Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re^3: On Coding Standards and Code Reviews

by ruzam (Curate)
on Feb 20, 2009 at 03:11 UTC ( [id://745264] : note . print w/replies, xml ) Need Help??

in reply to Re^2: On Coding Standards and Code Reviews
in thread On Coding Standards and Code Reviews

For Pete's sake people it's tabs and spaces!

How many hours of productive time has been wasted in meetings arguing the pros and cons of each? Does Perl care whether you've used spaces over tabs or tabs over spaces? We've already agreed that most editors can seamlessly convert between tabs and spaces of any desired indent size. The pettiness of it just blows my mind.

Here's a standard: forget standards. Use Perltidy.

A large portion (if not all) of the coding standards listed here could be configured into Perltidy. If every piece of code passed/used/saved anywhere in the company is enforced through Perltidy, then all code will conform to a single layout standard. The coders don't need standards, they can code to what ever style they feel comfortable with. After a pass through Perltidy everybody's code will conform to the same single standard.

In time coders will make an effort to conform to that same standard that they've been immersed in because it's just easier to adjust one's personal style choices than to buck miles of existing code. But even if they don't come around, who cares? In the end the code will come out formatted to standards regardless, and all the time that would have been wasted arguing over standards can be put to better use getting actual work done.

end grump
  • Comment on Re^3: On Coding Standards and Code Reviews

Replies are listed 'Best First'.
Re^4: On Coding Standards and Code Reviews
by Tanktalus (Canon) on Feb 22, 2009 at 15:00 UTC

    You're right. It's tabs and spaces. That's exactly why it's important to write it down (complete with pros/cons and links), and end the debate. That's why I think it's a good idea to put it in the rules - so you don't keep going around and around on it. I'm not convinced there is an obviously-right answer (i.e., one that you'll get everyone to facepalm and say, "of course, that's right!"), which means you'll always get pushback. But if it's written down, explanation given, you'll probably at least find acceptance from those who disagree, and can move on to being actually productive.

    Of course, running your code through perltidy before checking it in (or, better yet, having the VCS running the code through whichever tidy tool is appropriate) is even better. But, even then, you'll have to explain why your tidy tools are doing this, so that those who disagree with the formatting option can be, well, silenced, if not assimilated. Otherwise, every time you hire a new person, you'll have to explain it all over again, even if it's automated via perltidy or whatever.

Re^4: On Coding Standards and Code Reviews
by dk (Chaplain) on Feb 24, 2009 at 12:45 UTC
    Here's a standard: forget standards.


    On the side node, I wish Perltidy would be able to convert between the horribleCamelCase and well_defined_underscore_names too.