Why I Have Given Up on Coding Standards(richardrodger.com)
richardrodger.com
Why I Have Given Up on Coding Standards
http://www.richardrodger.com/2012/11/03/why-i-have-given-up-on-coding-standards/#.UK0hmuOe89E
58 comments
At my workplace we do it like this:
1. Here's the Eclipse code formatter settings - format your code with those
2. Never format your code otherwise
3. If one or two lines of code formatted this way are unreadable and you can't rework it, format it how you see fit.
1. Here's the Eclipse code formatter settings - format your code with those
2. Never format your code otherwise
3. If one or two lines of code formatted this way are unreadable and you can't rework it, format it how you see fit.
This is exactly what I was thinking as I read the article. There really are "Crazy Coder's" out there who write obfuscated code just because they can and it's infuriating.
No. You (MG) are using the wrong tool. You're hammering with a ratchet.
The correct tool is code reviews, to tack his eccentricity back to understandable.
Refuse to submit to pedantic assholes. CC is being a pedantic asshole when he claims "there is or isn't a coding standard"
>Now typical escalations are NG assigns the bug to CC since CC won't tolerate his code changes. NG will reformat a big chunk of CC's code just to piss him off.
NG will reformat a huge chunk of CC's code because he can't tell if it's correct formatted in an odd manner.
You can do weird stuff, occasionally, when it's useful. Trying to do it all the time? No. That's not okay. That's dumping a giant pile of tech debt on a project and basically being a sloppy, unprofessional coder. If he doesn't become more professional, you give him the boot, and DON'T MAKE EVERYONE ELSE'S LIFE SHIT for that dipshit.
I hate working at places that never fire people because they tolerate, and eventually promote CC.
The correct tool is code reviews, to tack his eccentricity back to understandable.
Refuse to submit to pedantic assholes. CC is being a pedantic asshole when he claims "there is or isn't a coding standard"
>Now typical escalations are NG assigns the bug to CC since CC won't tolerate his code changes. NG will reformat a big chunk of CC's code just to piss him off.
NG will reformat a huge chunk of CC's code because he can't tell if it's correct formatted in an odd manner.
You can do weird stuff, occasionally, when it's useful. Trying to do it all the time? No. That's not okay. That's dumping a giant pile of tech debt on a project and basically being a sloppy, unprofessional coder. If he doesn't become more professional, you give him the boot, and DON'T MAKE EVERYONE ELSE'S LIFE SHIT for that dipshit.
I hate working at places that never fire people because they tolerate, and eventually promote CC.
I certainly agree with you, and if you work for me that is the treatment you get.
If you aren't the manager though, you are NG in my example, its hecka frustrating. When the CTO (and the author is the CTO of his company) says "There won't be any coding style strictures here" you give the CC guy a weapon to annoy his co-workers and his manager. And yes you should fire him once that personality type is made apparent but counting on the manager to have the stones to make that call is often a losing bet. To give you an example of how passive-aggressive this behavior can become, I knew an engineer who wrote his comments in Klingon. The style guide demanded comments, he didn't feel comments added anything useful over reading the code, he wrote comments in Klingon. What sucked (for him) was when Klingon translators started popping up on the web. Needless to say his rants ceased being private to him.
If you aren't the manager though, you are NG in my example, its hecka frustrating. When the CTO (and the author is the CTO of his company) says "There won't be any coding style strictures here" you give the CC guy a weapon to annoy his co-workers and his manager. And yes you should fire him once that personality type is made apparent but counting on the manager to have the stones to make that call is often a losing bet. To give you an example of how passive-aggressive this behavior can become, I knew an engineer who wrote his comments in Klingon. The style guide demanded comments, he didn't feel comments added anything useful over reading the code, he wrote comments in Klingon. What sucked (for him) was when Klingon translators started popping up on the web. Needless to say his rants ceased being private to him.
Well you talk to the CTO about reasonableness or get a new job, because if the CTO doesn't value that, the company is headed for the trash can.
Exactly this happened to me once (with me playing the role of NG). MG and CC were the same person (a founder).
Hilarity ensued, for very large values of 2.
Hilarity ensued, for very large values of 2.
As with most things, the answer lies somewhere in the middle. Not having a coding standard at all is just as bad as having a very rigid standard with no room for free expression and where nobody can remember all the rules.
See StyleCop (for MS languages) for examples where "coding style guides" can go overboard.
See StyleCop (for MS languages) for examples where "coding style guides" can go overboard.
I don't do coding styles that aren't the "standard" for the language or aren't done by a tool (or at least done by a compile time add on program). I just change employers.
You're paying me 6 figures, you can make reasonable guidelines about things and expect professionalism but not mindful, constant compliance with arbitrary rules. It drains self control and concentration to follow huge coding standards with lots of minutia (Always put a contract with X Y Z above every function, always put stupid ass hungarian in front of your variables, etc).
You're paying me 6 figures, you can make reasonable guidelines about things and expect professionalism but not mindful, constant compliance with arbitrary rules. It drains self control and concentration to follow huge coding standards with lots of minutia (Always put a contract with X Y Z above every function, always put stupid ass hungarian in front of your variables, etc).
Yeah, I agree... The best thing is IMHO a standard which answers where to put curly braces and some basic variable naming convention. (Upper/lower/camel case, to prefix or not to prefix with type abbreviations etc... depending on the PL) Going further just creates pointless discussions...
The biggest thing to know about coding standards is that many programmers need to stop being giant dicks about it.
By this I mean I've come across people who insist on:
Others who insist on 2 space, 4 space or tab indents.
Others who insist on braces on new lines (in Java) or on the same line (in C/C#/C++), both of which go against the prevailing style.
Others who want to static import everything (in Java).
Etc.
None of it actually matters in the absolute sense. The key to working well in an organization is being flexible enough to just do what everyone else does.
At Google we use 2 space indents and 80 character lines (100 for Java). I actually like it now but in past lives I'm more used to 4 space indents and no line length limit. Whatever. It doesn't matter. Get over it (and yourself).
You see this same sense of heightened inflexibility in build systems. Some diehards like Ant (in Javaland) because you can arrange your project anyway you like (with enough XML). These same people chafe against the predefined structures of Maven.
The point of Maven (and organization-wide coding standards) is not that they're empirically the best. It's that they're consistent. You look at any Maven Web app and you'll know where to find things. Seen one, seen em all. Every Ant build is different.
Yet people continue to insist their (non-prevailing) differences actually matter and their exceptions should live on. They don't and they shouldn't.
Code should be written for those that come after you and read it knowing nothing about it. Knowing where to find it and being familiar with the conventions is a huge help.
And don't even get me started on the ASI (automatic semicolon insertion) crowd. That has to be the most idiotic idea in the history of coding styles: forcing people to learn a set of rules about when ASI happens (some of which can be quite subtle) for absolutely zero gain.
Seriously, if any of this gets your back up and you want to protest how ASI is good or how your weird style is important, just stop being a giant d-bag. Your teammates would secretly thank you for it.
By this I mean I've come across people who insist on:
if (blah) {
// ...
}
else ...
Others who insist on 2 space, 4 space or tab indents.
Others who insist on braces on new lines (in Java) or on the same line (in C/C#/C++), both of which go against the prevailing style.
Others who want to static import everything (in Java).
Etc.
None of it actually matters in the absolute sense. The key to working well in an organization is being flexible enough to just do what everyone else does.
At Google we use 2 space indents and 80 character lines (100 for Java). I actually like it now but in past lives I'm more used to 4 space indents and no line length limit. Whatever. It doesn't matter. Get over it (and yourself).
You see this same sense of heightened inflexibility in build systems. Some diehards like Ant (in Javaland) because you can arrange your project anyway you like (with enough XML). These same people chafe against the predefined structures of Maven.
The point of Maven (and organization-wide coding standards) is not that they're empirically the best. It's that they're consistent. You look at any Maven Web app and you'll know where to find things. Seen one, seen em all. Every Ant build is different.
Yet people continue to insist their (non-prevailing) differences actually matter and their exceptions should live on. They don't and they shouldn't.
Code should be written for those that come after you and read it knowing nothing about it. Knowing where to find it and being familiar with the conventions is a huge help.
And don't even get me started on the ASI (automatic semicolon insertion) crowd. That has to be the most idiotic idea in the history of coding styles: forcing people to learn a set of rules about when ASI happens (some of which can be quite subtle) for absolutely zero gain.
Seriously, if any of this gets your back up and you want to protest how ASI is good or how your weird style is important, just stop being a giant d-bag. Your teammates would secretly thank you for it.
In C, braces on a new line is the prevailing style? I've been doing the opposite because that's what K&R C does (except for braces that define functions).
Respecting Google's Java standards, sure. Respecting GitHub's JavaScript guidelines? No thanks. When organizations have earned the right to tell its employees to use a style it's no problem to do things slightly differently than you normally would, but when they haven't earned it...
As someone who is currently refactoring a giant mess, this is a terrible article.
The problems are myriad:
- we have people mixing camelCase and underscores
- we have tab indents and four space indents, and eight space indents
- program state is all stored in one giant struct, making the code impossible to reuse
- methods are giant, rambling monsters with at least 6 levels of indentation
Coding style is important, is what I'm saying.
The problems are myriad:
- we have people mixing camelCase and underscores
- we have tab indents and four space indents, and eight space indents
- program state is all stored in one giant struct, making the code impossible to reuse
- methods are giant, rambling monsters with at least 6 levels of indentation
Coding style is important, is what I'm saying.
Heck, I'd even settle for a much less than good coding style, as long as it's consistent throughout a project.
What you are complaining about is incompetence, not a standards document.
I wouldn't describe it as incompetent, it's just not forward thinking. We have a loosely enforced style guide that should prevent the formatting and casing issues, but what we need is actually a more dictatorial approach.
As I'm rewriting, I'm producing a style guide which is more prescriptive about things that matter, like writing reusable code. This includes trying to identify hotspots where extensibility is very important, versus areas where the code just needs to be readable and work. These deserve more love and attention from an architecture perspective.
As I'm rewriting, I'm producing a style guide which is more prescriptive about things that matter, like writing reusable code. This includes trying to identify hotspots where extensibility is very important, versus areas where the code just needs to be readable and work. These deserve more love and attention from an architecture perspective.
This is kind of conflating two different things.
One thing is conventions around things like where curly braces go, naming conventions for classes and methods and different types of variables, how much whitespace to use where, and so forth. Most of these things don't actually matter at all, but code certainly is easier to read if everyone on a team follows the same ones (so that I know that Foo.bar() is a static method while foo.bar() is a method call on a local variable and _foo.bar() is a method call on an instance variable on the class, without having any other deep knowledge of the code). The point of conventions is basically to get everyone to stop bikeshedding about things that don't matter (like which line a curly brace goes on in an if statement), so that they can shut up and go back to writing code. There's no rational way to decide trivial questions like "how much white space should we use," so rather than having people engaging in pointless holy wars over two versus four spaces, we just establish a convention and stop talking about it. It really does make life easier on a team if people are on the same page there, and there are plenty of tools that make it trivial for people to format their code so it conforms to the conventions.
Then there's the issue of "standards," which is a much larger, amorphous topic that probably shouldn't just be trivialized. Trying to encode them formally is probably madness, but when some person on your team writes a 245-line-long function or calls a method "getFoo" when it in fact writes a file to disk as a side effect, you do probably want to have a little chat during a code review to say, "Hey, yeah . . . so that's not really okay, even if the code functions correctly." That's what I think of as "standards:" the assumption that just getting things to work isn't the only thing that matters. And just throwing that out the window and saying "Anything goes so long as it works" is pretty suicidal if you're working on a team.
One thing is conventions around things like where curly braces go, naming conventions for classes and methods and different types of variables, how much whitespace to use where, and so forth. Most of these things don't actually matter at all, but code certainly is easier to read if everyone on a team follows the same ones (so that I know that Foo.bar() is a static method while foo.bar() is a method call on a local variable and _foo.bar() is a method call on an instance variable on the class, without having any other deep knowledge of the code). The point of conventions is basically to get everyone to stop bikeshedding about things that don't matter (like which line a curly brace goes on in an if statement), so that they can shut up and go back to writing code. There's no rational way to decide trivial questions like "how much white space should we use," so rather than having people engaging in pointless holy wars over two versus four spaces, we just establish a convention and stop talking about it. It really does make life easier on a team if people are on the same page there, and there are plenty of tools that make it trivial for people to format their code so it conforms to the conventions.
Then there's the issue of "standards," which is a much larger, amorphous topic that probably shouldn't just be trivialized. Trying to encode them formally is probably madness, but when some person on your team writes a 245-line-long function or calls a method "getFoo" when it in fact writes a file to disk as a side effect, you do probably want to have a little chat during a code review to say, "Hey, yeah . . . so that's not really okay, even if the code functions correctly." That's what I think of as "standards:" the assumption that just getting things to work isn't the only thing that matters. And just throwing that out the window and saying "Anything goes so long as it works" is pretty suicidal if you're working on a team.
The way I addressed your "standards" issue is to just reference the book "Code Complete (2nd edition)" http://www.cc2e.com/ and tell developers to follow all of those guidelines. It's a long book but well worth reading, and generally applicable to most any procedural or OO language.
For Java specifically our "standards" also incorporate the book "Effective Java (2nd edition)" http://www.informit.com/store/effective-java-9780321356680 .
For Java specifically our "standards" also incorporate the book "Effective Java (2nd edition)" http://www.informit.com/store/effective-java-9780321356680 .
Coding Standards don't solve every problem and should thereby not be implemented?
The truly evil thing about coding standards is what they do to your heart, your team’s heart. They are a little message that you are not good enough. You cannot quite be trusted. Without adult supervision, you’ll mess up.
No, they simply are conventions making it easier to communicate and understand each others code.
Please go write some code instead. You know who you are.
Yup.
The truly evil thing about coding standards is what they do to your heart, your team’s heart. They are a little message that you are not good enough. You cannot quite be trusted. Without adult supervision, you’ll mess up.
No, they simply are conventions making it easier to communicate and understand each others code.
Please go write some code instead. You know who you are.
Yup.
>No, they simply are conventions making it easier to communicate and understand each others code.
A 1 page coding standard picking which common conventions people use perhaps is making it easier to communicate, maybe.
A 10 page coding standard with lots of positive manual actions a coder must do at ever step that don't necessarily add to the process (I'm looking at contracts in private functions and hungarian especially), or that are outdated and not state of the art, is positively soul-killing to many people.
Most places need code reviews, not coding standards.
A 1 page coding standard picking which common conventions people use perhaps is making it easier to communicate, maybe.
A 10 page coding standard with lots of positive manual actions a coder must do at ever step that don't necessarily add to the process (I'm looking at contracts in private functions and hungarian especially), or that are outdated and not state of the art, is positively soul-killing to many people.
Most places need code reviews, not coding standards.
The real answer is "code review by peers."
Should you have a 100-page book of Coding Law that programmers must follow, on pain of firing? No. That's a demoralizing distraction.
Should you say this?
>> You decide if you can sleep at night with random code layouts and inconsistent variable names.
No. That's inviting each developer to leave a mess for the one who comes after them.
How about something moderate and - gasp! - subjective, like, "if your peers find your code confusing, you're doing it wrong?"
>> They are a little message that you are not good enough. You cannot quite be trusted.
I understand the sentiment here, but we're all capable of writing code that's clear to us right now, but isn't to others and/or won't be clear to us in the future. That's one reason why we have code review, and none of us should be ashamed to admit that we benefit from it.
Should you have a 100-page book of Coding Law that programmers must follow, on pain of firing? No. That's a demoralizing distraction.
Should you say this?
>> You decide if you can sleep at night with random code layouts and inconsistent variable names.
No. That's inviting each developer to leave a mess for the one who comes after them.
How about something moderate and - gasp! - subjective, like, "if your peers find your code confusing, you're doing it wrong?"
>> They are a little message that you are not good enough. You cannot quite be trusted.
I understand the sentiment here, but we're all capable of writing code that's clear to us right now, but isn't to others and/or won't be clear to us in the future. That's one reason why we have code review, and none of us should be ashamed to admit that we benefit from it.
Thank you. If your coding standard appeals to the aspergerish folks more than the neurotypical, it's probably going to sap the energy of the nerotypical and drain productivity out of the process.
This is absurd.
90% of the time of most devs is spent reading other people's code. Take any meaninful largish project - linux kernel, git, webkit, node. You will spend most of your time reading rather than writing. The least you can do to make this process easier is to conform to a reasonable pattern. Imagine a book that uses a different formatting every other paragraph. It's distracting and gets in the way.
I think the author is more against nitpicking on coding style. This is unfortunately necessary since most developers cannot even bothered to look at the code above and below to understand the style. If that is the case, how does one trust their code?
Coding standards is about basic discipline. If you followed the standard, I know that you are atleast smart enough (and more importantly friendly enough) for a real code review.
On a side note, if you spend most of your time generating new code, you get to set the coding standard. But others who change your stuff, should just follow your standard.
90% of the time of most devs is spent reading other people's code. Take any meaninful largish project - linux kernel, git, webkit, node. You will spend most of your time reading rather than writing. The least you can do to make this process easier is to conform to a reasonable pattern. Imagine a book that uses a different formatting every other paragraph. It's distracting and gets in the way.
I think the author is more against nitpicking on coding style. This is unfortunately necessary since most developers cannot even bothered to look at the code above and below to understand the style. If that is the case, how does one trust their code?
Coding standards is about basic discipline. If you followed the standard, I know that you are atleast smart enough (and more importantly friendly enough) for a real code review.
On a side note, if you spend most of your time generating new code, you get to set the coding standard. But others who change your stuff, should just follow your standard.
>Coding standards is about basic discipline. If you followed the standard, I know that you are atleast smart enough (and more importantly friendly enough) for a real code review.
Some coding standards are basic discipline. Others are overwrought bullshit that are a drain on concentration, spin up time with new employees, and a constant sap on productivity in order to make stuff a slight bit prettier.
Some coding standards are basic discipline. Others are overwrought bullshit that are a drain on concentration, spin up time with new employees, and a constant sap on productivity in order to make stuff a slight bit prettier.
The best thing to avoid a lot of style arguments is to have an automatic code formatter (on save, commit etc.) which takes care of indentations, spaces, braces and so on.
Of course, someone needs to set up the options first, but then, life is so much easier. Sometimes you'll miss the possibility to pad similar assignments to look nicely one after the second, but other than that, autoformatting rocks.
The only really tricky thing regarding autoformatters is styling array literals. For arrays like [1, 2, 3, 4] you want it in one line, but if the elements are longer, you may want to have each of them in a separate line.
Of course, this doesn't handle camelCase vs underscored_variables, but it's a feature to leave you the freedom (or accept some solution in the team).
Of course, someone needs to set up the options first, but then, life is so much easier. Sometimes you'll miss the possibility to pad similar assignments to look nicely one after the second, but other than that, autoformatting rocks.
The only really tricky thing regarding autoformatters is styling array literals. For arrays like [1, 2, 3, 4] you want it in one line, but if the elements are longer, you may want to have each of them in a separate line.
Of course, this doesn't handle camelCase vs underscored_variables, but it's a feature to leave you the freedom (or accept some solution in the team).
Do you know of one that works for Objective-C?
You know, if there's one thing I hate, it's a set of rigid coding conventions. They're the joy of the petty and officious and the bane of people who just want to get things done. This isn't an excuse to get rid of them altogether. It's an argument for not taking coding conventions so seriously.
I am ordinarily a big fan of articles pushing back against established best practices, but only because despite the sometimes whiny tone, they almost always bring something new and thought-provoking to the conversation.
This article does not.
This article does not.
Loosely related thoughts:
If I feel like it, I can tell my editor to display `underscore_functions` as `underscoreFunctions` without actually modifying the text. I don't feel like it.
Here's my official "coding standards":
Whitespace standards (as in "only spaces" or "only tabs" for indentation) are good. Use whatever's already there. Your VC system can probably handle it for you.
I consider standards for things that don't add ridiculous diff noise as "soft". I'd rather run a tool like sonar that can generate "hey, this is ugly crap" reports with blame annotations than reject commits for style violations. I'd consider rejecting commits for really nasty style violations that weren't covered by tests.
I'd also consider making people wear a monocle if they're going to be doing a bunch of "just style" edits. But meh.
On the other hand, a consistent codebase is a nice thing. If it's a large codebase, a very nice thing ... but it's more of icing on the cake than the cake itself. I don't want to eat a whole bowl of icing.
If I feel like it, I can tell my editor to display `underscore_functions` as `underscoreFunctions` without actually modifying the text. I don't feel like it.
Here's my official "coding standards":
Whitespace standards (as in "only spaces" or "only tabs" for indentation) are good. Use whatever's already there. Your VC system can probably handle it for you.
I consider standards for things that don't add ridiculous diff noise as "soft". I'd rather run a tool like sonar that can generate "hey, this is ugly crap" reports with blame annotations than reject commits for style violations. I'd consider rejecting commits for really nasty style violations that weren't covered by tests.
I'd also consider making people wear a monocle if they're going to be doing a bunch of "just style" edits. But meh.
On the other hand, a consistent codebase is a nice thing. If it's a large codebase, a very nice thing ... but it's more of icing on the cake than the cake itself. I don't want to eat a whole bowl of icing.
Python is perhaps rare (unique?) in having a single authoritative, uncontroversial coding standard (pep8). I'm pretty sure its existence solves more problems than it causes.
Go ships with a tool called gofmt which automatically formats your code to a particular convention. It's expected that you gofmt all code that is released publicly. It also solves more problems than it creates, even if I don't agree with all of its rules.
Go is much, much more strict than Python. Python is actually fairly forgiving when it comes to whitespace everywhere except for indentation. And for indentation, it doesn't complain as long as you're consistent (for both tabs vs. spaces, and if you choose spaces, consistent with the number of spaces).
Go, on the other hand, checks for many aspects of style at compile-time. If you include an opening brace on the same line, import a package that isn't used, define a variable that isn't needed... all of those will cause compile-time errors.
At first, it can get annoying - especially when you comment out a single line when debugging and then realize you have to make some other minor change elsewhere just to avoid one of the aforementioned style issues.
But on the other hand, I can't deny that it makes my own code cleaner, and it probably saves some errors down the line. Furthermore, it made my code more consistent with existing Go code right from Day 1, even when I was just learning the language. Furthermore, for anybody who wants to do any metaprogramming/code translation, having a more rigid syntax enforced by the compiler is very helpful.
Python doesn't do that. PEP8 is great, and I'm thankful that it's very widely followed. But it's much more powerful when these issues of "style" are made as mandatory as any other aspect of the language specification[1].
This "benevolent dictator" approach has its pluses and minuses, but having written Go code a short while now, I've come to appreciate some of its benefits in the case of coding style.
[1] Okay, so the Go language specification doesn't include all of these, and yes, there are two independent Go compilers. But we can say that it's "mandatory" in the same way that we can say that "Python" has the GIL, when in reality many implementations don't (Jython, Iron Python, etc.)
Go, on the other hand, checks for many aspects of style at compile-time. If you include an opening brace on the same line, import a package that isn't used, define a variable that isn't needed... all of those will cause compile-time errors.
At first, it can get annoying - especially when you comment out a single line when debugging and then realize you have to make some other minor change elsewhere just to avoid one of the aforementioned style issues.
But on the other hand, I can't deny that it makes my own code cleaner, and it probably saves some errors down the line. Furthermore, it made my code more consistent with existing Go code right from Day 1, even when I was just learning the language. Furthermore, for anybody who wants to do any metaprogramming/code translation, having a more rigid syntax enforced by the compiler is very helpful.
Python doesn't do that. PEP8 is great, and I'm thankful that it's very widely followed. But it's much more powerful when these issues of "style" are made as mandatory as any other aspect of the language specification[1].
This "benevolent dictator" approach has its pluses and minuses, but having written Go code a short while now, I've come to appreciate some of its benefits in the case of coding style.
[1] Okay, so the Go language specification doesn't include all of these, and yes, there are two independent Go compilers. But we can say that it's "mandatory" in the same way that we can say that "Python" has the GIL, when in reality many implementations don't (Jython, Iron Python, etc.)
I have little issue with complicated coding standards completely subsumed into the compiler.
If you make me manually do paperwork every day, I will quit your thing
If you make me manually do paperwork every day, I will quit your thing
[deleted]
I think he has a point. Rather than making coding standards where your organization adopts a "best practice", just try to write clean, understandable code. Folks who can mess up, will mess up: we've all seen unreadable "Hungarian Notation" code, we've all seen weird conventions (like all instance variables are prefixed with "my"). They don't help.
so, is it foo.getSize() or foo.GetSize(). Naming all instance variables my* might or might not be very useful, but naming some instance variables that way is defiantly harmful. The point of having standards and conventions is that you can just know what arbitrary and useless decision others have made, because it is not arbitrary, it is the standard.
There's standards and there's standards.
C allows you to place your braces, commas, other tokens and whitespace in whatever form you desire. I suppose there's no need to get anal over those.
But then there are standards such as assertions, avoiding type casts, and breaking functions into helper functions. Those have an effect on code quality by setting up guards for conditions and sentinels for invariants.
I've had my code blown up an assert call so many times that writing all the rest of the assert calls have cost nothing compared to the savings initiated by forcing myself to evaluate where my thinking went wrong as the assert failed.
Formatting coding standards, again, should probably be banished in favor of letting programmers express their thinking in form of how they format their code. I'm pretty sure the best programmers all have top-notch consistent formatting over all their source code files. And if the worst programmers don't, we have bigger problems than formatting.
C allows you to place your braces, commas, other tokens and whitespace in whatever form you desire. I suppose there's no need to get anal over those.
But then there are standards such as assertions, avoiding type casts, and breaking functions into helper functions. Those have an effect on code quality by setting up guards for conditions and sentinels for invariants.
I've had my code blown up an assert call so many times that writing all the rest of the assert calls have cost nothing compared to the savings initiated by forcing myself to evaluate where my thinking went wrong as the assert failed.
Formatting coding standards, again, should probably be banished in favor of letting programmers express their thinking in form of how they format their code. I'm pretty sure the best programmers all have top-notch consistent formatting over all their source code files. And if the worst programmers don't, we have bigger problems than formatting.
I've seen it both ways.
I worked at a company that cranked out 4,000 sites a year. The only way they could do that was by having implicit coding standards. Every bit of code you've written has already been done the same way by ten other developers, 1,000 times over.
It also made maintaining the sites super easy since within a few months you knew 99% of the layouts of every site which was built in the last three years.
On the flip side, for smaller agencies and smaller projects I agree with the author. Trying to impose standards actually hurts the process. Maybe I want to use LESS or some other technology which would vastly improve the code and process, but not make the code super easy to maintain for the next guy. If you only have a few hundred sites, this becomes more manageable.
Besides, do you impose standards on yourself when you're doing projects for yourself or for freelance work?
I worked at a company that cranked out 4,000 sites a year. The only way they could do that was by having implicit coding standards. Every bit of code you've written has already been done the same way by ten other developers, 1,000 times over.
It also made maintaining the sites super easy since within a few months you knew 99% of the layouts of every site which was built in the last three years.
On the flip side, for smaller agencies and smaller projects I agree with the author. Trying to impose standards actually hurts the process. Maybe I want to use LESS or some other technology which would vastly improve the code and process, but not make the code super easy to maintain for the next guy. If you only have a few hundred sites, this becomes more manageable.
Besides, do you impose standards on yourself when you're doing projects for yourself or for freelance work?
I'm sorry but no. You can't go wrong with PEP8 for Python and JSHint or something similar for Javascript. Neither of those standards are that rigid and there are tools for most major editors that highlight non-conforming lines as you're coding. Please, put semicolons at the end of your statements.
"Social problems are hard to solve so just ignore them and wing it"?
Not a recipe for success in my experience.
Not a recipe for success in my experience.
I think I prefer the idea of the style guide, which you might argue is a coding standard, but the use of 'guide' allows for a bit of lenience.
Moreover, I think one of these things is missing the point if it's entirely about syntax, whitespace, and whatever else can make the code appear readable on the surface. There's no substance to this and the code can still be shite while being 100% conformant. It'll just be formatted nice.
What a standard/guide should try to do is serve the dual purpose of educating or informing people about good practices, both in general and while being language specific. Some might disagree or find it patronising, but even if it's only encouraged by colleagues or peers, it can be the sort of thing that makes you think twice about the code you're about to commit.
By the same token, using a style guide for that should never be a replacement for a good, collaborative work environment. This is essentially a people problem after all.
Moreover, I think one of these things is missing the point if it's entirely about syntax, whitespace, and whatever else can make the code appear readable on the surface. There's no substance to this and the code can still be shite while being 100% conformant. It'll just be formatted nice.
What a standard/guide should try to do is serve the dual purpose of educating or informing people about good practices, both in general and while being language specific. Some might disagree or find it patronising, but even if it's only encouraged by colleagues or peers, it can be the sort of thing that makes you think twice about the code you're about to commit.
By the same token, using a style guide for that should never be a replacement for a good, collaborative work environment. This is essentially a people problem after all.
Just plain wrong is all there is to say about this article in my opinion. That said I don't believe that style requirements need to be hyper rigid, they should just prevent people from writing code that is entirely unreadable for no apparent reason.
I can't say I've ever been restricted by a rigid standards document. I do however, attempt to use recommended/best practices for standards in my own code. For the most part I can also say that if others would do the same, it would make me more efficient when maintaining their code.
As far as JavaScript, IMO jsLint is a wise tool to have and use for any project with more than two developers. But by all means, if someone thinks that it's not 'moving the needle', do a double blind study and show us the results. Somebody else, and what they believe worked best in their experience, doesn't really resonate with me unless I'm looking at some hard data that backs it up.
As far as JavaScript, IMO jsLint is a wise tool to have and use for any project with more than two developers. But by all means, if someone thinks that it's not 'moving the needle', do a double blind study and show us the results. Somebody else, and what they believe worked best in their experience, doesn't really resonate with me unless I'm looking at some hard data that backs it up.
Basically, what he's saying is "I don't enforce coding standards because my programmers are smart enough to choose one by themselves".
Seems to me that what you need more than the standards are the reasons behind the standards - because yeah, the person coding that particular problem knows more than you about that problem, and should /teach you what they know/, particularly when it's easy.
That doesn't work at all when it's religion.
Using spaces for indentation is a sin against humanity, but that doesn't mean that someone else isn't going to come along and believe otherwise and no argument you make will sway them.
Using spaces for indentation is a sin against humanity, but that doesn't mean that someone else isn't going to come along and believe otherwise and no argument you make will sway them.
Well, but then your problem is religion, not coding standards. And then it'll be over this or that design pattern, coding paradigm, version control commit logs....
If you name the problem "coding standards" and it's "religion", you'll solve the wrong problem and of course it won't work.
If you name the problem "coding standards" and it's "religion", you'll solve the wrong problem and of course it won't work.
go write some code, don't write blogs.. then.. work with some other guys and theeeennn let's talk about coding standards
I would never write such a story about something like "don't use conventions"...
I didn't read the entire article because I am not a novel fan
I didn't read the entire article because I am not a novel fan
Standards suffocate me, as any restrictive device should. Even knowing their importance, especially in mission critical roles such as aerospace and medical, it is hard to reason that all the time and creative energy spent on most standards is worth it. Especially since standards evolve by being broken or ignored, creating flux that makes the standard meaningless.
I think the need to form standards are a symptom of poor tools and methodologies for software development.
Robust software needs to be built using first principles. Instead of forming standards in such situations to enforce coding style, we should be improving our tooling, and not be writing code at all. The tools are the standard.
Code is a creative free form medium, and ignoring its raison d'être means killing what it is. If you need precise coloring within the lines, build and use the right tool - a printer. Don't enforce arbitrary rules on using crayons.
I think the need to form standards are a symptom of poor tools and methodologies for software development.
Robust software needs to be built using first principles. Instead of forming standards in such situations to enforce coding style, we should be improving our tooling, and not be writing code at all. The tools are the standard.
Code is a creative free form medium, and ignoring its raison d'être means killing what it is. If you need precise coloring within the lines, build and use the right tool - a printer. Don't enforce arbitrary rules on using crayons.
This is ridiculous; there's certainly a place for creative code. It's an obfuscated code competition. Yes, you can write a BrainFuck interpreter in the C preprocessor. If it was your job, would you do it that way? Would you saddle other people with the work of maintaining your implementation?
The second half of your argument is equally vexing. Yes, ideally tools would turn intent into actions. We would think, or express what we want at some high level, and it would come into existence. That's not how the real world works. Painters need to use a brush, musicians need an instrument, or at least sheet music.
Some would argue that brushwork is like coding style. But the thing is, do you want to work on a team of Jackson Pollocks?
The second half of your argument is equally vexing. Yes, ideally tools would turn intent into actions. We would think, or express what we want at some high level, and it would come into existence. That's not how the real world works. Painters need to use a brush, musicians need an instrument, or at least sheet music.
Some would argue that brushwork is like coding style. But the thing is, do you want to work on a team of Jackson Pollocks?
clearly, this person has never had to write code within a many-hundred thousand line perl library.
There are certain parts of the spec I dislike, but I thank god everyday I have to look at a new file, because it allows me to focus on what and how the code accomplishes its goal as opposed to minutia like how are arguments passed between functions/methods, what is the naming convention for variables, how are return values returned, or even just do i need to tab indent or space indent in this file?
There are certain parts of the spec I dislike, but I thank god everyday I have to look at a new file, because it allows me to focus on what and how the code accomplishes its goal as opposed to minutia like how are arguments passed between functions/methods, what is the naming convention for variables, how are return values returned, or even just do i need to tab indent or space indent in this file?
I use Google's R Code Standard in my code and cut my productivity in half.
I disagree... Because of the tools we have! If only our regular diff tools were able to work on semantic units then we could maybe be laxer on coding standards.
Once again Google got it right in their Go language: there's an official spec as to how formatting should look like and there's a utility, gofmt, which does format the code according to the language's standard way of doing thing and this is a Good Thing [TM].
Coding standards should be directly into language specs and then a "dictator" should mandate compliance with the coding standards before committing (use a hook or whatever suits you) to the (D)VCS.
Now of course you should be able to check out and see, in your editor, the code formatted as you prefer to see it. And it should cause no issues as long you re-format according to coding standards before committing.
This is all pointless ranting anyway: it all comes down to the same age-old issue that we're using text files to represent source code and that these text files can contain structurally incorrect source code.
It's all about the tools. Our tools (editor, (D)VCS, diff tools, etc.) do all really s*ck.
As long as we'll be using such inferior tools to craft our code we'd better have sound coding standards.
I'm pretty sure Google and their Go's gofmt are on to something.
As a side note, OP's rant about chaos that should be reigning king regarding coding standards in a codebase falls pretty flat if you're a Go programming team: the entire Go standard packages have been formatted with gofmt and you'd need something much better than the OP's rant to convince a manager that people shouldn't be using gofmt before committing their code...
Once can only hope language-to-come do not only mandate a very precise coding standard in the language's spec but does actually enforce it (e.g. by refusing to compile a source file that isn't properly formatted).
Once again Google got it right in their Go language: there's an official spec as to how formatting should look like and there's a utility, gofmt, which does format the code according to the language's standard way of doing thing and this is a Good Thing [TM].
Coding standards should be directly into language specs and then a "dictator" should mandate compliance with the coding standards before committing (use a hook or whatever suits you) to the (D)VCS.
Now of course you should be able to check out and see, in your editor, the code formatted as you prefer to see it. And it should cause no issues as long you re-format according to coding standards before committing.
This is all pointless ranting anyway: it all comes down to the same age-old issue that we're using text files to represent source code and that these text files can contain structurally incorrect source code.
It's all about the tools. Our tools (editor, (D)VCS, diff tools, etc.) do all really s*ck.
As long as we'll be using such inferior tools to craft our code we'd better have sound coding standards.
I'm pretty sure Google and their Go's gofmt are on to something.
As a side note, OP's rant about chaos that should be reigning king regarding coding standards in a codebase falls pretty flat if you're a Go programming team: the entire Go standard packages have been formatted with gofmt and you'd need something much better than the OP's rant to convince a manager that people shouldn't be using gofmt before committing their code...
Once can only hope language-to-come do not only mandate a very precise coding standard in the language's spec but does actually enforce it (e.g. by refusing to compile a source file that isn't properly formatted).
I think if specifed at the language level (pep8/python, gofmt/go, objectiveC/apple docs), that's one thing. Additionally, if you have complete tool support for your format, you can demand much much more from the programmer.
The issue is making a guy constantly REMEMBER, Keep in mind, and implement something NOT enforced by a compiler is a huge sap on a certain type of person.
The issue is making a guy constantly REMEMBER, Keep in mind, and implement something NOT enforced by a compiler is a huge sap on a certain type of person.
In the medium case its fine, you'll get folks who write code using a 'common' coding style and for the most part switching between them will be not too difficult. I've observed over the years that a noticeable number of bugs will be introduced by people who didn't read the code correctly.
The place it will go off the rails is when you hire 'that guy' (and it always seems to be a guy) who writes lots of code, and it works, but for reasons that only he understands he only writes it on one line. He likes every function to have its own line, that way he can just use the 'down line' command to get to the next function. And he doesn't really comment anything except sometimes in the middle he'll start a comment between the code that does something and code that doesn't. And someone will have a problem and it will be in this guy's code and they will come to you because they can't read that code and they aren't going to check anything in like that.
At this point a number of entirely predictable things happen. Let's name the players, "Crazy Coder" (CC) who has the bizarre style, "New Guy" (NG) who is asked to fix a bug in CC's code, and "Manager Guy" (MG) the person responsible, ultimately, for all the code.
First there is a blow up when NG takes CC's code, runs it through a pretty printer and reformats it into something they can read, fixes it, and then checks it in. CC has a huge fit that their code has been made "unreadble" by NG and they go back, rewrite all the code that had been reformatted including the NG bug fix, except they won't quite get what NG was fixing and so CC's version of NG's fix won't actually fix the problem. Now NG will be have their bug re-opened because their fix doesn't work.
Now typical escalations are NG assigns the bug to CC since CC won't tolerate his code changes. NG will reformat a big chunk of CC's code just to piss him off. CC will rewrite chunks of the system to invalidate previous fixes by NG and others.
Now as the outlier, MG might want to tell CC to 'change' their coding style to something a bit more standard. They won't. They will insist either there is a coding style or there isn't, if there isn't then there isn't a problem, if there is then everyone has to follow it. And the coding style dilemma will be served up front and center.
Coding style requirements become the lesser of two evils.