Does Coding Style Matter? 479
theodp writes "Over at Smashing Magazine, Nicholas C. Zakas makes the case for Why Coding Style Matters. 'Coding style guides are an important part of writing code as a professional,' Zakas concludes. 'Whether you're writing JavaScript or CSS or any other language, deciding how your code should look is an important part of overall code quality. If you don't already have a style guide for your team or project, it's worth the time to start one.' So, how are coding style guidelines working (or not) in your world?"
Re:Kinda Subjective but... (Score:4, Interesting)
Here's the funny thing, and I'm honestly not joking: one of these guys is using Comic Sans as his coding font, as he's dyslexic and it helps him. The other is using Tahoma, because it's very narrow.
Visual preferences vary. That is why we are able to set our own fonts and colours in our IDEs. It is strictly a personal thing. I'm a black-on-white guy, but the Tahoma guy from above is using the old Borland nineties colour scheme, yellow-on-blue. Strangely enough, I "grew up" on those same colours, and since switching to LCD monitors, I can't stand it any longer. No idea why...
Re:Let people code how they like (Score:2, Interesting)
I do not see any point in coding styles whatsoever.
then you have never worked on a free software collaborative project; you have never submitted patches to free software projects; you have never worked for a large software engineering firm with ISO9001 (Software TickIT) practices in place; in fact you have probably never worked with revision control tools ever in your life.
please allow me to know exactly who you are so that i never, ever employ you or allow you to go anywhere *near* any of the free software projects i am involved in or will be involved in, in the future.
It's so easy to run a code formatter on something now that someone else can read code however they like if it's really important.
running a code formatter and then creating a patch automatically includes your modifications in amongst a bunch of whitespace modifications, by violating the golden rule of submitting single-purpose patches.
even if you were to submit a patch with a massive white-space "code formatting" modification, the existing developers would, quite rightly, tell you to fuck off. if you committed it *without* asking them then they'd be fully justified in complaining and, if you persisted, in getting you fired.
a key in the statement you wrote is "read the code". if your sole job is "reading the code", then you're not really truly involved in the development. i'm assuming that you're a useful contributor: that means you have to submit modifications. forcing *your* coding style - especially when you've clearly and up-front stated that you don't see any point in *any* coding styles - onto everyone else is bound to cause serious problems.
bottom line is: i'm not impressed. fortunately, this conversation allows everyone else to understand *why* coding styles are important.
Re:It's easy with an IDE (Score:5, Interesting)
Having a consistent style means that you don't end up in the situation we are, where we have several patches that are probably a days work to merge with the main line, not because our patches are large, but because some bonehead decided it would be good to run an automated code reformatter on his source tree.
This not only reformatted everything to a style that no-one else on the project uses, but re-sorted all the fields and methods in the source files affected. This made everyone elses copy of the source conflict violently with essentially every change made in the reformatted files, giving everyone else the headache of re-implementing their patches.
Peoples edits continue to make the format of these files a mess because they are indented in a way that's inconsistent with the source.
Alas, we can't undo these patches because the bonehead is the lead developer. But catering to prima-donnas means more work for everyone else.
Re:It's easy with an IDE (Score:4, Interesting)
It all comes down from the guy in charge. I've set the coding style at two of the last three companies I've worked for, and while new guys may not like it, it does promote effective teamwork. It's a lot more than just indentation. We use the same data structure styles, iterator styles, and everything from start to finish. It can be very difficult to determine who wrote any given piece of code, and a git-blame shows that it's a patchwork quilt with everyone contributing all over the place.
The guy who I will say is now the lead developer of our main software suite writes code that looks exactly like mine. We've even on occasion wrote entire functions, in the same place, which were identical down to the last character, even in the obligatory comment. No git conflict in that case. At the other company, there literally were no coding style guidelines, and the result is no one was able or willing to easily edit anyone else's code. That makes it very difficult to move people around to projects that need them most.
There are a ton of developers out there who are loners. It's a field that attracts geeks who are somewhat social-phobic. I've never seen programmers voluntarily adopt a common coding style. It's more fun to fiddle around on your own. So, instead of working together as a team to solve real problems rapidly, individual programmers go off in different directions, learning more about different ways to write code than actually writing code.