Just to pick on the first one that popped out, using spaces over tabs. Don't get me wrong, I agree with it, but I know it's contentious, and would prefer to see something that expanded on why.

Tabs are a bad choice for indenting code, even if you set your editor's tabspacing to four columns. Tabs do not appear the same when printed on different output devices, or pasted into a word-processor document, or even just viewed in someone else's differently tabspaced editor.

For some of these layout rules (e.g. brace placement), we already fought a war some years ago and I don't want to reopen old wounds. With over ten million lines of existing code, it doesn't seem worthwhile to change longstanding company code layout conventions.

I know you have lots of links, but, without going through each one manually, it's difficult to know (in general) which link defends which rule. Some are obvious, but not all, so you should still have as direct of links as possible for most items.

Tabs are a bad choice for indenting code, even if you set your editor's tabspacing to four columns. Tabs do not appear the same when printed on different output devices, or pasted into a word-processor document, or even just viewed in someone else's differently tabspaced editor.

Having lot of respect for Damian Conway I would like to point out that almost all useful editors allow you to define the tab length. Be it 2, 4 or 8 spaces. Using tabs allows every developer to have their own indentation level by defining the tab width in their preferred editor/pager/viewer settings. Using spaces forces one indentation scheme (and forcing people is a bad thing). I always tell people who are arguing over indentation that whether you choose to use tabs or spaces you must use it systematically. Do not mix tabs with spaces.

I use spaces my self (spaces are what I am accustomed to), but I do not despise tabs.

--
seek $her, $from, $everywhere if exists $true{love};

I'm not sure allowing each developer to set their own indentation level works very well in teams doing pair programming. FWIW, Michael G Schwern holds the same view as Damian:

Here's all I have to say about tabs. I expect the source to look the same no matter whose editor, pager, printer or utility I run it through. Literal tabs violate this. The end.

I also notice that the Parrot coding standard mandates that "Indentation must consist only of spaces".

Though I agree with Conway and Schwern on this, the main reason I chose spaces over TABs is that is we currently do that (mostly), and I don't want to change over a million lines of legacy code. :-)

I would like to point out that almost all useful editors allow you to define the tab length. Be it 2, 4 or 8 spaces.

I would like to point out that those very same editors have a setting that when enabled will automatically converts tabs into a user-definable number of spaces.

Having lot of respect for Damian Conway I would like to point out that almost all useful editors allow you to define the tab length. Be it 2, 4 or 8 spaces.

And that's the one and only the reason why tabs are evil. Tabs are fine if they act the same in every editor.

Suppose you have a 80-column coding standard. You have a 3 character indent as standard. You set your tab width to 3 spaces because you indent with tabs, and you have a subroutine containing a loop, and an if statement in that loop. Inside the then block, you have a 65 character line. In your editor, the line ends in column 74, well within the boundaries.

Now the next person never uses tabs, and uses an editor (s)he didn't customize to your habits. Hence, the tabwidth will be at 8. Now your 65 character statement ends at column 89, violating the coding standard.

That's why tabs are evil. Because you do not know how where the tabstops of the next person will be. Spaces are predictable. Tabs aren't.

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

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.

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.