The Only Coding Standard You'll Ever Need(vitruvianinteractive.com)
vitruvianinteractive.com
The Only Coding Standard You'll Ever Need
http://www.vitruvianinteractive.com/?p=34
21 comments
I completely agree with you.
I've followed many different coding standards, none of which perfectly match what I use for my own code.
Even if the coding standard was different in every way from what I like, it's still better than me doing it the way I want to and everyone else doing it their own way.
Coding standards are not about choosing the "one true way", but about consistency, just like you say. Whenever I see anything in a codebase that breaks any convention (whether a programming language one, an idiomatic one, a naming convention or anything), I assume it breaks it _for a reason_, and that I need to investigate why.
Having a consistent style also increases the usefulness of automated tools and search/replace.
I've followed many different coding standards, none of which perfectly match what I use for my own code.
Even if the coding standard was different in every way from what I like, it's still better than me doing it the way I want to and everyone else doing it their own way.
Coding standards are not about choosing the "one true way", but about consistency, just like you say. Whenever I see anything in a codebase that breaks any convention (whether a programming language one, an idiomatic one, a naming convention or anything), I assume it breaks it _for a reason_, and that I need to investigate why.
Having a consistent style also increases the usefulness of automated tools and search/replace.
Agreed. The author focuses on the right and wrong of things, but it is really about conventions.
One could argue that opening brace on the same line makes code look more "natural", or opening brace on a new line makes it look more "symmetric". But instead of reasoning about which way is better or worse, one should focus on coming up with a rule that is prescriptive and covers all cases.
For example, the "opening brace placement" rule should prescribe the position of the brace in all these cases (for C language): 1. if and for loops 2. Function definition 3. Switch statements
One could argue that opening brace on the same line makes code look more "natural", or opening brace on a new line makes it look more "symmetric". But instead of reasoning about which way is better or worse, one should focus on coming up with a rule that is prescriptive and covers all cases.
For example, the "opening brace placement" rule should prescribe the position of the brace in all these cases (for C language): 1. if and for loops 2. Function definition 3. Switch statements
Agreed. Coding standards have nothing to do with "my way is better than yours". If you feel like they do, you should find new people to work with. It's all about being able to view code consistently.
At my previous employer (Large consumer electronics company doing embedded dev) we had a LOT of old code, or code we had originally gotten from third parties. We also had a fairly exacting coding standard. The coding standard made groking the 3+ million lines of code running your average TV MUCH MUCH easier. However, if you came onto a file that was written for some other coding standard and you dropped code into it that didn't match the style of that specific file you would probably not get a thumbs up rom a code review.
In that situation we all understood it was far more important for all of the old crusty code in third party libs to have the same style even if it didn't match out own internal coding standard.
Reading bodies of code with different conventions sprinkled throughout adds needless complexity to the task.
At my previous employer (Large consumer electronics company doing embedded dev) we had a LOT of old code, or code we had originally gotten from third parties. We also had a fairly exacting coding standard. The coding standard made groking the 3+ million lines of code running your average TV MUCH MUCH easier. However, if you came onto a file that was written for some other coding standard and you dropped code into it that didn't match the style of that specific file you would probably not get a thumbs up rom a code review.
In that situation we all understood it was far more important for all of the old crusty code in third party libs to have the same style even if it didn't match out own internal coding standard.
Reading bodies of code with different conventions sprinkled throughout adds needless complexity to the task.
I've recently come around to the Go way of thinking.. the coding standard is that the the code compiles and has been run through gofmt.
As a lifelong new-line-bracer, it was a bit of a pain for me to swallow some bits of the enforced Go syntax, but having the language tools be the ultimate arbiter of many coding standard decisions (things like function and variable names is still up to you) turns out to be great because virtually all of those decisions are just bike-shedding and having an enforced standard just eliminates all of that and makes it so much easier to read anyone else's Go code once you get used to the standards.
As a lifelong new-line-bracer, it was a bit of a pain for me to swallow some bits of the enforced Go syntax, but having the language tools be the ultimate arbiter of many coding standard decisions (things like function and variable names is still up to you) turns out to be great because virtually all of those decisions are just bike-shedding and having an enforced standard just eliminates all of that and makes it so much easier to read anyone else's Go code once you get used to the standards.
I was just about to write and say the same thing. Establishing and adhering to conventions is tedious and often diverts focus from the problem at hand.
Go is fun, and things like gofmt and the fast compile speed do make it a productive language.
Go is fun, and things like gofmt and the fast compile speed do make it a productive language.
Proposing that code should be simple, brief, and elegant is not insightful. This is like a lawmaker saying: "Don't worry about writing down laws, let's simply always be just! It's easy!" It's not that easy. The details matter.
Codification and standardization are powerful tools that our entire civilization relies on. They minimize variation, thereby easing communication between interacting parties. If everyone is on the same page, it's simpler to express complex ideas. That's the whole point of writing coding standards.
Coding standards minimize superficial variation (where do the curly braces go? how do I format variable names?) so that we can talk about things that matter (how should this algorithm work? what are the side effects of this function?).
Of course, the other end of the spectrum is important too. Variation promotes innovation and creativity. It's cliche, but I think you have to find the right balance between codification and individual intuition. In addition, you should be willing to modify coding standards occasionally (just like all standards are revised and improved over time).
Codification and standardization are powerful tools that our entire civilization relies on. They minimize variation, thereby easing communication between interacting parties. If everyone is on the same page, it's simpler to express complex ideas. That's the whole point of writing coding standards.
Coding standards minimize superficial variation (where do the curly braces go? how do I format variable names?) so that we can talk about things that matter (how should this algorithm work? what are the side effects of this function?).
Of course, the other end of the spectrum is important too. Variation promotes innovation and creativity. It's cliche, but I think you have to find the right balance between codification and individual intuition. In addition, you should be willing to modify coding standards occasionally (just like all standards are revised and improved over time).
I always liked "Write code as if the next person who has to maintain it is a sociopath who knows where you live". Simplicity, Brevity, Elegance fits in that overarching ideal nicely.
I must say that this was a completely worthless posting and completely misses the point of coding conventions.
- locked
- stucked
- one true way
- never changes
WTF? What is he talking about? And somehow coding conventions inhibit innovation, exploration and creation? That's news to me.
Innovating and creating in languages like python is probably impossible in his opinnion, yes?
WTF? What is he talking about? And somehow coding conventions inhibit innovation, exploration and creation? That's news to me.
Innovating and creating in languages like python is probably impossible in his opinnion, yes?
On teams I've had success with we've agreed on a style guide, peer reviewed code, participated discussion on a daily basis, and generally evolved the standards and practices as a group.
Agreeing on a style guide is important because it removes those issues from the daily discussion. We usually utilize an existing style guide that is agreed upon by the broader community as well. This doesn't close the door to "house rules", but provides a solid base line for discussing more important topics of design.
In matters of style, we also prefer to have some automated formatting when possible. I've know people to set up their own formatter for work, and run it through the "official" formatter to commit. Personally think that is crazy. I can adapt to almost any style, but if that is what somebody is passionate about, who am I to judge?
Agreeing on a style guide is important because it removes those issues from the daily discussion. We usually utilize an existing style guide that is agreed upon by the broader community as well. This doesn't close the door to "house rules", but provides a solid base line for discussing more important topics of design.
In matters of style, we also prefer to have some automated formatting when possible. I've know people to set up their own formatter for work, and run it through the "official" formatter to commit. Personally think that is crazy. I can adapt to almost any style, but if that is what somebody is passionate about, who am I to judge?
Hi there,
Love your blog and your engaging writing style. But coding standards? Sorry, in a global and outsourced world of enterprise apps, standard are as important as never before. I have to disagree.
This whole coding creativity thing is a myth when it comes to successful, scalable business applications. Creativity is for artists, who have no boundaries. Coders don't operate in such an artistic vacuum (operating system, SDK, business clients, users etc). There has to be such a thing as a disciplined coder - disciplined as in being restricted by boundaries and rules. Power needs control - in my world.
Keep going with the blog - I will certainly be yet another interested reader.
Kind regards, Michael
Love your blog and your engaging writing style. But coding standards? Sorry, in a global and outsourced world of enterprise apps, standard are as important as never before. I have to disagree.
This whole coding creativity thing is a myth when it comes to successful, scalable business applications. Creativity is for artists, who have no boundaries. Coders don't operate in such an artistic vacuum (operating system, SDK, business clients, users etc). There has to be such a thing as a disciplined coder - disciplined as in being restricted by boundaries and rules. Power needs control - in my world.
Keep going with the blog - I will certainly be yet another interested reader.
Kind regards, Michael
I like the 3-word simplicity of the OP's conclusion. In practice, however, what developers decide is "Simple", "Elegant" or "Succinct" (the noun of brevity, which escapes me here), doesn't always overlap. In fact, with the non-10x crowd, those three concepts are unfortunately non-existent.
It seems to me that coding standards have existed for the non-10x developer to stay in line with a hard-and-fast set of clunky rules to keep them from coloring too far outside the lines.
The older I get, the less I enjoy coding standards outside of the three he points out. I just wish they'd work for everyone.
It seems to me that coding standards have existed for the non-10x developer to stay in line with a hard-and-fast set of clunky rules to keep them from coloring too far outside the lines.
The older I get, the less I enjoy coding standards outside of the three he points out. I just wish they'd work for everyone.
The first thing that popped into my head after reading the headline: http://xkcd.com/927/
Same thought after reading the article.
Same thought after reading the article.
"Elegance" is a slippery slope. I'd much prefer "Clarity".
Here's a stage I grew out of quick:
"Don't fuck with code that works, no matter how much you want to fix the world".
wow, dude, you thought you broke through and have a higher level of understanding. Ya missed the next layer of meaning man! Go back and get yourself a nice size project with a nize size team, preferably 50% contracters from everywhere. Hand out no coding standard, go through some scrum cycles, see what you get.
The only (syntactic) coding standard you'll ever need is "Make your code look like the code around it!"
Wrong. Someday maybe you'll need to work on code written by irresponsible and sloppy programmers who wrote buggy and unmaintainable code, which you should not perpetuate.
Very, very rarely is software buggy and unmaintainable because it has adhered to any consistent set of syntactic conventions.
Consistency. Consistency. Consistency.
Clarity. Expressivity. Simplicity.
> This reveals the fallacy that coding standards are built on – that there is some kind of one true way of programming, ....
No, a coding standard establishes conventions for a project, so that people can more easily understand and maintain code written by others. Moving between coding conventions is jarring, and adjusting to it takes time & effort away from figuring out what code does or what is wrong with it.
Similarly, the fact that an entire novel (or website or ...) is set in a particular font does not mean that this is supposed to be the one true font; rather, consistency means we can simply read, and not be continually jarred by font changes.