A recent discussion on our mailing list revolved around the use of regions, and whether stripping them out of a codebase was a useful first task when joining a new project! The conclusion was, sensibly, that there were more likely bigger fish to fry (especially since region outlining can easily be disabled in your IDE) and so regions should be left alone. Along the way, however, someone voiced an opinion that the software devs have a professional responsibility to adhere to existing standards.
Consistency in code is a great aid to readability – no doubt about it – but often someone needs to be the first to write a unit test, for example. The benefit that comes about from automated testing massively outweighs any benefit from uniform code, by many orders of magnitude. Similar arguments apply to use of IOC, good design of code, proper consideration of class / method / variable names, refactoring, SOLID principles and so on. All of these things are simply more important than whether you group all your methods into a region named “Methods” or not. And unfortunately, none of these items can be adequately codified into standards – it’s simply not possible.
Curiously, coding standards are so mechanical that they can actually be captured by software and fixes can be automatically applied. These are the only coding standards that I personally ever bother to try and apply on a project. I want development tools to be worrying about capitalisation, the presence or absence of underscores at the start of variable names, positioning of braces, and so on. I do not want developers to concern themselves with such issues – the time and brain power of a good developer is simply too valuable to waste on such niceties.
Adherence to coding standards is just like tidying the decks of a ship. It’s a good thing to do … just make sure that you aren’t on a Titanic that is slowly sinking into the deep!