Why I Have Given Up on Coding Standards

Every developer knows you should have a one, exact, coding standard in your company. Every developer also knows you have to fight to get your rules into the company standard. Every developer secretly despairs when starting a new job, afraid of the crazy coding standard some power-mad architect has dictated.

It’s better to throw coding standards out and allow free expression. The small win you get from increased conformity does not move the needle. Coding standards are technical ass-covering. At nearForm I don’t want one, because I want everyone to think for themselves.

There’s a lot of noise out there. The resurrection of JavaScript is responsible. One “feature” in particular: optional semi-colons. Terabytes of assertion, conjecture and counter-argument are clogging up the intertubes. Please go write some code instead. You know who you are.

Well-meaning, and otherwise fabulous developers are publishing JavaScript coding standards and style guides. You are all wrong. Stop trying to save the world.

Here’s what’s happening: when you started coding you had no idea what you were doing. It was all fun and games until you lost an eye. Once you hurt yourself one too many times with sloppy code, you came to understand that you were a mere apprentice. Starting on the path to master craftsman, you soaked up Code Complete, The Pragmatic Programmer, and of course, Joel.

And then, it happened. On the road to Damascus you gained insight. Your new grab bag of tricks would make you a rock star programmer. Your productivity had already doubled (looking back, that’s hardly surprising). And now you needed to spread the word. What worked for you will save others. You cajoled, you preached, you pestered. You lectured your boss on the need for best practices and standards. And most unforgivable of all, you blogged.

Most developers don’t make noise. Those who make noise, get promoted. You got promoted. You imposed your brilliant ideas on others, certain of victory. You wrote a coding standards document, and you made it law.

And then, nothing. The same old slog, the same death marches, the same bugs, the same misery. No silver bullet.

After a few years, you stopped coding and became a manager. You still know that coding standards, rules and regulations are vital. All it requires is proper implementation. You’ve never quite got there, but you’ll keep trying. Hit ‘em over the head a bit more. Code metrics! In any case, as a manager you get to delegate the pain away.

There is another road. Perhaps you went back to coding, or never left. Over time you came to realize that you know so little, and all your wonderful ideas are sand castles. You’re washed up. This is the next level of insight.

Other people are smarter than you. Not some of them. All of them. The coder writing the user interface? They are smarter than you … about the user interface. You’re not writing the code. Why don’t you trust them? No, that’s not the right question. They will still mess up. Why are you making a bigger mess by telling them what to do?

You get to the point where you understand that people are not machines. You need to push intelligence out to the edges. You need to give up control to get the best results.

So why do most intelligent coders do exactly the opposite? What makes us such ready dictators?

First, you transfer your own experiences onto others. But not everybody thinks like you. Brains are pretty weird.

Second, control feels good. It’s a comfortable hole in the sand. But you can’t tell coders what to do. Cats don’t herd.

Third, you get to duck responsibility. Everybody on the team does. We followed the rules! You failed. Yes, but we followed the rules! Well in that case, here’s another project…

Fourth, good intentions; best practices; professionalism; engineering – the seductions of process. You are chasing the same gold stars you got when you were eight years old. But how is the master craftsman judged? By results, only.

Fifth, idealism, the belief that you can understand the world and bend it to your will. Something we’re pretty good at as a species … after we fail a thousand times, and with repeatable processes. Software projects are always one of a kind.

There are worse sins than these. You only need one of them to end up with a coding standard.

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.

We started nearForm about a year ago, and one thing we really care about is writing great code for our clients. In earlier lives, I’ve tried all the processes and methods and rules of thumb. They all suck. None of them deliver.

Starting with the principle that our coders are really smart. That does work.

I expect everyone to write good clean code. You decide what that means. You decide if you can sleep at night with random code layouts and inconsistent variable names. But you know what, maybe they just don’t matter for a 100 line node.js mini-server that only does one thing. You decide.

It is your responsibility, because you can code.

This entry was posted in Uncategorized. Bookmark the permalink.

275 Responses to Why I Have Given Up on Coding Standards

  1. Edmilsom Carlos says:

    Wow! It looks like you are saying that Anarchy is the key to success in the software development business. This is cool! I like the idea!

    • Branno says:

      Anarchy? Seriously?

      Come fucking on

    • Jeremie Pelletier says:

      I wouldn’t call this anarchy as much as I’d call it freedom. It’s the same thing happening to open-source projects: developers are free to choose their own project, free to choose their own coding standards, free to do anything they want.

      It forces critical thinking, you can no longer merely follow orders to get your job done since nobody is there to give them to you. You’re no longer a replaceable mindless drone but an actual engineer. If you’re able to think on your own, what good is management then?

      Programming is an art form first and foremost. By giving your artists their own freedom they will almost always surprise you in ways you never could expect. As with all other art forms, there is a process of natural selection: the good always stands out from the bad at the end of the day.

      • Ken says:

        Great comment.

      • Doug Blake says:

        Programming is NOT an art form. As a developer of medical equipment you would want to KNOW that what I produced was specified, implemented and tested to the nth degree. NO atristic license allowed. You web site jockeys have no idea!!!

        • Richard says:

          Like your comment. It made me smile (wryly!)…

        • araybold says:

          To Doug Blake: I agree with the sentiment but only conditionally with the conclusion. Coding standards that obsessively specify code layout and identifier naming cannot solve problems that matter. Writing correct code requires analytical thinking, something that the painting-by-numbers style of coding standards cannot substitute for.

        • Tony Marston says:

          > Programming is NOT an art form.

          Computer programming is an art, not a science, therefore it cannot be taught to somebody who does not have the necessary talent. A program may be required to achieve a certain set of results, but the program code can be written in an infinite number of ways. Provided that the program produces the correct result how it is written should be irrelevant except for the fact that it should be readable and maintainable by others.

          • Peter says:

            “[...]except for the fact that it should be readable and maintainable by others.”

            This is kind of the point of why we use coding standards.

        • JulesLt says:

          Things I have encountered in real life – as the coding standards specified that all numbers should be represented by constants, constants named ‘CODE_FIVE, CODE_SIX, CODE_SEVEN’, etc – rather than something meaningful.

          This code was developed by one person, and reviewed by another, neither of whom obviously understood the point behind the standard.

          And this is something I have seen frequently – an obsessive focus on surface quality, while not questioning what the code actually does.

          Now arguably, there is a good correlation between surface defects and deeper ones – I don’t think it takes too long for a good developer to learn and adhere to a coding style – it’s just a language dialect.

          The presence of a large number of surface defects may be a good indication there will be deeper defects.

          But the corollary is not true – eliminating all surface defects is unlikely to eliminate the structural ones.

        • nafSadh says:

          @Doug Blake:
          Ever heard of the seminal book “The Art of Computer Programming” of D.A. Knuth?

        • Joshua A. Schaeffer says:

          Unfortunately you are a niche programmer and the market will never wait for you to test to the nth degree to produce rapid iterations on non-real-time applications. Your approach is vital for your domain but hilarious to the Cloud and absolutely fatal to a startup.

      • David Stanek says:

        Have you worked on an Open Source project before? The ones I work on all have some sort of coding standards and if I want my contribution accepted I need to follow them.

      • James says:

        “Programming is an art form first and foremost. By giving your artists their own freedom they will almost always surprise you in ways you never could expect….”

        Well said.

        • CodeMachine says:

          When coding/programming allowed to be an expression resembling art, the real propeller heads(engineers) say: WTF am I supposed to work on this shit.

      • And it’s not just to understand this, it’s that everybody in the company knows that it is the way things are done.

    • Mark Over says:

      Come on, this comment comes from someone whose crystal castle built out of a few authors’ preaching has been shattered. It comes from someone who didn’t read the article, or didn’t understand it, but makes such a remark to make the author look stupid.

      Probably he will blog some ridiculous post somewhere with nonsense comments about it, defending the ideas of the preachers he follow blindly. The same preachers who were made rich by defending ideas and selling books for poor programmers like the author of this comment. Because, as programmers, they were doing just like the average blue-collar worker, and as preacher authors their are millionaires and rock stars.

      Why don’t you quit programming and write a book, put videos on internet and become another one of those “preachers”?

  2. The advantage of a code-standard for structural layout is that you can then have plugins/tools that do the layout for you. No more do you edit a file and get a ginormous code change because your vi settings rewrap the code differently than the previous guy.

    It’s not about getting your way with code-standards, it’s simply about not having to argue about it anymore on each and every code-change.

    • userulluipeste says:

      So the coding standard is something that is reduced to customizable code wrapping to you?

    • Jeremie Pelletier says:

      This assumes layout tools to be a good thing. Many people see them as a language smell, myself included: if your language requires tools to be practical, there’s a good chance the language is crippled to begin with.

      • Yannbane says:

        Yeah, I wont point out the elephant in the room… But anyways, it’s not Java’s fault, but the developers’.

      • The language smell argument is debatable, but in any case you don’t always have a chance to pick the language. Coding standards allow good developers not to worry about coding standards, and allow some great tools to be used across the whole code base.

    • I don’t advocate messy code at all. Good clean code is something that arises organically if you respect people’s intelligence, so long everybody knows it’s expected.

  3. Doug Sims says:

    I strongly agree with this. I’m all for coding standards – code should be efficient and correct – but the obsession over arbitrary formatting details is just noise that detracts from the important parts. If code is correct and efficient then it doesn’t really matter whether it’s indented two spaces or three. If it’s NOT correct and efficient then formatting doesn’t matter either. If you care that much about formatting details then use a tidy program (e.g. http://perltidy.sourceforge.net/).

    • Asko Nõmm says:

      I agree. Coding standards are a must and without that we’d still be writing HTML in caps-lock. Just because some idiot thought it should be that way.

      • rok says:

        I agree also. But today we’re writing HTML in lower case because some idiots thought it should be this way. The point is, does it really matter if the HTML is upper or lower case if the page works perfectly?

        • John says:

          Actually it does make a difference. Lower case and even more so, camel case, is much easier for humans to read given the varying height and shape of the letters. E.g.

          SOMELONGVARIABLENAME
          SomeLongVariableName

          • CjL says:

            This example is Pascal case, camel case would have a small first letter: someLongVariableName

            However, it is all semantics – just give me good readable code where I as a debugger can understand what has been coded and why, so when I come to fix your mistakes it is easy to spot them.

      • Anonymous Coward says:

        Coding standards make sense as a commonly agreed convention in a team or a company, not as a convention shoved up your ass by management. And they definitely don’t make sense unless regularly questioned and reviewed. It may even be that depending on the code you write some rules in the coding standard are stupid, while some rules you’d like to see enforced are stupid for other code.

        The worst coding standards related issue I’ve had is with a coding standard being nazistic about formatting, imposing formatting rules which can’t be implemented by using pretty (y’know, the command line reformatting utility available on *n*x-es – semantic-related rules). Having programmers check every line of code for conformance to some formatting standard manually is a stupid and annoying waste of resources, and actually is looses some important benefits of a coding standard.

    • Richard says:

      “If you care that much about formatting details then use a tidy program ”

      Or program in Python! :-))

    • If the team decides to use a formatter. It can’t be dictated.

  4. David Mc says:

    I agree in principal about coding standards are not a silver bullet. However there has to be conformity at some level or else it is just chaos. For me coding standards are less about the formatting of the code but more about a developers willingness to conform for the common good.

    If a developer can’t be bothered to camel-case a variable name or not prepend “str” to every string variable then what else aren’t they doing? Could I trust such a developer not to be doing other horrific practices that wont cause massive issues in the application? Am I going to look one day and find my database is crashing because the same developer who wont format their braces properly also can’t be bothered closing database connections?

    Rock star rebels are all very well and good, but ultimately saying you are going to drop coding standards is like saying you are going to drop basic office etiquette. So you can’t really complain when you are sat next to a dishevelled developer with his bare feet up on the table reeking of BO…because hey…dress codes and personal appearence are no silver bullet that you’ll get make good applications either.

    Get me?

    • Dan A says:

      Dropping formal office etiquette is probably a good idea in this context as well.

      The point is about trust. I think trusting your employees to bathe, resist telling sexist jokes, etc in an office environment (sometimes referred to as having common sense) is a given. If its too hard for them then maybe this isn’t the kind of person you want working for you.

      Likewise, if you can’t trust your developers to write good, maintainable code without a some rigid set of rules then you might be better off finding other developers.

      • David M says:

        Yes but when you go to fire said employee’s who tell sexist jokes, smell bad and write poor code how do you justify this if you don’t have a set of rules that they have broken? “I’m firing you because you wear offensive t-shirts with swear words on them”….”but you don’t have a dress code? show me in the rules where it says I can’t…I hope you have a good lawyer”.

        I agree ridgid standards where you have someone standing over you with a rule stick slapping your hands when you do something deemed to contravene the coding standards is not helpful.

        There has to be some standards though, even if they are just guidelines.

      • Anonymous Coward says:

        I’m all in favor of telling sexist, racist or all other sorts of politically incorrect jokes. Hearing such jokes from coworkers and not feeling offended is a manifestation of trust. If for example you tell a blonde female coworker a joke involving blondes, and she can’t trust that you’re just joking, there’s no trust. Also, if she feels offended in any way, she has some serious issues of self-esteem and confidence in herself – which both she personally and the team around her should deal with, rather than avoid addressing them. (Or she has some serious lack of sense of humor, which is IMO reason enough to not have hired her in the first place – I’ve never seen a person without a sound sense of humor make a good team member in a software team.)

    • There are such things as spelling standards. Why would anyone trust the opinion of a fellow who can’t figure out the difference between “principle” and “principal”?

      Sorry, but you were asking for it :-)

      • Anonymous Coward says:

        IMO you’re comparing apples with oranges. There’s the compiler which checks for such mistakes. Coding standards often have rules like ‘start every sentence with “Simon says”‘ – to stick to the analogy with natural language. That’s what you don’t want enforced unless it makes sense in your particular context. And the best people to judge whether it makes or doesn’t make sense are the people tasked with applying the standard, not management. You first build a well-knit together team, then let it develop its own coding standard, not have management or some star programmer develop the standard and then force the productive dev team to use it – if you want the standard to be useful, that is.

        • James says:

          “You first build a well-knit together team, then let it develop its own coding standard, not have management or some star programmer develop the standard and then force the productive dev team to use it – if you want the standard to be useful, that is.”

          Good point. I would say though that a good coding standard is an evolving piece of work as the project is also evolving. I’ve experience success by shifting the paradigm like so: have a star programmer or just a central coding standards developer. Have this person develop out the standards to the best of their knowledge and then have it evaluated by the other team members while also taking input for additions or changes. Make sure those standards are “effectively” disseminated to everyone and keep an open and ongoing chain of discussion on additional standards or changes to the standards that all team members discover as the project evolves. The key is to be agile and make changes to the standards which do not take much time away from developing out the project.

      • David M says:

        I usually rigorously check my spelling and grammar and the one time I dont due to time constraints I get owned! Well played sir.

        However my point I think whether in principal or principle is still valid. There has to be something to pull together a code base and as someone else pointed out this is better achieved as a group consensus rather than a rock star programmer dictating the rules.

        The title of this blog is a headline grabber but really is like saying “Why I’ve given up on deodorant”. The reality is he hasn’t given up on it he’s just making a controversial statement.

        It sounds like something my emo nephew would come out with.

    • Messy code is not something any team should accept. A convergence of style that arises organically when an expectation of professionalism is set is far more valuable in the long term.

      • So when fifteen new programmers show up with their own styles, how long do you expect to give them to fit into the existing standard your workers already have? And how annoyed will those workers be at having to work around the new random styles cropping up?

        Coding standards, when properly implemented actually make employees more free, not less. Free to code instead of having to spend time figuring out where the bug is in someone else’s nested ifs.

  5. Gary Geck says:

    I basically agree with this article. I see it as the study of the so called “informal logical fallacies” (appeals to authority, red herring, …etc there are over 40 of them documented). These logical fallacies are good for a beginner in philosophy or in thinking. They are ideal in the education of young adults. But once they are ingrained in us, we won’t commit them. The goal is not to abide by them as rules, but to get the spirit of them to become intellectually honest to others and ourselves.

    The red herring is a fallacy where we distract the discussion using irrelevant info. But how annoying is it when we have some newbie accuse us of making a red herring logical fallacy when they just don’t understand the relevancy of the information we’re giving them. Sometimes it takes a while to properly build up an argument. And this is another: they are INFORMAL logical fallacies. They are just suggestions, not absolute truths. The same goes for coding standards which might be better than lame n00bs but is never perfect. Coding standards are INFORMAL despite what n00bs may think.

    • Gary Geck says:

      ps I mean once we have them engrained in us, we no longer need to think about them as rule per se…we can really forget them and we won’t commit them…

    • cmdicely says:

      And this is another: they are INFORMAL logical fallacies. They are just suggestions, not absolute truths.

      The “informal” in “informal logical fallacy” doesn’t mean that it is a “suggestion”. It distinguishes fallacies that relate to the specific content of an argument (“informal fallacies”), from those that deal with the structure of the argument (“formal fallacies”.)

      Coding standards are INFORMAL despite what n00bs may think.

      Coding standards are “formal” in the sense the term is used to distinguish “formal fallacies” from “informal” ones (in that they deal with the form of the code, irrespective of its specific content), and, quite often, in the sense that they are requirements imposed by binding authority, as well.

      So, while I actually agree with the idea that rigid coding standards are more counterproductive than beneficial in most cases, your raising of informal logical fallacies and tying your argument on this point into the word “informal” as it relates to logical fallacies is a distraction that is counterproductive to your argument.

      • Gary Geck says:

        Informal fallacies deal with semantics. Formal fallacies are precise according to syntax rules. But when one tries to use informal fallacies as a purely syntactic rule, they fail because rules cannot find informal fallacies, only people can who understand the semantics. They’re vague and they can be misinterpreted as a result.

        I see coding standards as mainly semantic. A person can see they they are obeyed or not but a machine cannot. But you’re right that the simple coding standards are also syntactical. For example, beginning a variable with a lowercase letter.

        • Gary Geck says:

          PS. so a better analogy would be someone who reads a book on how to make friends and does everything in an empty, algorithmic way…but after doing this a while, they don’t need to think about the rules any more…they just can be more natural and succeed…

        • Gary Geck says:

          And I am not saying that formal fallacies are only snytactic…nor do i believe that formal paradoxes are void of semantics either….I believe that mathematical logic is not just syntax rules but has actual real meaning…but it can be recognized syntactically is what I mean…

    • Yes, knowing when to break the rules is the next level up. A strict set of coding standards creates a glass ceiling that not only prevents people from reaching this level, but also tells them they’re not good enough anyway. Hence, bad.

  6. Inori says:

    It might work if you have a team of senior developers, who will unknowingly follow a CS anyway. I bet you do too.

    In a more realistic world filled with junior (and even mid-level) developers, good luck reviewing code like this:

    function coolFunction_here () {
    if ( true == FALSE)
    {
    var i_like_tabs = true;
    var butSometimesIAlsoUseSpacesForGiggles = true;
    }

    }

    • Ryan says:

      I agree completely with Inori. I work on a Python team now where everyone is actually coming from different backgrounds. One guy names methods and variables both inFirstLowerCamel, another uses lowernoseparator for variables and lower_with_unders for methods and then there’s the guy who must think you get bonus oints for using a few characters as possible. And that doesn’t even account for all of the module and package names. Luckily in Python we have . That is exactly what I want in a coding standard. Not overbearing or draconian but simply trying to get everyone on the same page.

      • Nick says:

        So people use upper case or lower case or underscores? So what? Do you think the compiler (or interpreter) cares?

        Concentrate on getting the code right.

        • Anonymous Coward says:

          The compiler is not a human. Typically, a piece of code is written once, then read 1000 times until it is scraped. By not using some sensible formatting you add comprehension effort to every one of the 1000 reads. That’s unreasonable.

          • Doug Sims says:

            if you read a lot of code (other people’s open-source work) then you should be used to minor differences in formatting and such anyway. And if you don’t read a lot of other code then you should. I agree with Nick (above) – concentrate on getting the code right.

      • Anonymous Coward says:

        What you’re telling us is that at least many people on the team don’t stick to best practices which aren’t tied to a particular standard – using descriptive identifiers, for example. Also, if the team has no strong team ties, so that the problem gets identified and a naming convention agreed upon all team members emerges, you have a bigger problem than no coding standard. Enforcing a coding standard, even if it is a reasonable and sensible one, won’t get your group of people actually aggregate into a team.

      • Jeremie Pelletier says:

        I really don’t see how enforcing these makes for a more productive development pipeline.

        If you care about indentation, use a language where its semantically meaningful such as Python, Haskell and CoffeeScript or use formatting tools. This is a non-issue: programmers who don’t pay attention to such details usually aren’t good programmers to begin with.

        If you care about nomenclature, use a language where its actually meaningful, such as Haskell. Again this is a pretty useless enforcement, who cares if a variable in a private method isn’t named properly? Nobody is going to read the code anyways and if anyone ever does they’ll pick up the meaning within a second (or else hire yourself a better developer.)

        • someone says:

          > Nobody is going to read the code anyway..

          THIS…. If your code is write-only, you don’t need standards.

          But, I assure you, that for a lot (vast majority?) of projects, maintenance (that is readability) of the code IS a primary concern.

        • Marcel Valdez says:

          So if you’re writing embedded systems, you should not use C, and change to Python, Haskell or CoffeeScript?

          If an inexperienced programmer (but a great algorithm solver), writes code without good style because doesn’t know any better (yet) should be either fired or dismissed?

          Nobody is going to read the code? Are you kidding me? Did you come from 1995 and start posting into the future with some kind of auto-time-capsule? Seriously, please do yourself a favor and Google: software engineering.

          Any decent software shop does code reviews where any code has to be read by 2 other persons. Without any coding standard every member might spend 2, 3 or more times reading the code if they have to decipher which variables/methods/classes are private, protected, public, global, constants by having to scroll back and forth in a 2000 line code file (no coding standard, remember?).

          The point this post is trying to make, is that coding standards should be standards, they should be guidelines.

          • Marcel Valdez says:

            shouldn’t be standards*

          • James says:

            “Any decent software shop does code reviews where any code has to be read by 2 other persons. Without any coding standard every member might spend 2, 3 or more times reading the code if they have to decipher which variables/methods/classes are private, protected, public, global, constants by having to scroll back and forth in a 2000 line code file (no coding standard, remember?).”

            “Scroll back and forth in a 2000 line code file”
            Word! I had to do this and make changes extremely fast, and be 100% accurate that these changes were not going to destroy any other parts of the code base. And there were no comments to why the cascading if, elsif, else statements were made. Nor was there even the notion of a standard to anchor off of. It took 8 months to finally get some documentation standards Incorporated into our code base, but once they were it cut down about 4-5 hours of time per bug fixes we were making. It also allowed for the next kids we were training for our code base to have a good jump start in learning on their own how to make changes with good pieces of information about the code and the decisions made in developing out the code base.

        • Prophet says:

          Dr Pelletier seems to have a distorted view of reality, as the majority of the academic world does (alas, that was the way things were for me as well). In the real world, where people try to build software, there exist bad programmers with whom we have to deal with. There is also much reading and rewriting and maintenance of existing code.

          Both your points are moot, sir.

        • Richard says:

          “Nobody is going to read the code anyways and if anyone ever does they’ll pick up the meaning within a second…”

          Trust me, that person could be you in five years time! – long after you’ve forgotten what all that inconsistently named and patchly documented code does. You’ll find yourself asking, “Did I write this gobbldygook?”

      • Gary Geck says:

        perhaps syntactic coding standards are good…but semantic coding standards are too rigid and only good programmers are allowed to write code?

      • “The road to hell is paved with good intentions”

    • Prophet says:

      Put it through a formatting tool; indent, gofmt, PEP-8-enforcer, you name it. Then commit it.

      You are welcome.

    • Tez says:

      I would be surprised if a single developer used multiple styles for variables. However, as long as the variables and methods are well named it is easy to understand.

      Try reading code like

      function ticket1234 (t1,t2,ccc)
      {
      var t3 = new ccc(t2);
      var tValue = t3.convert(t1);
      tValue = t3.Value + tValue;
      return tValue;
      }

      I don’t care if the person names their functions camel, pascal, underscores or otherwise, just name them well! I have seen senior developers name things after tickets and with very short unhelpful names.

      you might understand the function if it was more like the following (note I have intentionally messed about with underscores, casing etc.):


      function GetInternationalisedCurrency (rawValue, countryCode, Internationalisation) {
      var currency_Converter = new Internationalisation(countryCode);
      var internationalisedCurrency = currency_Converter.SetDecimal(rawValue);
      internationalisedCurrency = currency_Converter.currencyPrefix + internationalisedCurrency;
      return internationalisedCurrency;
      }

      I believe well named functions beat the strict coding standards for coding standards sake… The first version “conforms” to a coding standard but is completely unreadable… The second one even when it messes about with case and underscores is still practically self documenting.

  7. Simon Chadwick says:

    I’d be happy if everyone just used spaces instead of tabs to indent.

    • Alex Davies says:

      Please provide me with 1 reason to use spaces over tabs, I’ve never understood this view

      • Anonymous Coward says:

        Use tabs for indent, spaces for spacing. It’s not the same. Using spaces instead of tabs enforces your convention of indentation over all readers of your code. Using tabs for indent and spaces for spacing avoids this.

        If you don’t use straightforward, simple indent rules, with a fixed tab size, but indent arbitrarily depending on things like where the = is in an assignment, or where the opening ( is in a function call, you’re creating ASCII art which can’t be properly checked/formatted by most tools. This isn’t helpful, it’s wasteful. If your indents are always a fixed multiple of spaces, tabs don’t harm, and add the benefit of everybody being able to use whatever indent size he prefers.

        • I like my ASCII art and I miss it.

          These days I write PEP8 & strict PyLint compliant Python, which does not allow any room for such artistic flourishes, (and I am all for coding standards, so I am happy to comply) but I used to love being able to express the pride that I felt in the work that I was doing through meticulous layout and vertical alignment.

          I justified my actions by claiming that it enabled me to give different sections of code a distinct look and feel, making it easier for me to navigate, but really it was just the equivalent (in software) to Apple making sure that the insides of their computers look as good as the outsides.

          A commitment to true quality should pervade every aspect of your craft.

      • Jeremie Pelletier says:

        Simple: it displays the same no matter what editor and configuration you have. Using tabs makes your indentation dependent on the tab-spaces setting.

        Take JavaScript for instance, your editor might have 2 spaces per tab but your browser might have 8. Thus when in the browser’s debugger your code has a completely different formatting, possibly adding line-wrappings that weren’t present in your editor.

    • Adam says:

      How many spaces? I like my code formatted with 4-space indents. My colleague likes it better with two. I have one colleague who, for reasons no one understands, insists 5 spaces is the correct way to indent.

      Using tabs means that everyone gets to set how much indentation they like. Using spaces is just one more way to force you view on everyone else.

  8. Kurt says:

    Based on my own experience as a developer and manager, coding standards are not necessarily evil (but they can be if taken to extremes). In your career you spend a lot more time reading code than writing it; the primary role of coding standards is to reduce context switching for your brain when reading other people’s code.

    The second role of coding style guides is to avoid common programming mistakes that happen just because of the way our brains work. It isn’t that we are “dumb”, it’s just that we aren’t perfect.

    And, finally, the third role of coding style guides is to avoid wasting times on religious wars about silly things, like tabs vs. spaces, and where the curly bracket starts. As a team you agree on something that makes the most sense according to what tools and platforms all the devs are using (e.g., tabs are no big deal for Windows devs, but suck for Linux devs, so just use spaces and/or configure your SCM to do the translation for you).

  9. I don’t agree at all with this article. It would only work when your team are very knowledgeable and very disciplined. Coding standards are there to prevent arguments and to provide a level playing field, so any developer can immediately know what to expect in code to make maintenance and reading easier. As for bringing up Javascript, one true brace style is almost mandatory to avoid silent errors like this when using allman style:

    function returnAnObject()
    {
    return
    {
    name:”bob”
    };
    }

    • Chris O. says:

      This is a good point, Gary. In JavaScript in particular, because of semi-colon insertion, returnAnObject will return undefined. I’ve actually seen Jr. developers use this style of bracketing in our large JS codebase and create production bugs.

      I’m not sure that this one particular language design choice invalidates the author’s takeaway, however.

    • Philip Bragg says:

      I tend to use one true brace everywhere, which is wrong for certain languages and as you say, more right than wrong for Javascript. What I find is that when I’m collaborating on a project, sometimes I have to adapt and that definitely reduces my productivity a little. If I’m an insignificant contributor, in terms of lines of code, I don’t really have a problem with this, but I’ll still query it if I think it’s massively inefficient or counter-productive.
      What I suppose is needed is an acceptance that standards should be peer-imposed and not come from non-coding bosses and the standards should be allowed to evolve, to prevent inefficient things from the past being dragged pointlessly into the future.

    • Anonymous Coward says:

      Essentially, you’re saying that coding standards are not needed for teams which are actually teams – totally agree, such teams build their own coding standards.

      OTOH, if you only call your bunch of people a team, not having a coding standard is your smallest problem, and enforcing a coding standard isn’t likely to make things better.

    • Zbyszek says:

      I think in this example problem is in the language specifics not in coding standards. Beacuse of javascript strange rules you should not use such syntax. I would say your arguments is like saying that when writing a code in C one should use = for assignement not := as they would in Pascal.
      This is NOT a coding standard, this is an ability to code right.
      Maybe better example would be a standard of using const==variable instead of variable==const in C which is often enforced to avoid mistakes like if(x=1) instead of if(x==1), but I personally hate this standard as it makes code much less readable

    • It works the other way round. By setting an expectation of professionalism, but not spoon-feeding the details, you create a team that is knowledgeable and very disciplined. Everybody has hidden depths.

  10. DeathfireD says:

    We tried this once at my place of work when the company was just starting out and it didn’t end well. When a client caused their site to break, the support programmers who where tasked to fix it where confused about why we were all coding things differently or why some programmers were over complicating simple things things or why we were all using different plugins for the same functionality. We shortly realized a standard on how we code and what plugins we use was a must. On the rare occasion we will have someone code outside of this standard and when that happens it ends up costing us lots of time when something breaks or needs to be implemented into the site at a later time.

    • Anonymous Coward says:

      See, that’s exactly the point: the standard emerged from the people using it. That’s likely a good standard – and one unlikely to go unchanged if it becomes outdated. It’s standards pushed top-down which are harmful. I was bitten often by such standards, that’s why I advocate against them.

    • “support programmers” – I think that phrase has significant explanatory power here :)

  11. LOVE this. I’ve been coding for 30 years, and continue to be astounded at the amount of time wasted on stupid shit that is not coding. No amount of “best practices” will make significant progress at turning novices into experts. They simply need to put in their 10,000 hours. The only coding standards that are important is that it works, it is readable, and it is delivered in a timely manner.

  12. Yaniv says:

    I wonder how it would look like to a client when one of your programmers leaves and the only one who can fix his broken code is him because he’s the only one who can actually read it. What if he gets into an accident and dies? Anything can happen. I bet you can get away with it if you have a hacker in your team, but that’s such a waste of time and money.

    The way I see it, coding standards don’t necessarily make your project progress faster but rather make sure you’re not putting your whole company’s trust into a single programmer’s hands because that’s simply bad practice. If everybody can read everybody’s code then you have no problem. Also sometimes software has to be maintained and improved for years and that would be impossible if every class in was written in a completely different manner. Not to mention if you have a certain vision about a project and your rookie programmer can’t even start to comprehend your software design because he simply doesn’t have the right experience yet.

    A balance between being strict and being loose usually works for me.

    • Anonymous Coward says:

      Coding standards won’t solve the problem you’re describing. Especially bad coding standards, focused on how things should look, rather than how they should work. People from outside a team cannot develop a coding standard about how things should work – they don’t know the solution domain in detail.

  13. nagisa says:

    And then there’s cool language wide standards like PEP8 and convenient tools like gofmt.

  14. John Bannick says:

    Coding guidelines can be a useful way to show any coder best practices.
    I read coding standards and other peoples’ code for that purpose.

    Guidelines are also useful in helping teams, especially geographically dispersed teams, share code.

    However, strictly enforced spacing, bracketing, etc. standards and the mind set that would enforce them, make people mad and drive away your best people. Not polemics; just observed results.

    Guidelines good: standards bad.

  15. Tristan says:

    Really insightful article, thank you.

    Basically what you’re saying is that the value of autonomy and trust on a team is greater than the value any specific coding standard could achieve; especially since the negative psychological impact of standards brings people down as well.

    I have found this to be true not only in coding, but in any management case where authority wins out over autonomy. The more you can say to your employees, “hey, here are our high-level goals—we all share these and value them greatly, we expect you to do the same” and then get out of their way, the better it seems to work.

    As in this wonderful TED talk by Dan Pink—Autonomy, Mastery, and Purpose are key. I don’t think his concept covers 100% of management cases, but it is extremely close.

    This is a huge management realization and one that people should be making more noise about. This basic concept should be the direction of our efforts. Thanks again for your post.

  16. Pingback: Orestes | Why I Have Given Up on Coding Standards

  17. Mohsen says:

    As someone who sorted CSS properties to match companies coding conventions I completely agree. They were paying me to do but I hate to rewrite code that is already working.
    What is difference between

    .class {
    background-color: white;
    border: 1px solid black;
    }

    and

    .class {
    border: 1px solid black;
    background-color: white;
    }

    ?

  18. Jim says:

    No company, big nor small, listed or not has ever fails because of coding standards.

  19. Nathan D. Ryan says:

    I largely agree. A coding standard is supposed to make things easier, on balance. If a coding standard cannot be automated, it does not make things easier, due to the manual energy involved in attempting to follow and to enforce the standard. If a coding standard is too loose, it is purposeless. If a coding standard is too rigid, it forces a black market of anti patterns, as developers circumvent the standard. There seems to be a “habitable zone” of automatable standards that are already mostly satisfied by the compilers, IDEs, and a few popular analysis tools. Internally imposed coding standards are usually unwelcome, rarely justified, and even sometimes a reflection of bad practice.

  20. Pingback: » Why I Have Given Up on Coding Standards Andy Rumpler

  21. Anonymous says:

    I really liked the article. Until you got to a plug for your company. You almost made it all the way through a regular, interesting and insightful blog post, but you couldn’t resist getting a little advertising in. Why do intelligent people insist on making everything into an advertisement?

  22. Viktor says:

    A programmer should use an editor that presents the code to him as the programmer preferes it to be presented, therefor it is irrelevant however it is formated on disk.

    It’s more important to focus on writing good code than code that looks good.
    This is really a no-brainer.

    • Darryl Wagoner says:

      That depends on how you define “good code”.

      I have a problem with saying “just write good and readable code”. All code is
      readable! It just depends on how much time you are willing to invest in reading it.

      People get uses to coding formats and can read them quicker than randomly formatted code. Code formatting is largely taken care of by the IDE.

      However coding format standards isn’t the end of the story. There is also best
      practices.

      Code should be:

      1. Very readable: This means few comments, descriptive names, and readable
      by someone outside the team.
      2. SOLID: When possible and sensible the SOLID principles should be followed.
      3. DRY (Don’t Repeat Yourself)
      4. Unit testable.

      The original author seems not to have spent much time supporting code that
      hasn’t followed good practices. Most of the expense of a produce is bug fixing
      and enhancements.

      In my shop code that isn’t very readable is defective code.

      For code to be acceptable it has to:
      1. Execute correct.
      2. Understandable by a notice programmer
      3. Easily changed
      4. Testable

    • There have been many attempts to move away from linear text.

      “visual” coding , “literate” coding etc.

      The jury is still out. The best implementation I have seen so far is Scratch: http://scratch.mit.edu/

      Linear text is very powerful.

  23. Warren Postma says:

    “Coding standards” sometimes means “where do you put semicolons and curly-braces”. It also sometimes means “Am I expected to give my variables meaningful names, comment my code, and avoid raw untyped and unsafe operations”.

    It descends into the former, sadly, and that’s where I agree with you. When it’s about writing good code, and having code-reviews point out where the hurt lies in your code, then that’s great. But I too am sick of competing in whitespace wars.

    Warren

  24. grg says:

    Hmmm, on my current project, we have code from 5 programmers. They all have different coding styles. One wants to start each parameter with “p”. Another one loves tabs instead of spaces. Another wants a box of asterisks at the top of each procedure. Another one loves a certain formatter that comes with the IDE. One uses a lot of with’s, the rest use almost none. One loves nested procedures, nobody else does.

    The code is a mess and hard for anyone who didn’t write it to immediately and visually understand what is going on.
    Plus, this is in a regulated industry, so the code has to be maintainable for the next 20 years. By then all these people will be gone and the next generation will have to try to understand this hodge-podge.

    That’s why a certain level of coding standards might be a good idea.

  25. Bron says:

    As someone who spends a large amount of my working day on an open source project with an indenting standard which I _hate_ (4 spaces, 1 tab, 1 tab 4 spaces, 2 tabs) you know what I say.

    Suck it up princess.

    You are writing code primarily for other programmers to read, perhaps years later. So jump down off your high horse and follow the style of the code around you.

    Starting something new, awesome – you can do it your one true way, and I bet you’ll be glad if you wind up sharing that codebase with someone else if they copy your style rather than trying to put their own imprint on the code. I write in the style that annoys the crap out of me because, it’s the style of that codebase. I load up a custom editor configuration which makes it easy, and away I go.

  26. Tim says:

    This is fucking retarded. Coding standards are there to make it easier for developers to quickly read and understand the code. If everyone uses their own standards and style, reading the code will require needless feats of mental agility. Get a clue.

    • Anonymous Coward says:

      If everybody uses their own standard than there’s no teamwork going on. Build your team first, and a coding standard will emerge. Enforcing the coding standard before building the team is likely to harm the process of team building – programmers won’t feel empowered, will get demotivated and avoid getting involved in anything other than the minimum they need to do to get the paycheck.

  27. Xobb says:

    You’re somehow right about the article. Snr dev shouldn’t care about coding standards. He sees the code standard from around and just follows it. If building from scratch, he’s building his own coding standard with var names and function names in the style he likes most or whatever. But they are all the same around the project. That’s it.

  28. Shawn Holmes says:

    I don’t know how I feel about this.

    Can we/do we waste an excessive amount of time debating trivialities like for/against semi-colons? Yes. No argument there.

    Should we cut the crap and trust other folks on our teams to deliver quality code instead? I’d love that.

    But what if the members on our teams have absolutely no accountability? No investment in what they do? You know who I’m talking about; you’ve had one on your own team. They write code during the day, and they’re completely checked out of tech in their off hours. It would probably be impossible for them to care any less about standards than they already do about their workday, which they see as “just something the pays the bills”.

    Have you seen the code these folks write?

    It’s a god damn disaster!

    I think *some* standards are in order in this environment. They need a guard rail! Otherwise, they’re going to continue to bowl a 0 game, and you’ll be the one staying late setting all the pins back up by hand.

    A few folks here mention quality code, and that’s where the focus should be. Some semblance of structure, ie. standards, are just one piece of that puzzle. They’re a tool to improve a programmer’s efficiency, just like a good IDE is, or a fast computer with a lot of memory.

    Do we really need to be in the business of decreasing tools?

    • Steve says:

      Best comment so far that I agree with. You need *something* so that people generally agree on what clean code should look like. Don’t focus your standards… I mean… *guidelines* on how much whitespace is valid, should you or should you not use braces on single statement blocks, etc. These are too prescriptive. Developers are creative; let them be creative.

      Perhaps the term “guidelines” is even too restrictive.

      Preventing human mistakes and making readability easier are key.

      Our guidelines are continuously evolving. Who’s to say that what somebody wrote last year (or 5 years ago) is even valid now. Methodologies change, fashions come and go.

    • Taking over, or leading, an institutionalised and disenfranchised team is a while ‘nother blog post :)

      I think coding standards in this scenario help move you toward a local maximum. The question is, are you happy with that?

  29. Pingback: Why I Have Given Up on Coding Standards | My Daily Feeds

  30. Pingback: Some light dinner reading | Tyler Merrick

  31. Blick Black says:

    This would be ok if developers actually had the sense to create beautiful code. Unfortunately 95% of code looks like shit and most people don’t know the first thing about the aesthetics of writing pretty code. Yes it matters. Refactoring well written code is a breeze, refactoring badly written code is a nightmare. Its all about habits and seems ones code as a form of art rather than a means to an end.

    But I agree with you. Fuck everyone else’s coding standards. I will only use mine weather a company has standards or not, I could care less. Unless your code looks as pretty as mine, don’t bother trying to convince me to change the way i code.

  32. Well, it depends.

    Some projects really do need standards and guidelines, others, not so much. Personally, I believe that there are (some) standards that do provide real value under a reasonably wide range of different circumstances. Things like test coverage, limits on McCabe Cyclometric complexity, that sort of thing.

    However, there is one point, raised by the article, that I strongly agree with and believe to be critically important, so I will repeat it here: Rules, imposed by fiat, and enforced by humans, are a terrible, terrible, awful, terrible idea.

    When designing complex systems, our individual productivity, our ability to get into flow-state, is strongly driven by our enthusiasm and our sense of ownership. The difference between a 10Xer and the rest of the pack is predominantly one of motivation and obsession. The difference between a 10X team and everybody else is measured by the same criteria.

    Apparent freedom is a critical component of ownership. Ownership is a critical component of motivation. Dictatorships destroy all of that good stuff. If you are going to have standards, they cannot appear to be imposed, and must be communicated in the background, via out-of-channel mechanisms.

    The key thing that people almost always miss out is automation. You cannot tell people that they have to follow a standard, but you can get your continuous integration (or continuous testing) mechanisms to check for standards compliance and highlight any failures as part of the normal development feedback loop. The natural desire that most of us have for neatness and uniformity will drive us to comply with the standards, without having it forced down our throats, and without it destroying our “flow”.

  33. andy says:

    Trusting your coders is wonderful. I’m extremely lucky to be where I am and be so trusted. The problem that I’ve experienced, in my admitted few years, is the coders that got into it for the wrong reason. If you let those coders run around with a pair of scissors in their IDE, they will have no eyes, no tongue and will probably be collapsed in a pool of their own blood.

  34. Sometimes it’s hard to me from background from java moved to php or .net moved to php and noobs moved to php and superb power php..
    java to php.. Everything must put in function..Even php array output as function .
    asp.net to php .. Before everthing autocomplete now err.
    noobs .. to php .. They just know to code and no thinks coding standard.
    superb php.. Thiking tenanry and shorter code improved speed system.. and latest php library and new structure style..
    Using IDE also the same.. PhpStorm ,Netbean and Zend studio when formatting output diffirent phpdoc output.

  35. Prophet says:

    Richard, a query: how often would you say have you had to deal with (regardless of whether that means “debug”, “review”, “refactor”, etc.) other people’s code, and how often do you reckon have you felt encumbered, held back by or even frustrated at code style?

    Do not say ‘never’, because I will know that’s a lie.

  36. Amer Mallah says:

    If you’re against coding standards, you’ve never had to maintain code written by someone with different coding standards. Coding standards provide consistency so that every improvement does not automatically have a learning curve.

  37. I still go for coding standards. One reason is to make our team work efficiently and not just writing our own way of coding. Which will cost some time to understand and could have some confusions. So a coding standard must be implemented for us to better understand what we are trying to do.

    And additional to that, once we have to pass along the code to the other generation of programmers, they can easily adopt the codes and understand it fast.

  38. Pingback: JavaScript Semi-Colons | Diputs Media

  39. I agree with the heart of your conjecture:

    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.

    Relationships between professionals are based on mutual respect & trust. If as a manager you feel that your developers are just a bunch of lazy, overpaid undergrads they’ll eventually figure it out. They will begin treating you with the same disdain by living up to your expectations.

  40. Polo says:

    This article is symptomatic of where our industry is heading.

    In the beginning there was design backed up by good documentation. By good documentation I also mean common coding standards including commenting stanndards. There agile methodologies evolved in an attempt to capture and implement the rapidly changing requirements reflecting the rapidly changing world we live in. Now, as a consequence, thanks to Agile/Scrum, hacking is condoned, design is ignored, and documentation is neglected, or worse, is considered superfluous.

    In no other industry would this be accepted. Imagine the chaos if medical records staff in a hospital were allowed to use their own data entry standards, or if architects specifying a building or infrastructure project were allowed to use ad-hoc specification or drawing terminology.

    Working as a self-employed consultant with 30+ years in the industry, I’ve noticed that it is getting more and more difficult to get up to speed on new projects, mainly due to no design documentation and poor coding guidelines.

    • The trouble with reality is, … it’s real. We need to work out how to deal with it. Waterfall is a great methodology if you don’t have to make money.

      All of our chatter is just a random search for ways to deal with this. But I think we need to jump off a local maximum here.

  41. Paul says:

    This article is symptomatic of where our industry is heading.

    In the beginning there was design backed up by good documentation. By good documentation I also mean common coding standards including commenting stanndards. There agile methodologies evolved in an attempt to capture and implement the rapidly changing requirements reflecting the rapidly changing world we live in. Now, as a consequence, thanks to Agile/Scrum, hacking is condoned, design is ignored, and documentation is neglected, or worse, is considered superfluous.

    In no other industry would this be accepted. Imagine the chaos if medical records staff in a hospital were allowed to use their own data entry standards, or if architects specifying a building or infrastructure project were allowed to use ad-hoc specification or drawing terminology.

    Working as a self-employed consultant with 30+ years in the industry, I’ve noticed that it is getting more and more difficult to get up to speed on new projects, mainly due to no design documentation and poor coding guidelines.

  42. Andy H says:

    There are some spanners in the works for this concept, the main ones being:

    1. Inexperience programmers, or no0bs.
    2. The Fadistas.

    As you try to explain at the start when you were new you didn’t really know anything, so letting inexperienced programmers loose into the wild without any supervision or guidance, usually results in the biggest steaming turd you’ve ever seen!

    The other primary issue are the Fadistas, these are the ones who’s approach to what they are doing changes from either month to month or week to week. They are intelligent and experienced, but they are using your companies time and money to experiment.

    The problem the Fadistas experience if left uncontrolled is that when asked to come back to some code they wrote 6m ago, they’ve no idea what they were doing at the time and usually end up completely re-writing the element in the style they are holding at that particular moment. Wasting more time and money.

    In small groups of like minded, experienced programmers the concept may work, but in large corporate groups with widely varying ranges of experience and thought processes there needs to be a path to follow.

    You do cover that the path can be too wide or too narrow, but the key part (imo) is not to eliminate the coding standard, but to give opportunity for the programmers to steer it’s direction.

  43. vaughan says:

    never ever ever block comment.

    ever.

  44. Madan Cheemakurthi says:

    Well, to start with….
    1. Coding Standards are to increase the readability of the code.
    This helps in if you have a large legacy project which is being maintained by developers over the years and during this time several developers leave and the new ones join. In this kind of a scenario, you need some standards to be in place and otherwise, it will become even more a big problem to maintain the code.

    2. It is your choice to run the show with the individual brilliance of the developers or take the help of processes to some extent.

    3. If you extend this logic further ….are you saying that we don’t need design patterns in coding because all that matters is whether the code works or not? Nope, certainly not.

    4. If the developers don’t follow a minimum set of standards, I’am sure 95% of developers will themselves forget the context of the fixes (code) they have done after 2 years. You need something to fall back on!

    5. The article does explain to some extent the ground realities experienced by a developer and the actual situations encountered by the developer…..but it is somewhere sounding very disappointed and negative.

    Having said all of the above……Nothing is good if it is in “overdose”. Everything in life should be balanced and optimal.

  45. Edmilsom Carlos says:

    Let me guess Richard: You are a Microsoft.NET developer right? I mean, seriously..

  46. Robert W.Mills says:

    It sounds to me as if he’s only involved with the apps initial creation. He doesn’t dirty his hands with the remaining life of it (adding new features, fixing bugs, etc.). The people who are helped by standards are the maintenance guys who he probably doesn’t care about.

  47. Pingback: Why I Have Given Up on Coding Standards | My Daily Feeds

  48. Sharas says:

    Standarts and “recommended practices” are also often a shelter for incompetent.

    • Steve says:

      Noobs (urgh! I hate that word!) may be “incompetent” to the extent that they need to learn and may not be fully up to date with all the experience that there colleague of 15 years in development has. That’s where guidelines and recommended practices come in to play.

  49. Wynn Rostek says:

    After having spent almost all of my 40 years of programming as the sole programmer on one embedded system or another, I’ve learned that highest productivity gains are to be had by keeping track of the kind of mistakes I make, and working like crazy to prevent those. Coding standards do nothing to increase the productivity or quality of my code. Maybe they help someone else who makes those kind of mistakes, but they don’t help me. When you are the sole person holding up a 6 million dollar contract, and have to get 5,000 lines of code designed, coded, debugged and out the door in 6 weeks, you tend to eliminate non-essential distractions.

    • You’re actually building the bike shed! Thank you.

      Please do a deeper write up of your techniques – this is more of what we need.

      • Wynn Rostek says:

        -Wall is my best friend. The code has to compile with no errors and no warnings. Period. No exceptions. Over the years I’ve found that my mistakes tend to occur as follows: Cut and Paste errors. Still make the = vs == error on occasion. A search with the editor when I think I’m finished helps here. Still overlook some edge cases if they are complex enough. The remainder tend to be design errors, and very low rate errors. I still average about an error per two hundred lines of code, but 80% of these are picked up in early testing. I spend about 20% of the project schedule writing test tools that allow me test new features as they are developed, these are usually done in something like C# with a good library/IDE under windows. A lot of what I’ve done lately has been linux based. Worried that you have memory leaks? run htop, and watch the RES column. If it climbs over time, you’ve got leaks of one kind or another. pmap gives a great break down of memory usage. The total at the end is a great way to check for memory leaks on a live application. Do 2 pmaps about 10 minutes apart and diff to see who is climbing. ls -l /proc//fd will list all the open sockets and files. Leaks here also cause RES in htop to climb. If it is a file leak, the file name(s) will be listed, making tracking things down a piece of cake. As you might guess, I really prefer non-invasive means of identifying problems as most of my applications are soft real time, and tools like valgrind and prof tend to break things more than they’re worth.

  50. Luis says:

    I work in a “enterprise” project with a control freak architect – we use Sonar with PMD, checkstyle, findbugs, zero code violation threshold. Almost no one want to have initiative anymore. I don’t like it. The management feel empowered.
    If we fail, at least we followed the rules.

  51. Jay says:

    I’m completly with you… Most of Coding-Guidelines are just trash. I give you an example. Here the guidelines tell me that a method should not contain more than 4 Ifs, not to be longer than 10 lines of code, to use a dictionary instead of a switch-statement. And so on… So what’s the result of it. Instead of method containing 5 Ifs written in 10minutes I had to write a class containing 8 Methods and at least 100 lines of code. I read the method containing 5 Ifs to in some seconds and see at the first look if there’s going something wrong. Now I have to look in wich case which method is called. Which is pretty bad if you dont debug and have to step from method to method.
    Isn’t good code, good code when you see what its doing without debugging? If it is, than it doesnt care if the variables are in camelcase, lowercase or what ever. Code is good if you can read and understand it. Onother result of the guideline here is that instead of doing stuff like this:
    void DoSomething()
    {
    If (true)
    {
    DoSomeThingElse();
    }
    }

    I have to write this code
    void DoSomething()
    {
    DoSomeThingElseIfValid(True);
    }

    void DoSomeThingElseIfValid(bool param)
    {
    If (param == true)
    {
    DoSomeThingElse();
    }
    }

    That sucks and there’s not a single benefit. For me personally there’s the problem that the If is in the methodname to tell everybody else whats the method for. And if the “if” changes I have to rename the method or in worst case it will keep the old name which is not telling right. So what’s it for. As a developer you should be able to read and understand code. No matter how the variables are formatted or how long the methods are. If a developer is telling me that isnt able to read and understand a method containing 5 If-Statements, I tell him that he should overthink if developing software is the right job for him. Code must do what its ment for. And as long as its doing it, it doesnt care if the method is 10 or 100 lines long. Even if you do it like we do here and split that shit to 10 methods instead, the chance for a bug is the same. So why write code in 1 houre if you could do it in 10minutes with the same result? Specially the managers out there should think if its worth the money to spend more time doing the same shit, just for having a code-guideline.

  52. Jack Simmons says:

    The article comes across as the other extreme from CMMI formality. I once worked for a company whose “developers” spent hours arguing about such mundane fluff as where the little squiggles should go on the page. One of their teams asked me to join their project. Their “tech lead” then handed me a thick coding style guide. I told him that if such a thing was their main concern then they had no use for a Ph.D. in Computer Science, that a simple program could reformat code into whatever style they wanted. Paying anyone to worry about such things is a silly waste of time and money. I went on to another project.

    Where CMMI becomes important is establishing such things as version control, requirements identification and satisfaction, testing processes, and providing a basic structure that helps a distributed team function. Far from the hype, CMMI is never free. It can easily devolve into filling check boxes and preparing for inspections. These are typical of government-developed processes. (CMMI was originally developed under government contract to government specifications.)

  53. Semi Essessi says:

    did anyone else read this as ‘… because I am shit at my job’?

    I’d accept an argument against poor, or draconian standards, but actually, good standards can stop people from doing dumbass stuff or hitting subtle gotchas – esp. useful for junior developers who might not understand the intricacies of static initialisation order or memory alignment in C struct layout…

  54. Dani says:

    When is code of high quality?
    1. Correctness (if it does not what it is inteded to do, it’s worth nothing)
    2a. Efficiency (if it doesn’t do what it is inteded to do in an efficient fashion, it’s worth is reduced)
    2b. Maintainability (Readability of the code is a precondition)

    Do coding standards help to achieve any of the aforementioned goals? To which degree?

    I think, good coding standards can support goal 2b to a certain degree, bad coding standards may reduce goal 2b. They do not support goals 1 and 2a.

    A Master Craftsman produces code that supports all 3 goals, especially goal 2b.

    • terry says:

      YES, YES, a thousand times this!!!!!!!!!!!!!!!!!!!!!!!!!!!! This is the best comment I’ve seen so far that proves the incompleteness of coding standards. Coding standards help somewhat with maintainability but it doesn’t address AT ALL the other critical properties of what we would consider good code. This incompleteness is precisely why guidelines and not a standard makes more sense. Because coding standards are incomplete in their effectiveness to begin with.

  55. Vincent says:

    I don’t care any standard if everybody will write as K&R. :))

  56. An interesting idea. I thought at one time coding standards were a waste of time. However, having witnessed several large projects in long term maintenance where there was no coding standard applied has changed my mind a little. In one project are methods that do the same thing scattered in different classes throughout the project…each written by a different developer. Bad programmers? maybe, but I think the lack of standards and basic documentation made it easier for them to just reinvent the wheel than look through the largish codebase for something that already did what they want.

    A balance has to be sought though. You don’t want to be bogged down in docs and standards, but a little bit of structure can help guide a project.

  57. Don Taylor says:

    As an architect I can assure you I don’t care about coding standards – I’ve got much bigger fish to fry than worrying about naming conventions, indentations, the whole tabs vs. spaces thing, vertical alignment of braces and all that nonsense. It’s not that I don’t have opinions on these issues, it’s just that I code ~25% of the time so I let the developers work it out. I follow whatever they have worked out.

    What’s really interesting is the multiple teams I oversee have developed different standards. This generally hasn’t been a problem – as each team supports their own software in perpetuity.

    One thing I do insist is when conducting a code review we are not to discuss coding standards. Previously I’d sat through code reviews where people are arguing over nomenclature and braces alignment while missing the fact the code wasn’t doing what it’s supposed to do. Pointless. By not allowing the discussion of coding standards during code reviews you force the participants to actually pay attention to the logic. Which is the whole point of a code review.

    Bottom line? Let your development teams work out their own coding standards. They’ll be much happier, and productive, if you do so.

  58. Tom Leonard says:

    I strongly agree with this. I was for coding standards – more importantly, I found code should be efficient and correct – but there is this obsession with the rock solid adherence to an older set of coding standards, that I just cant fathom. This inflexibility details is just noise that detracts from the important parts. If code is correct and efficient then it doesn’t really matter whether it’s indented two spaces or three. If it’s NOT correct and efficient then formatting doesn’t matter either. If you care that much about formatting details then use a tidy program. All the programers I have worked with come from different backgrounds. This leads to different technologies and styles….Great !
    I once ran across a company that did not allow the use of ‘var’, LINQ or even multiple return statements within a function. How archaic…they had more production level bugs and poor code architecture than companies with 100 x the moving parts.
    Let the developers ‘own’ their code, let them have a vested interest in their development progress and then you might see a resulting reduction of bugs.

  59. Woody Peckerwood says:

    programmers I’ve been coding professionally for 30 years and this post is spot on.

    Every coding standard I’ve been exposed to is wrong in multiple ways.

    All programmers hate other programmers’ code.

    Deal with it. If you try to make a coder code YOUR way, you will destroy 70% of his productivity.

    Here is an email exchange I had with a previous boss who wanted C++ declarations done a specific way.. .

    ——

    I noticed that the g++ compiler outputs error messages using TYPE& or TYPE* and wondered why? Here is what I found in my investigation:

    Which type declaration format is more standard in the industry?

    TYPE& and TYPE* (new way) or TYPE & and TYPE * (old way)

    1) The g++ compiler outputs error messages using the new format:

    undefined reference to `DTClassifier::serializeAndDeserialize(File&, Serialization::Direction) const’

    2) The God of C++, Scott Meyers uses the new style syntax: example: http://www.aristeia.com/publications_frames.html

    3) ALL the new c++ headers use the new method (excerpt from /usr/include/c++/4.1.2/cstring)

    inline void* memchr(void* __p, int __c, size_t __n) { return memchr(const_cast(__p), __c, __n); }

    using ::strchr;

    inline char* strchr(char* __s1, int __n) { return __builtin_strchr(const_cast(__s1), __n); }

    4) All the tr1 headers use the new format (except from /usr/include/c++/4.1.2/tr1/tuple)

    // Adds a const reference to a non-reference type. template struct __add_c_ref { typedef const _Tp& type; };

    template struct __add_c_ref { typedef _Tp& type; };

    // Adds a reference to a non-reference type. template struct __add_ref { typedef _Tp& type; };

    5) ALL the stl headers use the new format: (excerpt from /usr/include/c++/4.1.2/bits/stl_algo.h)

    template inline const _Tp& __median(const _Tp& __a, const _Tp& __b, const _Tp& __c, _Compare __comp) { // concept requirements __glibcxx_function_requires(_BinaryFunctionConcept) if (__comp(__a, __b)) if (__comp(__b, __c)) return __b; else if (__comp(__a, __c)) return __c; else return __a; else if (__comp(__a, __c)) return __a; else if (__comp(__b, __c)) return __c; else return __b; }

    6) boost uses the new format: (excerpt from tuple/tuple_io.hpp)

    #if defined (BOOST_NO_TEMPLATED_STREAMS) static char get_manipulator(std::ios& i, manipulator_type m) { char c = static_cast(i.iword(get_stream_index(m)));

    // parentheses and space are the default manipulators if (!c) { switch(m) { case detail::format_info::open : c = ‘(‘; break; case detail::format_info::close : c = ‘)'; break; case detail::format_info::delimiter : c = ‘ ‘; break; } } return c; }

    7) Bjarne Stroustrup uses the new style: (from samples on his web site)

    http://www.research.att.com/~bs/3rd_code.html

    “list example” http://www.research.att.com/~bs/print_entry.c

    struct Entry { string name; int number; Entry(const string& n, int i) :name(n), number(i) { } };

    8) Andrew Koenig uses the new format:

    http://www.cs.fit.edu/~mmahoney/cse2050/source/unix-source/

    9) Excerpts from various coding standards documents

    a) Here is a coding standards very similar to ours: http://geosoft.no/development/cppstyle.html “51. C++ pointers and references should have their reference symbol next to the type rather than to the name. float* x; // NOT: float *x; int& y; // NOT: int &y; The pointer-ness or reference-ness of a variable is a property of the type rather than the name. C-programmers often use the alternative approach, while in C++ it has become more common to follow this recommendation.”

    b) http://www.gotw.ca/publications/c++cs.htm

    C++ Coding Standards by Herb Sutter and Andrei Alexandrescu, the newest book in Bjarne Stroustrup’s C++ In Depth series, is the authoritative reference for C++ software development teams. It’s the only C++ coding standard with Stroustrup’s name on it

    Looking through the errata list you can see all the declarations use the new format. http://www.gotw.ca/publications/c++cs-errata.htm

    10. I could go on and on and on but I couldn’t find any examples of C++ standards that follow our standard of putting the * or & separate from the typename.

    —— boss reply below
    Short Answer:

    I don’t care, they’re *all* wrong!

    Long answer:

    Their way of doing things does *not* gracefully support declaring more than one variable in a single declaration statement! If they were right,

    int* ip, k;

    would declare two pointers to integers. It does not!! End of story!

    ——-

    Of course the multi million dollar project failed (on the government check)

  60. Harald M. says:

    Nice attempt: “It is your responsibility, because you can code.”

    “can code” is not what coding standards try (or tried) to solve: They tried to solve the “can communicate with code” problem. Yes, I’m also against coding standards in the weird, preaching sense that you describe. But obviously, each and every team need a coding standard that is just a culture so that you feel ok in code written by others. There may be even 2 or 3 coding standards in a group – I live happily in such an environment of about 30 programmers. But not 10, and not 30.

    It’s about communication; it’s about respecting the others’ needs for reading and understanding; it’s about politeness. It’s never about preaching, “brace wars”, “company rules”.

  61. I ended up writing a blog post as a comment on my website: http://rtigger.com/blog/2012/11/22/design-standards-vs-code-standards/

    Synopsis: I like Michael Feathers’ comment that having Design Standards is much more valuable than Code Standards, but they need to be reviewed regularly in order to prevent stagnation and much of the same detriments you mentioned in your post.

  62. Alfredo De Regil says:

    I think it is naive to expect that a group of people will produce quality software systems just by accident when you give them “freedom”.

    If you are a developer working alone for your one-only company then do the coding and architecture like you want. It’s the only occasion when you will have “freedom”.

    If you are a developer working with other people then agree with the other people about how do you architect and code the system. You do not have “freedom”. You work for somebody, and then follow the rules! That does not kill your professionalism and creativity. It just challenges you more to do your magic but working with the standards.

    If you are responsible for delivering a system built from other people make sure there’s a standard way of architect and code. You need that in order to align the work of all the people that enters and exits your project. You need that in order to make a business out of it because you need to maintain that software in the future. You do not control people. You cannot expect people to have freedom and then leave you with systems that are not maintainable. You better guide them with a standard way of doing things.

    If you are in charge of a system do not waste your time discussing. You are responsible; you are paying for the job. You better express what is good and what is not good. If you give them “freedom”, then you will end up with probably “excellent and creative systems”. But you will suffer trying to maintain several types of architectures and coding conventions.

    I have seen team morale going really up when you guide the team and show them structure. When you give them “freedom” they work separate, they do not integrate, they build systems that do not share anything and are very difficult to maintain.

    Do not allow for bad surprises in your team. Developing software should be more of a professional engineering practice and less of a casual artistic craftsmanship.

  63. daves says:

    js on a server? please…. maybe we do need some standards

  64. Antony says:

    Excellent read, a good dev I know today said ‘no-one ever reads coding standards stored as a word doc’ – and I think he’s right. Use tools to control style, syntax, metrics, balance and so on – use people to code.

    People are not machines, they’re better than that.

  65. Larry says:

    I kinda disagree. You don’t necessarily need concrete standards, but you’ve gotta have organizational guidelines (a little more subjective):

    1. You GOTTA have SOME standards, or collaboration and legacy code is a NIGHTMARE!

    2. You GOTTA control spaghetti code!

  66. Bill Gord says:

    I’ve been designing software and writing code for over 45 years. Occasionally being a manager. Often being the “technical leader”. Sometimes working comfortably alone.

    I’ve seen coding standards come and go. Some of them have been mine. Some of them seem really good. Some I have helped force to become “standard”. None of them last very long.

    I’ve worked with strong programmers and worked with weak programmers. The beginners need guidance and will learn. The weak are done learning and need crutches – for themselves, not for their code (their code needs help too, but a crutch isn’t the solution). Coding standards are just a crutch – at the end of the day (week, month, project, whatever) you can just feel good about the fact that your code looks good.

    But the major software often outlasts all the standards – and then shows the folly of that past. What ‘standard’ to follow when modifying very old software? The ‘old’ one? – at least the text looks good. The ‘new’ one? – looks like a mess.

    I’m not advocating dead-brain ugly code; I’ve worked with code with no indentation at all, code that had as few line breaks as possible, code that used all one-character identifiers. This was, even in its day, simply stupid arrogance. Back in the day of interpreted BASIC, I even purposefully wrote some code like this myself (fortunately not much, and it wasn’t worth the extra effort for the hypothetical efficiency).

    And I certainly support the concept of ‘best practices’. Not because of their ‘style’ but because of their functionality. Hash lists over Linear search (but not always). Memory caching versus frequent I/O (but not always). Inline procedures (but only sometimes). Even pre-processor macros (whatever you call them: think C-family #define) – again carefully crafted. Not to be used or avoided because the “look good” (or not) but because they “work right” in the circumstance.

    Common Sense works wonderfully. The code has to “read” nice. Like a book or a poem. Literature has wide boundaries on ‘style’ – so should software code. But of course: it has to work right, satisfy expectations, be acceptably efficient, with timely delivery and usable documentation. But to follow some short-term, rigid formatting goals? Nope… that is just useless silly effort.

  67. Keith Barrett says:

    I sympathise with your attitude to coding standards: they are often just a list of seemingly arbitrary formatting rules. But what has to be kept in mind is why they exist in the first place. It is because it is not sufficient for a piece of code to be correct – it is also a part of a system’s design documentation. Other coders need to be able to read the code, possibly years after the original developer has gone, and understand how it works and how best to modify it. So we have coding standard for the same reason we have documentation style guides – so that the pain of reading someone else’s code is diminished.

    So ultimately there is just one coding standard: Make sure your code is readable by another coder.

  68. anonymous says:

    Very good point. Unfortunately, most of the developers won’t even get it after reading it.
    1. Code should be correct and efficient.
    2. Clean.
    A great coder should be able to distinguish when it’s worth spending the extra 5 hours making sure your code is in maintainable state and when something needs to be done fast and correct.
    I’ve noticed that developers that don’t have the talent and creativity to figure out and work with complex algorithms usually spend their time “re-factoring” and they emphasis so much on it as it’s the sole most important thing. They eventually become architects ….

    Uncle Bob should read this :)

  69. makaveli says:

    I like this article and actually agree with all the points made. Hire a good developer and trust that they would do the job right. If you will be picking on formats, have this discussion in your interview process.

  70. StandardsFTW says:

    I really like the idea of coding standards, people who use variables like P1, P2 and P3 should be punish with all the fury from the code gods! I don’t think that strict coding guides are the way, but having some minimal standards help in the long way.

  71. Ray says:

    A lot of the comments are about how standards facilitate or hinder development times. Very few have commented about the affect of maintenance.

    The old ‘iceberg’ principle, where 9/10’s of the costs of software is maintenance, and the huge cost of transferring the logic from ‘long dead’ programmers, into the heads of the poor maintenance programmer becomes much more critical than fast development.

    Many languages sacrifice readability for technical convenience. VB and Cobol were designed for English native speakers,so that ‘non-programmers’ could check the business logic. But then they discovered that most programmers don’t speak English.

    Whatever ‘standard’ you adopt should be directed at reducing softwares biggest cost – rewriting. If you find that your maintenance programmers find it quicker to re-write the code than figure it out ( and isn’t that 80% of the time ) you know you haven’t got the ‘standards’ right.

  72. gby says:

    This is exceptionally well written post but I disagree with your opinion.
    In any bigger project with long lifespan some coding standards are beneficial. Don’t treat guidelines as orders that are created to limit your freedom. Some rules make our lives easier, like the rule on which side of the road we should drive…

  73. Legogris says:

    I disagree.
    For me, coding standards are not about imposing your way of doing things on a team. It’s about making things easier for everyone by having an agreement on how certain style choices should be made so that everyone knows what to expect in the code. This is more important in some languages (like JavaScript) and teams (like with people with diverse background and/or views).

    Consider a JavaScript file where every third line omits out the optional semi-colon but the others have it.
    Or a Java class where half of the curly braces are on the same line and half on the next.
    Or the example Ryan made above where, in the same file, you have getPropertyA , get_property_b and setpropertyc. I have worked in inconsistent PHP files like this and its extremely frustrating. Even if I have my own preferences on these things I am happy to give them up as long as the whole codebase in a project is consistent. Yes, there are best practices that should be followed, but there’s still a lot of room for opinion on many of them.

  74. Henri de Feraudy says:

    “other people are smarter then you”
    surely you mean
    “other people are smarter than you”.

  75. I have no doubt in my mind that not having a coding standard was/is the right decision for you. However, I somewhat disagree with your conclusion on what motivates developers for creating one.

    I believe that more often than not, it is about developers switching from a more structured environment (say a large, established engineering company) to a more unstructured one (say an internet startup), or simply that a developer working for the smaller organization talks to his college at the big company and realizes that they do things in a more structured way, including having and following a coding standard. Since that company is big and famous, he thinks that that must be the right thing to do.

    Human beings are not very good at context switching and realizing that what works with seven developers does not necessarily work with seven thousand and the other way around. There is no right or wrong way, just trade-offs, and these trade-offs are heavily context-dependent.

    When company X ships a product, it wants it too feel like a single product, not something put together by seven thousand individuals, even if this is the case. So it creates standards for consistency in user interface, packaging, documentation, etc, etc. Once it has that, adding a coding standard is not such a big step. On the other hand, if the coding standard is the only SOP (Standard Operating Procedure) you follow, you probably don’t need it.

    • Yes, good observation. Refugees from big companies often don’t get that things work differently in start ups.

      The bigger question is whether the “regulations” are working for the big co itself?

  76. AspieDBA says:

    Everyone has their own preference for the way they write irrespective of whether it is code, an email, letter or book.

    Those we like to try to emulate. Those we don’t beat over the head with the coding standards argument.

    I get involved in peer reviews and mentoring. My colleagues code is not how I’d write it and mine is not how they would write it. for the purposes of peer review we simply use a layout tool that also doesn’t write code how we would (only more so) but it does represent a central point of comparison. A lingua franca if you like.

    We don’t save/checkin code produced by the layout tool unless the peer review/mentoring reveals bugs that are fixed during the session.

    My teams coding standards are
    1. Make it readable
    2. Make it readable

    99. Make it readable
    100. Fill in metadata tags so the automated documentation process can do its stuff.

  77. Sven says:

    To all those people who believe coding standards are useless.
    Go support another teams projects (note multiple) for a while and tell me where you stand (that is, after your head stops spinning) from the 13 different styles across the 13 projects or even across the one project.
    How does spending time trying to understand/read someone elese coding style rather than focusing on the problem make me more productive?

  78. Viktor Nordling says:

    “Please go write some code instead.”. Lol, some of the commenters did just that, to prove their points about their coding standards.. :)

  79. Pingback: Coding standards

  80. Mr CSharp says:

    What a fucking waste of time to even write something like this up. This is one individual’s opinion making it out to be like everyone and every team should adopt this kind of attitude. Thing is, a company’s standard, whether any developers like it or not, is a standard. Everyone needs to adhere to it for a reason. It’s also not like the standards are like Latin where it is frozen and set in stone, but the standards should adopt best practices. – for everyone to adhere by. Why does anyone need to adhere to one single standard? Well, for junior programmers coming into the industry, it’s for them to learn how to write code the way the company wants you to write the code so that others will be able to read the code that was written and to follow the logic without spending tonnes of time to figure out what’s going on.

    Sure, if you work alone and there’s no standards, then you can make up your own standards and hopefully the coding style will be consistent throughout. Cripes, to write something like this means that you think that the project your undertaking is going to be maintained by the person who created it. It doesn’t happen that way 99.9% of the time. Only pre-graduate students agree with this article because it’s too much of a hassle to follow a company’s standards. I’ve been a contractor for so long and I do disagree with some of the standards out there. But if I’m gonna be working with a client, I’m not going to argue about their standards. It’s like going to someone’s house for dinner and telling your host that the way they cook and serve really sucks.

    • “But if I’m gonna be working with a client, I’m not going to argue about their standards.”

      And that makes you a professional. I would do the same.

      I’m just think we can find a better way.

  81. Ng Shi Jie says:

    Nicely written, this is somewhat true when the same person is maintaining the code.

    But not one developer will stick to the project forever and turnovers are expected.

    The first developer (most probably a senior programmer) wrote some sloppy codes, decides to throw it to the poor guy (most probably someone new) who has to maintain and extend new features to it.

    Do that for a couple of more cycles, you will have a monolith of codes that mean almost nothing to the next guy joining the team and yeah, we are often rest assured the code “works”

  82. Carl Sharman says:

    This strikes me as an intelligent, insightful and well-reasoned article; but it also strikes me as yet another example of the rampant reactive lurching from one extreme to the other so prevalent in our industry.

    It goes like this. We have no standards, we get burned. That’s a problem, so we obsessively intruduce restrictive, dogmatic coding standards, thinking that will solve the problem. Howerver, that just introduces a whole load of new problems – as so well described in this article – so we drop the standards altogether. Is that really the answer?

    I believe that both camps are correct, to a point. Standards are helpful, but but they don’t need to be dogmatic; just applied where relevant, flexed where appropriate. It’s not binary!

  83. Pingback: Coding Standars – As a software craftsman, yes I care | The Ordinary Developer

  84. Coding standards are a matter of professionalism and responsibility. Giving up on them seems insane to me. I respect your opinion, but I find it complicated to swallow.

    I decided to blog as a response to this post, otherwise my answer would be too long http://theordinarydev.wordpress.com/2012/11/23/coding-standars-as-a-software-craftsman-yes-i-care/

  85. Amir says:

    Coding standards are mostly overrate and misused, my best guide for writing one has always been, http://www.yosefk.com/blog/the-iron-fist-coding-standard.html

  86. Paul says:

    Coding standards should only be put in place if they validation / adherence is automated and impossible to bypass. So using something like stylecop. But every rule should add value. So if I see an object that is lower case, then I know it’s a variable. If it is prefixed with this then I know it is a class variable, rather than a method variable. I fell out of love with “this.” for a while until as a team we decided that it’s inclusion really helped the maintainability of code going forward. Maybe it didn’t help much when we were writing the code, but when we came 6 months later then it helped loads.

    A recent upgrade to style cop enforced (by default) that all comments must be free of typo’s – we could all agree that it was a good thing, but at the end of the day we also all agreed that it didn’t add any value to the code we produced so that rule was instantly disabled.

  87. CAS says:

    As a mere amateur programmer who, however, publishes code and apps online, I agree with the author. I believe, incidentally, that Microsoft do not enforce code standards. Trying to code in a style that is not natural to oneself only slows down the coding process. the important thing is that code is clear and readable, and works reliably. If it is clear then another coder can easily modify it, without worrying about variable-naming conventions, so long as variable names are logical and appropriate, and who cares whether or not one statement is used instead of two, or whether or not short-cut ternary and unary operators are used, or optional semicolons and braces? As for code optimisation, what does one gain by investing lots of time in optimising an algorithm that isn’t even a bottle-neck? To me, style only matters as far as things like using an old non-generic object collection whose type conversions create a bottleneck, instead of a generic collection type, and the correct use of any agreed interfaces that standardise method, and avoiding over-use of ill-considered inheritance, instead of say aggregation, that makes modifying classes time-consuming, etc. That’s my humble opinion.

  88. Pingback: Coding Standards: Consistency is King - Tom Lee

  89. JohnLBevan says:

    Isn’t there a middle ground? Coding standards which harp on about when to use semi colons and what case things should be in are micro-management, which causes issues.
    Standards around how the architecture should be built allow for more flexible systems; i.e. if everything’s done in the same way you can update everything to work differently by alerting a single part of the framework. If you’ve let everyone go off and do their own thing you’ll have 20 different solutions for the “output table to csv” piece which are just different enough to make re-factoring them into one simple solution a complete rewrite.

    Have code standards, but implement them at the right level of granularity to get benefit without frustration.

    On the low level code standards side there are a few benefits if everyone works to the same standards, but as mentioned above if every company has different standards you’re just micro managing. If you have tools to take the pain out of standards (e.g. Telerik’s JustCode as an example of something I’ve used and love) then they become a good idea again. Such tools will find any non-compliant code and give quick re-factoring options to correct the issues. As such everyone can work to standards without even needing to know what those standards are, so it doesn’t hit their productivity or cause upset.

  90. Kevin says:

    As a freelancer sure, do what you want.

    As a programmer, you’ve got to know you will be judged by your peers on not only function but form as a sign of competence. Yes, this includes code standards.

    No ones saying you have to adhere to them 100%. But if you’re running a company with junior devs or interns coming in, if you can’t maintain your own codebase, how can they? You have to set examples for them to follow and lead them. If you don’t display signs of structure and organization neither will they, and when the shit hits the fan some night at 3 am, you will open the code files and think ‘who the hell wrote this garbled bullshit?’

    • So how does one reduce the amount of “garbled bullshit”?

      Enforcing a top down standard is only moderately effective, with lots of other, psychic, costs.

      Encouraging intrinsic motivation and pride in one’s work is more effective.

  91. i tHink it’s Great to Have the Ultimate Freedom in Coding

    being Able to use Whatever Spacing tHat makes me Feel Productive it What’S Important

    tHe Placement of semi-Colons where and when i see fit Means that i’LL produce better Code, Free of the Shackles of Conformity

    whether Other People can Read my Code Easily or not Doesn’t matter, because All tHat matters is tHat i get the Code working

    Was the above paragraph harder to read than the paragraphs written by the blog author and every other commenter here? Think about why that is. Why are there rules of written language? Why are there standards in capitalization, punctuation, separation of paragraphs, and page margins? Do writers (and that includes everyone on this page) find the rules of English writing it so constraining that you can’t get your idea across? Perhaps the same applies to code: if you have a standard, then issues of capitalization, spacing, etc., fade into the background so that you can focus on the essence of the code, which is, after all, much more important.

    If you want to be a Thomas Pynchon or e. e. cummings of programming, great, I wish you luck (there are some wonderful obfuscated code contests that you can enter). But if you want to write code that can be read and understood 5-10 years from now, that “free expression” gets in the way of understanding.

  92. Sharas says:

    Also, coding standarts is a very good bikeshedding topic.

  93. Wakil says:

    Coding standard is good. But sometime it can kill.
    As a freelance programmer, conforming with coding standard might retard you productivity based the standard set by some dead-head manager.

    As for me I support your argument. I also feel coding standard should be personal.

  94. Allan Woods says:

    I worked for a company who had a 1 rule coding standard :-

    “The code (peer) reviewer can easily understand (review) your code before release and confirm that to the best of the revieweres belief, the code will function as per its design requirement”

    As we were all professionals, we understood this to mean that it required sufficient in-code documentation to declare what the function of the code was and to prove that the code met this function.

    Little things like format, variable naming etc. were discretionary. Reviewers were free to suggest performance improvements nbut not to require them if the functionallity was being met.
    Also, by being peer-reviewers we all saw examples of each others code and were able to see what worked for us. In other words, management allowed the programmers to self-discipline. This was not chaos or anarchy. Instead management offerred the opportunity for personal and professional growth. If a programmer was unable to meet the standard (i.e. write code that functioned correctly) then they either shaped up or shipped out.
    I kind of miss those days :-)

  95. Tony says:

    Wow, that sure is a lot of comments for an article without even an attempt to provide proof or examples to backup the authors assertions.

    It’s almost like he wrote a very shallow piece about a very deep topic knowing that the majority of the readers would agree or disagree based solely upon their own existing beliefs of this highly contentious issue. Creating maximum activity on his blog for minimum effort.

    But that would be cynical of me.

  96. KJ says:

    Spoken like someone who has never maintained a piece of code in his life. Coding standards are for the people coming after you having to fix the crap you made. Coding standards are so a maintainer can wake up 2am in the morning half-sleep and easy tell what the you were doing. I hate when inexperienced “programmers” NOT software engineers promote garbage such as this.

  97. A wonderful lesson!
    Thanks

  98. Pingback: Stuff The Internet Says On Scalability For November 30, 2012 | Krantenkoppen Tech

  99. Max Lybbert says:

    To put it simply: you’re doing it wrong. The article addresses common standards that are, in fact, useless. If your standard only addresses how code looks/is formatted (size of indent, brace placement, variable naming), then it certainly should be thrown out.

    However, a standard like the one used by the Linux kernel ( http://www.kernel.org/doc/Documentation/CodingStyle ) is incredibly useful; at least after the preliminary chapters about code formatting. The standard we have at my work isn’t about how code should be formatted but what approaches make for good code (“The single-most important practice when programming is to write simple code”; “When faced with a choice of multiple ways to code up a solution, programmers often run a performance test and choose the fastest approach, even if the speed difference is the neighborhood of a handful of microseconds over a million iterations. Simply put, this approach is silly, and should be avoided. Instead, choose the approach that is easiest to understand, least likely to mask bugs, or is more idiomatic. When we need to improve performance, we won’t do it a handful of microseconds at a time; we will use fundamentally different algorithms.”). We include links to http://www.stepanovpapers.com/notes.pdf , http://doc.cat-v.org/bell_labs/pikestyle , https://blogs.oracle.com/jag/resource/Fallacies.html , and the Linux kernel style guide.

  100. Pingback: LATW Episode 20 (October 1–November 30, 2012) « shahriar

  101. Loved it, every single word of it. I was reliving it in my mind, word by word.

  102. Bob says:

    I like turtles.

  103. Ferdy says:

    I have the same experience with coding standards as the author: they are near-impossible to enforce and really don’t add that much value, business value that is. They do absolutely have the negative price of distrust and ego conflicts.

    Having said that, if a team embraces a standard out of free will, because it works for them, by all means do it. My key statement though is that you need to solve problems in the right order. You should only worry about coding standards once you have solved all other problems that are far more important.

    To illustrate, I regularly come across major issues at the architectural level in software. People who don’t know proper OO, coding stuff in the wrong application layer, big issues like that. As long as you have those, don’t even bother with coding standards because you have far bigger issues to work on.

    If you’re overseeing a team of developers, my advise regarding coding standards is to let it be. If the people are any good, they make come up with a standard themselves, which they will then fully support. If they’re not that good, coding standards is the least of your problems.

  104. There are a lot of people out there who sleep well with code that might work, but looks like a combination of train wrecks, cats walking or cleanling ladies wiping over the keyboard.

    This code might work, but – to cite Uncle Bob – “I’m not going to touch it!”, that is, unless it can be read well, unless it can be understood well.

    See, there are other people who can’t sleep well with code like that flying around for which they should take responsibility – as in collective ownership.

    I have never written code like the former because I quickly realized that there’s beauty in code when I started programming in Turbo Pascal in 1991, but still, I’m sometimes worried when looking at code that I have written years ago.

    Also, I have worked at companies where at least one of the former has worked and created a mess – and it was a PITA to fix bugs interweaven into this mess.

    Coding style and coding guidelines help to take collective ownership and boost productivity for those who stick to them, and it’s time to accept wider, general coding guidelines – because they make a lot of sense. Go and see your local PHP-Fig representative about this.

    Best,

    Andreas

  105. Pingback: Richard Rodger: Warum ich auf Coding Standards haben | PHP Boutique

  106. Brent Logan says:

    This sounds like the rantings of a lone wolf or a prima donna.

    Extend this attitude to a “team” and watch out.

  107. JohnFx says:

    I couldn’t agree more. I used to be a stickler for coding standards thinking that somehow it would magically make poor programmers learn good habits, but that was folly.

    I’ve replaced coding standards with a list of best practices focusing on maintainable and modular code. They aren’t requirements as much as a list of guidelines that new programmers on my team are exposed to. They are free to decide for themselves when or where they are appropriate. I provide them mainly to emphasize the characteristics of code that are important in our shop.

  108. Not every thing is for everyone, it all depends upon individual and situations. Pick standard which is popular in your team or which you can follow e.g. Java coding standards like getter, setter etc

  109. Norman Azadian says:

    I agree with the article. What counts is 1) correctness, and 2) readability. Nothing else matters. We’re all adults and professionals so we should all know what readable means. What to do with someone who doesn’t? First, ask yourself why you hired that person. Second, some re-education is in order. Third, if that fails, show them the door.

    • Peter says:

      So, you agree with not adhering to standards, but you want people to adhere to standards of readability and correctness? How… contradictory.

  110. Pingback: Coding standards are communication tools | The ByteBaker

  111. Peter says:

    I was almost ready to shout “troll”. On the one hand the author advocates 100% freedom, but on the other he expects “[...]everyone to write good clean code”, thus imposing standards.

    But wait! “You decide what that means.” Brilliant! So if I want to name my variables Tomato, Oscar, Hobbit and L1ttl3R3dR1d1ngh00Dz, I can!!! If I want to forego methods and write *aaaaallll* the double, triple and quadruple code I want, I can!!!

    So I get to decide what our testers and debuggers must understand about my coding!!!! WOOT!

    Wait… didn’t I just set a standard? Oh dear! Hell and damnation! I have imposed standards upon other people!! Who will save the world from me???

    Recapping: the author is trying to convery a nice point, but is getting lost in his own rhetoric. Coding standards implemented by Apple, Microsoft, and whichever other company should be seen as a guideline for good practice. If you work in a collaborative effort, it is up to the group to (further) establish guidelines, so they can effectively work together.

    Point of thought: in total anarchy where no standards were ever implemented, none of us could be having this conversation, since no standardized language like English would exist.

  112. Pingback: What is a coding style standard? Do style standards really help? Why can't programmers all just use their default style? » No Sleep Til Bootcamp!

  113. TheLateCoder says:

    All I have to say is having cleaned up and fixed code from many previous programmers, Standards are needed, I mean I totally get the art expression, however if you know anything about art few if any people interpret someone else’s piece the same. The same can be said of code, if you are following lengthy code with no standards you will want to kill yourself…. I know! Trust Me! So I am guessing most of the people pro code however you like must not fix others work where the guy went totally code ape @#it and did whatever….

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>