I agree with you especially when analyzing the micro-code of for loop vs while loop (although I would argue that some people attempt to micromanage that as well with coding standards docs).

The overall patterns and practices I am speaking to is more about separation of concerns, single responsibility, and protection of objects.

For example, a correct architecture that has hides actual implementations, provides only factory mechanisms (or DI) to retrieve dependencies, and only provides exposure to the appropriate layers actually does force developers into putting things in the correct place. Does it stop them from wiring up wrong things? Does it stop them from writing junk code? Does it stop them from changing the code to expose everything publicly? No, no, and no – however, they have to really try hard to go against the grain *plus* it is very obvious when they do.

Developers will most likely build an architecture that forces other people’s code to look like theirs. For example, requiring passing unit tests to pass the build – good. Requiring a certain minimal test coverage to pass the build – good. All of that is an example of imposing constraints that are good, but none of that has -any- say whatsoever into what the code looks like, or what patterns it uses.

We spend so much time trying to hire great people, train them and then say: I don’t trust you to figure the best way out yourself? As far as I’m concerned, forcing patterns into people’s code (or out of them) is like telling them to use a while loop instead of a for-loop. It’s subjective and way too micro-managing.

The only times it’s going to help (as opposed to just being annoying and limiting) is when you have bad programmers. And if you have bad programmers, you’re basically screwed no matter what you do.