Slashdot Mirror
Does Coding Style Matter?
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?"
At my workplace, we just all plug the same code style settings into our IDEs, and everyone's code gets formatted the same way automatically. And yes, it matters: having everyone's code formatted the same way makes it much easier to read.
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.
I've always preferred to use tabs over spaces for indentation, 2 breaks in between major sections or functions, and clearly named vars or functions. The kind of code most people can drop into and say "Oh, I see where this is going" and immediately begin to understand and therefore modify.
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?
What else can happen when an unstoppable force collides with an immovable object?
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.
You can't handle the truth.
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.
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.
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.
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".
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
The best article that I've ever read on coding style is Style is Substance by Ken Arnold.
I won't repeat what he has to say here, because he explains it better than I could. But I wish that more programming languages would follow what he is advocating, because we waste way too much time arguing about braces and tabs.
Ctrl+K, Ctrl+F
Presto, you've got your coding style for code that you didn't write.
Doesn't work for me. Ctrl+K deletes the current line, and Ctrl+F moves the cursor forward one character. What version of emacs are you using?
Just use Artistic Style for C and its derivatives C++, C#, and Java. I usually set it for "--style=ansi", but that's a project preference. External code is run through Artistic Style before use. This way, everyone knows the indentation is consistent.
For Python, of course, there are few formatting options, so this isn't an issue. Dreamweaver will indent HTML. Javascript remains a problem.
Almost all the posted comments are talking about formatting (tabs vs spaces, indentation, line breaks, etc).
While its good to be consistent with these. Style is so much more.
Consistant naming schemes for variables/functions/classes/methods etc.
Useful and meaningful comments.
Handling non-expected input and states gracefully
Catching and handling of exceptions
meaningful feedback to the user if there is a problem.
I would call all these things and more "style." These are the things that make it easy to maintain code after it is written. They also help to reduce the incidence of bugs.
My does:
My don'ts list is getting shorter and shorter. Most programmers have reasons why they produce the code the way they do. Lack of experience should be met with understanding and appreciation for improvements.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
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.
I still have more fans than freaks. WTF is wrong with you people?
When writing code everything matters.
Forcing people to follow a style I think is counter productive. It prevents the styles from evolving. In recent years for example people have been moving towards using better naming rather than commenting.
Strict rules prevent creativity and for that reason I disagree with the conclusions of the article to require one. Requiring anything more than just to follow a style no matter what that style may be and to try to maintain the existing code in the style that it was in is about as much as you can do.
"The best way to predict the future is to invent it." - Alan Kay
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;
I have worked with large engineering firms; I have not have submitted small patches to OS projects long ago but as I noted, for small changes I mimic existing coding style.
I have worked with dozens of teams ranging in size from two to thirty or so.
in fact you have probably never worked with revision control tools ever in your life.
I have worked with many such tools starting with RCS, then CVS, then git.
running a code formatter and then creating a patch automatically includes your modifications in amongst a bunch of whitespace modifications,
You may have not noticed where I said small changes I mimic existing coding style. I am talking about new code, where someone who is submitting the code is also the guy who has been writing it for a while. As long as the people working on that block of code are consistent, there is no SCM issue with them coding as they like. I am not saying to re-format a whole file and check that in; just to make it more readable as needed.
bottom line is: i'm not impressed.
And I am sad you cannot read, nor understand the point I am making.
Hopefully for the good of future teams you can eventually lodge the stick out of your ass that companies have made you push in so far you don't even know you have it any longer.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If you have to enforce a standard for using proper names of variables, functions, and classes and documenting your code - YOU ARE HIRING the wrong people to start with. I'd fire anyone that you have to actually state that to or even if I was forced to point that out to.
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?
Well maybe that's going to be fixed. Let's see:
>>> from __future__ import braces
File "", line 1
SyntaxError: not a chance
>>>
Nope.
PS: That's real, try it yourself
Your coworkers, however, might.
ftfy
grammar-lesson free since 1999. (rescinded - 2005)
Poor or inconsistent coding style, OTOH, gets in the way of producing correct, working code. If you have to constantly stop to figure out how the current statement's nested or which block it's in, that takes time and attention away from concentrating on what the code's supposed to do. That means more errors, more bugs, more time debugging and a greater likelihood of missing bugs or a deadline or both. If I look at code and find no consistent coding style in it, that tells me that either the programmer didn't take too much care writing the code or there were several programmers working on it who didn't take any care to mesh their work. Either way it makes me wary of the code.
And while mostly the exact style doesn't matter, only that there's a consistent style, some styles do have their drawbacks. Forinstanceomissionofwhitespacetends tomakecertainerrorslike=vs==harder tostopandmorelikelytolinger. Now, how long did it take you to find the typo in the previous sentence? I rest my case.
Seemingly you are the one who can't click a button. And that is your fault.
Code style can, however, make it easier to spot typos when you make them, easier to scan for them. Eg. the regexp "if .* = " to spot use of an assignment inside an if condition, which is normally a bug. If you consistently use whitespace between tokens, it's easy to write that regexp and have it reliably catch all occurrences while also reliably not catching anything else. If you omit the whitespace, it's harder to come up with a check that's resistant to false positives (and a test that throws up a lot of non-matching lines isn't helpful, the errors get lost in the noise). It can be done, but this is about easy not merely possible. You can make pigs fly with a big enough rocket strapped to them, but if you want a flying animal it's easier to just start with a pigeon instead. And anyone who wants to use techniques that make it easier to make errors and harder to spot them when you do make them... is not a professional.
Seriously? You are reading the code, fixing bugs, and you find formatting problems. So you back out your half-complete changes, fix the formatting, commit that change, then re-apply your fix-in-progress?
NO. What part of dedicated commit for formatting changes do you not understand?
You never leave changes from a previous session uncommitted; always commit all changes before leaving the desk.
Before you start working on any code, you update your working directory from the repository. You correct any formatting problems and commit, after update from the repository, and you do this when you have not yet made any changes to the code, and 'svn diff' is empty.
If you discover any formatting issues, you ignore any formatting issues you see, DO NOT CHANGE THE FORMATTING, while you are coding, finish your code changes, commit that.
Then, only after your code changes are fully committed, you run the formatting script, and commit any formatting changes.
Your diffs will then not be polluted.
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.
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.