Skip to content
loading...
markdown guide
 

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)

 

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:

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

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

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

 

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.

 

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.

 

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

 

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.

 

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

 
 

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.

 
 

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.

 

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.

 

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

 

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.

Classic DEV Post from Dec 15 '19

VS Code + GitHub Gist = Developer Micro-Blogging (aka a "GistLog")

In a previous post, I introduced GistPad, a new VS Code extension that provides an in-editor scratchp...

Michiel Hendriks profile image
I shouldn't have written all of those tank programs.

Hey there reader...

Do you prefer sans serif over serif?

You can change your font preferences in the "misc" section of your settings. ❤️