I guess it may be just me, but I'm curious as to why. Some of your suggestions/commandments are purely arbitrary, and I don't use that in a negative light as sometimes there is no best choice and consistency is more important, but I'm still curious as to why you chose that arbitrary rule over another similarly-weighted controversial rule.
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. This goes doubly, if not more, if you're going to need to not just defend your rules against peers in your organisation, but against every single new hire for the rest of your tenure there. It also allows the rules to be properly challenged if, for example, the significance of your decision is reduced.
As an example, continuing to pick on the spaces vs tabs, perhaps it is desirable for each developer to use the tools they're most comfortable with. That may mean some of your developers using eclipse, others using emacs, others using vi, and the odd wacko using notepad, as long as each is highly productive. But then, perhaps your management (either personnel or technical) decides for some reason to standardise on an environment - whether that's MS Visual Studio, Eclipse, or Komodo. Now maybe the reason for spaces goes away, and it can be revisited. But without a continued, on-going understanding of the reasoning, your rules become unchallengeable shackles or cargo cult, possibly long outliving their usefulness.
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.
My second suggestion would be to store the whole thing in a corporate wiki where others can add their reasons for (or possibly even against) each dictum, making it (hopefully) feel less like dictum, and more like group selection, and thus easier to self-enforce. It also would help keep the document living which helps it stay in use, as well as keeps it available for challenge.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||