DEV Community

Cover image for Your most controversial opinion
Michiel Hendriks
Michiel Hendriks

Posted on

Your most controversial opinion

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 opinion do you hold which you cannot seem to convince your peers or management about.


Oldest comments (22)

Collapse
 
scottishross profile image
Ross Henderson

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

Collapse
 
elmuerte profile image
Michiel Hendriks

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.

Collapse
 
dougmckechie profile image
Douglas McKechie

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.

Collapse
 
josegonz321 profile image
Jose Gonzalez

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)

Collapse
 
jfrankcarr profile image
Frank Carr

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.

Collapse
 
josegonz321 profile image
Jose Gonzalez

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

Thread Thread
 
elmuerte profile image
Michiel Hendriks

See Paritosh' comment in this thread.

In short:

if (someRatherLongBooleanCheck) 
   doSomething()
if (someOtherRatherLongBooleanCheck) 
   doSomethingElse()
   doNotLookAtMe()
if (imJustHereToDistractYou) 
   andWeAreDone()
Thread Thread
 
zenmumbler profile image
zenmumbler

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

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

Collapse
 
ben profile image
Ben Halpern

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

Collapse
 
josegonz321 profile image
Jose Gonzalez

Hmmmm, how come? :)

Collapse
 
kspeakman profile image
Kasey Speakman

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. ;)

Collapse
 
elmuerte profile image
Michiel Hendriks

Or start doing audible code reviews.

Collapse
 
cjbrooks12 profile image
Casey Brooks

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.

Collapse
 
elmuerte profile image
Michiel Hendriks

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.

Collapse
 
cjbrooks12 profile image
Casey Brooks

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...

Collapse
 
thorstenhirsch profile image
Thorsten Hirsch

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.

Collapse
 
sam_ferree profile image
Sam Ferree

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...

Collapse
 
elmuerte profile image
Michiel Hendriks

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.

Collapse
 
lobsterpants66 profile image
Chris Shepherd

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.

Thread Thread
 
josegonz321 profile image
Jose Gonzalez

Yup, also the less code to read.

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

Collapse
 
tylerlwsmith profile image
Tyler Smith

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.

Collapse
 
christopheriolo profile image
Christophe Riolo

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.