What was the strangest coding standard rule that you were forced to follow?

Re:What was the strangest coding standard rule that you were... by biot on Tuesday December 04, 2012 @05:23AM (#4870233)

  > To NEVER remove any code when making changes. We were told
  > to comment all changes.

I'm afraid given this rule, I would abuse it horribly. My backspace key would no longer function and every typo I make would introduce a new set of /* */ comments. Every refactoring would have the old type, variable, line, function, or entire class commented out with the fixed code alongside it. Bonus points for interleaving the old code and replacement code.

[ Parent | on HN ]

Re:What was the strangest coding standard rule that you were... by Shivetya on Tuesday December 04, 2012 @05:45AM (#4870291)

I understand the rule, we have this rule in place with a caveat. The rule protects us from a few common events, first being that where some developers just love to tinker with code outside the scope of their project. The second is simply a bad design where the results affected other code in unexpected ways.

There have been a few times were code was reverted and having the code merely commented out saved time, time spent cut/pasting from archive. Even with a good CMS keeping commented out code can serve another purpose, knowing what was when and why. That way we can avoid the "well back in year X we had a rule" because we have the code readily accessible.

For large blocks (subroutines/procedures/etc) it is not uncommon to move the whole to the end of the source.

[ Parent | on HN ]

Re:What was the strangest coding standard rule that you were... by glennsayers on Tuesday December 04, 2012 @05:52AM (#4870303)

"saved time, time spent cut/pasting from archive"

Surely source control would be a nicer way than copy/pasting old code back in?

[ Parent | on HN ]

Re:What was the strangest coding standard rule that you were... by wladimir on Tuesday December 04, 2012 @06:18AM (#4870359)

I've seen this mostly as workaround for broken source control systems, along with a change log at the top of each file. For example with ClearCase it can be a hell to find out preceding revisions of a file (the tools are slow and very user unfriendly), actions that are trivial with more modern systems.

I tend to agree more with coding guidelines that go exactly the other way: Do not leave around any commented out or dead code. It breaks the flow of reading the code and can cause confusion as to what is actually happening. If you need to refer to an old state of the code, just provide a commit id in your comment.

[ Parent | on HN ]

Re:What was the strangest coding standard rule that you were... by bruceboughton on Tuesday December 04, 2012 @06:00AM (#4870319)

>> Even with a good CMS keeping commented out code can serve another purpose [..]

This, here, is your problem.

[ Parent | on HN ]

Re:What was the strangest coding standard rule that you were... by alexchamberlain on Tuesday December 04, 2012 @08:42AM (#4870822)

What is wrong with developers tinkering with code outside the scope of their project?

[ Parent | on HN ]