ProcessesShouldNotForcePeople to obey certain rules. If they do, those rules are likely to be broken everywhere.

A common example of a rule that I have seen people violate is the following style guideline:

   if(it_is_true)
   {
      do_something();
   }
is required instead of 

   if(it_is_true)
      do_something();
''Rule:'' All branches of conditionals should be encompassed by braces.

The odd thing is that the developers who push this rule are the ones who most often violate it!

An example of a rule that works within this principle is ''indenting guidelines in Java,C or C++''.

Since emacs will automatically reindent a whole file in one command, this rule is easily obeyed by all programmers. If someone would make a mistake about indenting rules, then the files can easily be fixed.

An example of a rule that violates this principle is ''the use of naming conventions in C++.''

In Smalltalk or Java such a naming convention would not be a major hardship. A person could periodically check whether he was following style guidelines. If he made a mistake and violated a guideline, it would be easy to fix. Just use a refactoring browser.

In C++ there are no refactoring browsers, nor will there be in the near future. So fixing a guideline mistake can become quite hard. Some mistakes would be left standing. Eventually there would be enough mistakes that the guidelines go out the window.

-- ThaddeusOlczyk

----

''Reductio ad absurdum'': An example of a rule that violates this principle is "don't write code with stupid bugs in it". People don't find it easy not to put bugs in their code, and no RefactoringBrowser can find all the silly bugs in your code. Therefore it's wrong to ask programmers to write code without bugs.

This is perhaps slightly unfair, since we ''don't'' exactly ask programmers to "write code without bugs"; but we certainly want them to try, and when a bug is found it needs to be fixed. Since this manages to happen despite the fact that bug-avoidance and bug-fixing can't be mechanized, it's clear that sometimes it makes sense to aim for things that aren't easy and can't be mechanized.

An obvious difference is that bugs are bad in themselves, whereas non-adherence to conventions is only "secondarily" bad. But I think the above shows that ''if'' some convention is worth following then the fact that it forces people to do things they may hard needn't in itself make it a bad convention.

I should perhaps mention that I think the underlying point is sound: conventions that are easy to work with smoothly are better. I just don't think all conventions that aren't so easy to work with need be bad.

-- GarethMcCaughan
----
Bogus argument.

There is another guideline which is, rules should be well-defined. Which means that the term bug needs to be well-defined. Care to try?

-- ThaddeusOlczyk
----

The best definition of a bug: "something that fails the UnitTest or FunctionalTest". So your rule is run UnitTest and run FunctionalTest. It fails to satisfy the rule ProcessesShouldNotForcePeople; if anything, it supports it.

ThaddeusOlczyk
----
See also BadCodingStandards, ThreeRingBinder''''''s