Your Brain Cares About Code Style
My first team had (among many other great attributes) the custom of strictly following a style guide. It was followed so religiously, I’ve yet to come across another place that does so to the same extent. It wasn’t really written down anywhere, but after a couple of weeks of pairing with the other guys you got it.
What does that mean exactly? It means that we wrote code that looked, to a large extent, like it was written like the same guy. We put 2 blank lines between regions. Members had a specific way of documenting. We even used the same idioms for creating empty lists etc. (Java).
If we paired with someone and saw him indent the code the wrong way, we’d go all OCD until it was fixed. And it was regarded totally OK. We didn’t feel like we were nitpicking on each other. It was the way things got done. I even know a guy that would notice extra whitespace at the end of lines (without any IDE help).
Ever since, whenever I see code written with careless indentation and whitespace I feel like the coder who wrote that just doesn’t care enough for the craft. Yes, No Whitespace – No Care!
What’s the big deal?
If code isn’t written in a consistent style in your team, whenever you come across code with the spacing a bit wrong, the first thing your head’s going to process is “I didn’t write this.” This is a natural feeling, and as we all know coders have a hard to restrain impulse to rewrite any piece of code they didn’t write. Once all the code looks the same, that feeling isn’t that hard and you can actually focus on the code itself and have a better sense of ownership. I know, it sounds stupid, but that’s the way our stupid minds work in.
A big part of the Extreme Programming principle Collective Code Ownership is obtained by simply keeping a consistent style. Anything important enough to become a core value of the only methodology that works must be worth the effort to take notice of.
principle Collective Code Ownership is obtained by simply keeping a consistent style. Anything important enough to become a core value of the only methodology that works must be worth the effort to take notice of.The next time you see code with reckless spacing, change it and let your teammates know. It might be hard at first but the end goal is important – the ability to fluidly read code, without feeling like you’re wearing someone else’s shoes.
Subscribe in a reader
Use automatic code formatter. Problem solved.
Style (as Aviv is defining it) is a lot more than whitespace and bracing conventions – it’s all that, plus use of language idioms, plus comment standards, plus so much more. For example, if half of your comments are written as imperatives (“Check input variables for NULLs”) and half are written as descriptions (“Checks input variables for NULLs”), then your style is inconsistent, plain and simple. Show me a code formatter that can correct that!
Beyond that, though, it’s much better to train individuals to write code in a certain style than to train them to run “make format” before each commit – as Aviv points out, when you see code that looks and reads exactly the same, day after day, your brain abstracts away the details of the formatting and starts processing on a higher level. If you’re used to writing code differently than everyone else and simply relying on indent(1) all the time, that higher-level thinking gets replaced by cognitive dissonance, as your brain struggles to hold two sets of style rules at once.
For a team to make real progress, each member has to be focused on the work to the best of his or her ability. With inconsistent code style, that’s simply not possible.
crtl+a source->format. Done.
This really is true words. One of my biggest issues with browsing someone elses sourcecode is having to swallow the fact that they organize code like turds. You’ve opened my eyes, young lad, and for that I am thankful!
I’m glad to see your post about the importance of consistency in programming. You are right on the money when you say that our minds expect to discover rules and patterns in code and we get easily disoriented and confused when we encounter many unexpected and unjustified exceptions.
I wrote about the importance of consistency in my own blog a while ago. Would be happy to get some feedback from you. You will find the blog post here:
http://theamiableapi.com/2011/09/14/api-design-best-practice-consistency/
Thanks,
Ferenc
I would love to see that working with the Teams i work with (freelancer).
Not long ago, a guy reformatted my code to some i-have-never-seen-and-dont-belive-that-those-are-standards standard via some stupid IDE plugin. it was terrible and after that it just wasnt my code anymore.
Thats why we customized and automated code beautifier. Everyone after writing code needs to run code beautifier which makes everyone code exactly similar to the last white space.
Much ado about nothing. Use a code formatter with the same settings and problem is solved.