DEV Community

Your most controversial opinion

Michiel Hendriks on May 03, 2018

What is the most controversial opinion you hold within your company, team, or project? I am not asking about tabs vs spaces, or editors. What opin...

Read full post

Jose Gonzalez • May 4 '18

I work in an awesome place holding pretty high code quality standards, so very little comes to mind.

I have one tiny nit-pick: brackets for one-line if statement in C#

Example:

if (cookies.Any())
{
   Console.WriteLine("Awwwww yisss, cookiieeeessss!!");
}
else
{
   Console.WriteLine("Oh noes, need cookies!")
}

My personal preference

if (cookies.Any())
   Console.WriteLine("Awwwww yisss, cookiieeeessss!!");
else
   Console.WriteLine("Oh noes, need cookies!")

Less code to read, the better. { } add unnecessary noise.

Note: Standards can change and I have an opportunity to change the existing standard. But all propositions are taken to developer votes (you know, democracy style)

Frank Carr • May 5 '18

I've been kind of back and forth on this.

From coding in C and C++ in the past, I like the security having the braces bring but I also like the brevity of not having to use them. I've kind of ended up in the use brackets camp because, in the long run, it makes the code easier to read for more people.

Jose Gonzalez • May 5 '18

Hmm, what type of security do they provide to you? I’m interested now :)

Michiel Hendriks • May 5 '18

See Paritosh' comment in this thread.

In short:

if (someRatherLongBooleanCheck) 
   doSomething()
if (someOtherRatherLongBooleanCheck) 
   doSomethingElse()
   doNotLookAtMe()
if (imJustHereToDistractYou) 
   andWeAreDone()

zenmumbler • Jul 16 '18

Or for a concrete example, the "goto fail" bug from a couple of years ago:

imperialviolet.org/2014/02/22/appl...

Douglas McKechie • May 4 '18

In terms of the company I currently work for they are huge advocates and promoters of Open Source Software (which is great), but this means often we aren't allowed to use what I might consider to be the best tools for the job, we must always use open source.

Casey Brooks • May 8 '18

Don't use switch statements or chained if-else statements. While they certainly can be useful in some situations, the majority of cases I see it in use signals a place where that logic needs to be extracted behind an interface, where each case is an implementation of that interface. The presence of a switch is a major code-smell when it comes to building maintainable or modular software.

Michiel Hendriks • May 8 '18

So basically a chain-of-responsibility pattern. I can get behind that.

I think we can adapt Craig Zerouni's quote a bit to give us a nice rule:

If you have too many [special] cases, you're doing it wrong.

Casey Brooks • May 8 '18

Ah, I had no idea there was a name for this pattern, but that's exactly it! I see references to GoF everywhere, and I usually find I'm actually doing a bunch of these patterns myself already when I see it. Maybe I should actually read that book sometime...

Tyler Smith • May 12 '18

The use of Foo, Bar and Baz in examples makes code concepts harder to understand.

While code is about abstractions, teaching through a more concrete implementations would help people learn code faster because it aligns more to how people actually think about non-code concepts.

Kasey Speakman • May 7 '18

Working from home. For now software development is a relatively small part of the organization. Most existing roles work with customers in person or use software only available on site, and remote work is not an option. So it violates some sense of fairness when I work from home, even though it is possible (and more productive) for my role. At times I collaborate a lot with people (spontaneous discussions about features, whiteboarding, pairing, surprise demos for visitors). Most of these could be overcome with the right collaboration tools. But the culture is one of expecting people to be available in person. So the idea is dismissed before the point where we would even try collaboration tools.

Maybe I should pick up a really annoying habit -- like smelling bad or clipping my toenails during lunch -- to make them beg me to work from home. ;)

Michiel Hendriks • May 8 '18

Or start doing audible code reviews.

Ross Henderson • May 3 '18

In my team? That we should use JavaScript a lot more to improve UX.

Michiel Hendriks • May 5 '18

In contrast to not improving UX, or to use some other technology? Or to drop the idea that the web application/sites should also work without JavaScript?

I used to be in the camp of "it should also work without JavaScript". Thus only use JavaScript to improve UX, but not depend on it.

But this changed once the old Internet Explorer died, and JavaScript finally became usable for most users. Now I think having some functionality which only works with JavaScript is acceptable for websites. And for web applications depending a lot/completely on JavaScript is perfectly ok.

Sam Ferree • May 12 '18

Having a team styleguide is important.

It’s not “nit picky” we take one hour to set the style, the set our editors to format on save, instead of having different bracket placements 8 times in 24 lines of code...

Michiel Hendriks • May 12 '18

I find that a really weird controversial opinion. A style guide is vital for any project that has more than zero developers. I cannot imagine anybody being against it as it does not take any effort to comply to it with current tools.

Thorsten Hirsch • May 11 '18

We are not allowed to contribute to open source projects, even though we use a lot of open source. I find this situation unethical, but my boss and my fellow developers don't care.

Chris Shepherd • May 12 '18

Got to agree. Apart from avoiding bugs, it reduces the amount of code you can see in one screen.

The less code you can see, the smaller people make their functions, the easier they are to understand.

Jose Gonzalez • May 14 '18

Yup, also the less code to read.

I'm only referring in a C# context as I'm not very familiar with other languages.

Jose Gonzalez • May 5 '18

Hmmmm, how come? :)

Christophe Riolo • May 13 '18

Javascript should get rid of the old warts without caring for legacy code. Legacy code should either update, or if it cannot update, it's code that is meant to be broken.

Ben Halpern • May 5 '18

I need to give this some thought and get back to you!