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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
Baltasar García Perez-Schofield -
OpenSource -
Ben Halpern -
Vinod Kumar -
Top comments (22)
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:
My personal preference
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)
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.
Hmm, what type of security do they provide to you? I’m interested now :)
See Paritosh' comment in this thread.
In short:
Or for a concrete example, the "goto fail" bug from a couple of years ago:
imperialviolet.org/2014/02/22/appl...
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.
Don't use
switch
statements or chainedif-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 eachcase
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.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:
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...
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.
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. ;)
Or start doing audible code reviews.
In my team? That we should use JavaScript a lot more to improve UX.
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.
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...
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.
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.
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.
Yup, also the less code to read.
I'm only referring in a C# context as I'm not very familiar with other languages.
Hmmmm, how come? :)