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?"
It's easy with an IDE (Score:5, Insightful)
Er (Score:3, Insightful)
Of course coding style fucking matters. Code's generally going to be part of a much larger product that existed long before you joined a company and will continue to exist long after. You don't want the codebase turned into some sort of elaborate puzzle with 200 different methods of laying out code contained within. Uniformity makes maintenance much easier.
Kinda Subjective but... (Score:5, Insightful)
I can't stand opening up any type of code, even web pages, and finding ugly difficult-to-follow lines which seemingly make no sense. Then again, it's all a matter of preference and perspective, isn't it?
Learn one word (Score:4, Insightful)
Learn one word: consistency.
Be consistent from one piece of code to the next, from one project to the next. Be consistent about your design ideas, be consistent in your thinking. It's going to help you and anybody else working on the same stuff.
Everything else is sugar.
Let people code how they like (Score:2, Insightful)
I do not see any point in coding styles whatsoever. All they do is slow down coding for all but the two guys that actually like the coding style as defined; for the rest it's needless busy-work to comply.
I agree that one persons code should look consistent; so someone should pick a style and stick with it. Also if I am making a SMALL change in someone else's code, I try to mimick the style of code around it.
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. But while code is underway conformance to a specific style is not helpful.
Re:Kinda Subjective but... (Score:5, Insightful)
Out of curiosity, why do you prefer tabs? Seems like unless everyone has the same tab size set, it can make the code more difficult to read than spaces.
Further, most IDEs and text editors have "smart tabs", allowing the simplicity of working with tabs even though you're using spaces.
Re:Kinda Subjective but... (Score:5, Insightful)
I use tabs because anyone can set the width to whatever they like (2, 4 or 8 spaces usually).
Re:Let people code how they like (Score:3, Insightful)
Note to self, don't hire this one.
The reason we enforce code style is the same that we enforce requirements traceability. We must have maintainable, auditable code. If we were writing throwaway scripts to delete old comments on a website, perhaps that would be okay. However, when we're writing production code that needs to work and be maintained, code style is very important. Yes, we audit code. Yes, it works. We have yet to have gotten hit with a real-world exploit, critical bug or unexpected behavior from garbled input.
Is writing code this way slower and more expensive? Hell yes, if you believe that SLOC is a good measure of success. However, we care about lifecycle cost, and our approach is working very well. And, it's easy to take a month of vacation when you know your code's good enough that nobody will call and ask about it.
Style has always mattered (Score:2, Insightful)
Mine is best, yours sucks to the extent that it isn't mine and most editor/IDE authors are too lazy to make mediating style a critical feature; but they seem to be slowly getting there. Now get those goddam spaces out of my indents so I don't have to get carpal tunnel, or else make me an editor smart enough to automaticly import them as tabs and export them as spaces so that we can just. stop. talking. about it.
Re:Kinda Subjective but... (Score:5, Insightful)
Out of curiosity, why do you prefer tabs? Seems like unless everyone has the same tab size set, it can make the code more difficult to read than spaces.
For the same reason why CSS was invented to style HTML. Tabs are entirely font-agnostic and they are semantic. Spaces are not, and are directly visual.
There are people who like two characters of indentation and there are those who like eight. Some like six! There are people who like proportional fonts for coding. There are people who like special narrow monospaced pixel fonts. Even Consolas on Windows, a very popular coding font, is narrower than the standard monospaced width, so code is less indented with Consolas than Courier.
Tabs are also easier on the eyes if you have "show special characters" turned on in your IDE. Also, tabs are easier to work with if you ever need to run some regex on your code.
There are no benefits whatsoever to using spaces, only downsides.
Code style, not formatting style (Score:5, Insightful)
I don't really care how you *format* your code. Do you put the brackets on the same line as the beginning statement? Do you put a space between the function name and parentheses? Do you double-space your code? I don't give a fuck. That's all syntax. It's easy to figure out.
Coding style is more important to me, how the actual *code* works. Do you initialize your variables as soon as possible? Do you properly use for loops and while loops? If you use recursion, does it make sense? Do you give your variables meaningful names like $activityType, or useless ones like $_a? How do you decide when to break something out into a function?
I work on a project with several other people. We all have our unique styles, both for format and for code. I, for instance, have been told I code with a "LISP accent", rarely storing the return values of a function in a variable, rather using the return value as an argument to another function. Another puts a blank line between nearly any two statements. Another assiduously follows some code formatting standard nobody else in the company has read.
Although it can make it harder to work on each other's code, it has one benefit - you can easily tell who wrote the code. "Putting the braces on a new line? This must be Pete's code!" or "There's an underscore at the front of every variable name? This must be Jimmy's code!" or "There's a for loop that starts ''for (;;){''? This must be Kevin's code!".
And if I do go in to "someone else's code" and change or fix things, I follow their style, more or less. Unless I'm completely rewriting a section, or making enough of a change that it should be considered a rewrite.
Re:Kinda Subjective but... (Score:5, Insightful)
a tab is a tab. It is not 8 spaces. It might be the same width as 8 spaces, but that is because your editor displays a tab as that width. Most editors allow you to change it.
If your code style calls for tabs, do not insert 8 spaces instead of a tab. it's annoying, and you break the tab settings everyone chose for themselves.
Re:Let people code how they like (Score:5, Insightful)
Coding style is not just be about making code look pretty (according to someone's personal definition of pretty). The purpose of a coding standard is to make the code more readable and thus, more understandable. Having the code look consistent helps in that regard.
Most of the time as a programmer is not spent on producing code but on skimming through other people's code and trying to figure out how something works, or why something doesn't work. Time is money, and it is better that a code writer spends a few extra seconds on making the code more readable than a code reader spending maybe fifteen minutes on the same piece of code because he misunderstood some detail of it the first time around because it was written in a weird way.
There are some things that are more important than whitespace and braces, that are too often overlooked. A coding style/code standard should also include conventions for code patterns, comments and how to choose reasonable variable names ... and these things can not be changed by a "pretty printer".
Re:Kinda Subjective but... (Score:4, Insightful)
And when you use tabs, it doesn't matter what tab size they assume. That is the point. Proper use of tabs means you use tabs to indent to the block level and spaces for further indentation, like so:
{
<-tab->a = long expression
<-tab->____continued;
}
Re:It's easy with an IDE (Score:5, Insightful)
... and it makes version control diffs shorter and to the point.
...and makes global search and replace easier, because you can more often use plain strings, rather than having to construct a regex.
Re:Kinda Subjective but... (Score:5, Insightful)
Tabs for indenting, spaces for alignment. Makes sense logically too, because those two functions are fundamentally different.
I.e. it should be:
<TAB>int_a;________//_Hello
<TAB>int_whatever;_//_Yeah
Where <TAB> is a tab and _ is a space.
Works beautifully. Think, people!
Re:It's easy with an IDE (Score:4, Insightful)
Re:Kinda Subjective but... (Score:5, Insightful)
man expand
read it.
And your post is exactly why people standardize on spaces. Because some people think they can insert a bunch of spaces instead of a tab, breaking everyones formatting, making diffs a huge mess and putting your whitespace changes in the commit log. Tab is not space.
A space is ascii # 32
A tab is ascii # 9
stop mixing them.
Re:Let people code how they like (Score:5, Insightful)
No, really he's not. I am quite capable of reading code with different indent styles, brace styles, etc. I do so on a regular basis, even when working with language approved styles as I regularly program in multiple languages. I have no trouble with it mixing program to program, file to file, or even function to function.
In fact, most code bases I've worked on looked like that. And there was no noticable speedup in places that did enforce a style vs those that didn't.
In fact, he actually tends to harm code quality. Why? Because he bogs down code reviews. Rather than looking for serious maintenance or correctness problems, we focus on his half dozen style complaints. This wastes our time and causes people to hate code reviews, or take them less seriously. The places I've worked with style guidelines all had shitty code review processes, and this was the reason.
So no, that anal retentive asshole made everyone's job far worse. There are code style issues that matter, like naming variables well and commenting sufficiently. Formatting is not one of them, and being particularly picky about it is a BIG red flag about both a person and a company.
Re:It's easy with an IDE (Score:5, Insightful)
Sounds like pandering to the lowest-common denominator.
Why don't you switch to programming in VB while you're at it?
Bullshit. If I want to search for every time that a certain condition is evaluated, I should be able to search for "if (foo.bar ==", not "if\s*\(\s*foo\.bar\s*=="
Wait? Is that even right? Can = be used without escaping when it is outside of a capture or a positional assertion???
Re:It's easy with an IDE (Score:5, Insightful)
Re:Let people code how they like (Score:4, Insightful)
Note to self; don't work for people who don't have a real account on Slashdot.
Seriously? How is having a slashdot account a positive personality attribute? Were you too busy reading the articles to notice what gets posted here?
Re:It's easy with an IDE (Score:4, Insightful)
That's silly. You let the experts in your team write the "complicated C++ meta-template programming techniques" and the mediocre programmers use them. That's the point of C++-templating: Make it easy for the users of the code. It's incredible what kind of extremely convenient libraries can be written by template wizards.
Gladly the next standard will also make it easier to write, see "static_if" proposal.
Re:Kinda Subjective but... (Score:4, Insightful)
Re:It's easy with an IDE (Score:4, Insightful)
.. and then you commit your changes and everyone wants to kill you. You just broke all their patches.
There have been various proposals for an IDE that stores the sources as a raw format that has no formatting, and you apply the formatting in the view, but they obviously have the disadvantage of not working with a plain text editor, needing a special IDE, probably a special version control system as well.
Re:Kinda Subjective but... (Score:3, Insightful)
Seriously, what the fuck are you doing that depends on the exact way that tabs are displayed by other people!? Why would it possibly be that important? Just how fragile is your workflow that it's broken by someone else's display metrics?
Maybe you need to take a long hard look at your toolchain, then throw it outside in a heap and set fire to it.
I've been using whitespace-insensitive diff and merge tools since the 90s, and I reformatters since 2001 to solve even the largest formatting inconsistencies. There is never a reason for any programming task to be "broken" by the use of tabs, spaces, or any combination with any configuration. The tools to fix any conceivable problem have been around for over a decade.
If you're finding you're writing regular expressions looking for a specific number of space-equivalents made up from tab characters, just stop. Re-think your career in programming, and considering going into the secretaries typing pool. You'd fit right in, because many of them also still haven't figured out that a tab is not the same thing as 'n spaces'.
Next, you'll be complaining that people are putting spaces in their file names...
And it should never matter today! (Score:4, Insightful)
Code editors (at least most of them) are still stuck in a dark age where everything comes down to hand-crafted ASCII-art, which is complete and utter bullshit. Editors could and should work much closer, if not directly on, the AST of the language in question, and completely abstract away all those pesky details like indenting scopes or formatting comment blocks "properly". That stuff should be left to user preference and style sheets.
But I guess that would put an immediate end to the religious zeal displayed in tabs-vs-spaces (it's of course ts=8 sw=4 noexpandtab, noobs!), would not mask syntax errors in gobs of meticulously crafted gunk, and take all the "fun" out of programming.