Re: Why Create Coding Standards and Perform Code Reviews?

[JavaFan]

In a couple of $WORKPLACES, people have been discussing introducing coding standards, and enforcing them. Each time, I've been successful in changing their minds.

Now, I'm all in favour of writing good code. But once people are talking about coding standards, they almost all first focus on layout nits. Like whether you may omit parens when calling a function. Whether you should put spaces before a bracket/curly/paren, after it, or none at all. Whether you should write $$aref[1][2], $aref->[1][2] or $aref->[1]->[2]. Where to put opening and closing braces of a block. Whether you should use "foo" or 'foo' for a string that doesn't use interpolation. Do you shift from @_ or not? Or other visual things, like whether every module should start with 'use strict'.

They seldomly focus on the real issues - or if they do, they aren't willing to put it up front in the coding standard because it's so hard to enforce. 'use strict' isn't important. Using properly scoped lexical variables is. And if $WORK prouds itself it's only hiring "top" programmers, it shouldn't matter programmer A always uses parens when calling a function, and B only when needed.

As for the particular points:

Improved code maintainability.

Perhaps, but that strongly depends on the standard. It also doesn't mean code that doesn't adhere to some standard isn't maintainable. But what's more important is the trade-off. Unless the standard is your own standard so you don't have to think about it, following the standard takes an effort. I'd code much more slowly if I had to follow everything PBP says - just because it sometimes wildly differs from my style. So the business pays a price: it takes longer to write new code. Now, if your code lives for many years, and needs regular maintainance, ease of maintainance is important. But if code has a short half-life cycle, faster delivery of code at the expense of creating "techical debt" is better for the business.

Improved code quality. In particular: testability, supportability, portability, security, efficiency, robustness.

That requires a very good coding standard. I'd be interested to see a Perl coding standard that improves code in half of the mentioned topics.

Improved development speed. Your developers don't need to make all decisions starting from first principles.

That I strongly disagrees with. Almost any rule a programmer has to follow decreases coding time, it doesn't increase it. (If it did, it wouldn't have to be in the standard.) I don't understand your argument though. What have first principles to do with coding, or coding standards?

Better teamwork. Don't waste time with needless debates. Spend your creative energy on things that matter.

I've wasted time on many (needless) debates about coding standards, including the time I spend writing this message. I've never had a co-working coming up to me asking why I put (or didn't put) a space somewhere, or why I omitted an arrow. Nor do I ask my co-workers about details. Now, I might ask a co-worker why they used a cubic algorithm instead of a quadratic, or why they opted for Module X instead of Module Y, but I doubt such things could be covered by a coding standard.

Better performance under pressure. Under stress, people fall back on what they've been trained to do.

But what people have been trained to do is most likely not the rules laid down in standard of their current $EMPLOYER. If I have a dead line loming, I'm much more likely to finish before the deadline if I don't have to check my code with the rules in the coding standard - its rules won't be better or worse than my rules, but they are different.

Fewer bugs. Good standards should minimize common coding mistakes.

Doubtful. I'm not going to make less bugs because I'm following someone elses rules. Now, I will make less bugs if I am following my rules, but it's unlikely my rules will match $WORK rules (again, not that one rule is better than the other - many coding standard rules have just one purpose: uniformity). If I have to do work to make live easier for someone, than that's not free. It takes me time, and I'll make mistakes I wouldn't have made otherwise.

Shallower learning curve and useful training for new hires -- if your standard mandates proven, well-known idioms and style from the programming mainstream.

More rules means there's more to learn.

Again, I'm not saying company coding standards aren't good. Sometimes, they are. But it's not clear-cut, and one should be well aware of both the benefits and the drawbacks.

[eyepopslikeamosquito]

I don't understand your argument though. What have first principles to do with coding, or coding standards?

Someone like Damian Conway has derived each of his 256 best practices in PBP "from first principles". In the interests of development speed, I don't want each member of my team to similarly repeat his research and analysis.

Regarding development speed, the places where a good coding standard has the potential to help is in areas (often "cross-cutting concerns") that are common to many projects and many teams. For example:

• Should I use File::Slurp from CPAN or write my own ... or add one to our library code to be shared with other teams?
• When parsing XML, should I use XML::Simple or XML::LibXML or something else? ... or just use a regex? ;-)
• In my Perl module, should I use '1.23' version numbers or '1.2.3'?
• Should I use C++ Boost shared pointer or write my own "from first principles"? (Update: or wait for ANSI C++ committee std::shared_ptr ;-)
• Ditto for C++ Boost regex (Update: or wait for std::regex - see also Re: Regex match for Any number of words? by davido).
• Error handling.
• Logging.
• Tracing.
• Debugging.
• Memory management.
• Concurrency and locking.
• Thread-safety and reentrancy.
• Exception-safety.
• Portability. I need a cross-platform mutex. How well do C++ templates work on HP-UX? I need file locking or threading that works on both Unix and Windows.
• Libraries. For C++, should I use Boost or something else ... or write my own?
• Documentation. Should I document my C++ code with doxygen or something else? For Perl, POD or Perl comments? BTW, see PBP 7.2: "Create standard POD templates for modules and applications".
• Naming.
• Internationalization and Localization.
• C++ Unit testing/Mocking. Should I use CppUnit or CxxTest or Catch or Boost or GoogleTest/GoogleMock ... or write my own?
• Code review checklists.
• Build and release engineering. e.g. revision control, makefiles, ...
• How do I make a customer patch?

Note: More bullet points were added long after the original reply

[JavaFan]

In the interests of development speed, I don't want each member of my team to similarly repeat his research and analysis.

I'd expect of my team members to have encountered such situations many times in the past, and have done the research and analysis long before being hired. For junior programmers, I expect them to do the research once they encounter a situation for the first time, and remember them. It's called experience.

Now, there maybe situations that require different solutions for different projects. But you cannot both follow a company wide coding standard, and use a different solution each time.