in reply to Seeking Best Practices - does your company follow a standard?

The company I work for doesn't have coding standards. And I hope they never will. A few times, people have discussed getting some coding standards - but each time, those discussion quickly goes in the direction I always predict (and this has been true for other companies I worked for as well, whether they code mainly in Perl, C or Java): they forget about the important things and start with trivialities like layout nitpicks.

Personally, I find it far more important to have standards like "any database change should be inside a transaction" and "applications shall deal with signals sensibly" than whether an opening paren should be follow, or be followed by a space (or no space, or spaces on either side). IMO, if you think layout details like that are important to standardize on, you're saying to me that your productiveness is influenced by such details. But I think that if you find it significantly harder to understand code based on how spaces and parens interact, you shouldn't be coding. Go fry French fries instead. For instance, we all agree that indentation is important. But 3 or 4 spaces? Who cares? As long as it's consistent in the same block.

Note that by no means I'm saying people should mess around. Writing clear and correct code is important (the latter obviously being the more important one), but don't waste your time codifying unimportant things. And certainly don't base it on a book that's full of 'rules' which are either obvious, or smell like "it's two weeks to the deadline, I'm way off my target number, what I can come up with now?". Yes, it's PBP I'm talking about.

  • Comment on Re: Seeking Best Practices - does your company follow a standard?

Replies are listed 'Best First'.
Re^2: Seeking Best Practices - does your company follow a standard?
by Herkum (Parson) on May 05, 2010 at 21:19 UTC

    While sometimes coding policies can be nit-picky they can sometimes be very useful. One place I worked at had no coding standards either. The result was code that no one understood or could support. It was fairly common to have 1 subroutine to be 2000 lines! I repeat 2000 lines! What the hell!

    I am not saying coding standards are going to everything, but without them, the quality can very greatly depending on the skill level of the programmer...

[reply]
      One place I worked at had no coding standards either. The result was code that no one understood or could support. It was fairly common to have 1 subroutine to be 2000 lines! I repeat 2000 lines! What the hell!
      Yes, and?

      Are you suggesting to solve that with a coding standard that says "No subroutine shall be more than N lines"? What should N be? 1000? 100? 10? 2? Does N include lines that contain nothing but comments? Nothing but white space? Nothing but an opening or closing parenthesis? What if the result of picking an N is that programmers start using nested maps on a single line, instead of multiline nested for loops, just so their subroutines fit in the N line maximum?

      I can imagine cases where a single 2000 line subroutine is preferable over splitting it up. There are 10 line subroutines that should be split up in two separate routines.

[reply]
        Piffle.

        That you have to imagine cases where 2000 line subs are preferred, tells me exactly how often such cases really occur: almost never.

        In 10 years of coding Perl for a living, I have never seen a 2K LOC subroutine that wasn't 90% scaffolding that should have been abstracted away into other modules, with the remaining 200 lines doing 5 to 10 different things that should have been tucked into their own, nicely named subroutine.

        Programmers will use their first working solution as a template for every similar project, you can bet the codebase is a massive pile of cut and paste, long past being maintainable.

        The issue isn't one one of arbitrarily counting elements of syntax, but clarity of expression: at every level, any reasonably experienced reviewer should be able to see what the code is doing and how it fits into the big picture, without having to think about it.

        2000 line subroutines require exponentially more time to understand and review than a group of small subroutines, because they require exponentially more time than the 10 to 20 smaller (by 2 orders of magnitude) subs a decent implementation would probably use.

        If 2000 line subs are common where the man works, something his company's programming culture is badly messed up, and nothing short of wholesale replacement of the entire development staff from the top down will make things better.

        He should get out before that culture infects him to any great extent.

[reply]

In Section Meditations