No downvote; you're entitled to your opinions and local practices, but the only items I can endorse are 1, 2 and possibly 8 ... and even those have exceptions.
As for the rest of the list? Contentious, at best. Some shops will work well with your kind of internal policy; others would turn into hell-holes were they to adopt this kind of rigid (and, in many cases, IMO, ill-advised) rules.
- 3: Some of us regard nested } else { statements as easily readable. Though trivial, for me, the required, subsequent additional scrolling in't worth the supposed gain.
- 4: Perhaps a good idea if your shop is mostly full of minimum-wage noobs. The kind of breakage you're trying to avoid isn't generally a problem with skilled programmers given time to work carefully (...yeah, yeah, yeah -- but I'd love to live :) in a more nearly perfect world.)
- 5, 6 & 7: Again, arguably reasonable as a standardization technique; the specifics, however, are not universally acceptable.
- 9 & 10: Aw, c'mon. Are your minimum-wage hacks also unable to read code accurately?
- 11 & 12: Bunkum, IMO, but at least present them as the single point they actually constitute.
- 13: Well.... maybe. The headline statement is valuable; the narrative wanders off into disputable territory.
Now, how about some items that should be included:
- use strict; use warnings; (oops, two statements on one line...) UNLESS you are very sure of a good (coding) justification for omitting them!
- Generally, prefer use warnings over -w because of its limited scope (of course, if incompetents are writing the modules or somesuch, ignore this rule).
- Indent and break logical sections with an extra newline (yes, I know this is at least to some extent inconsistent with the observation about your 3. "Consistency," a wise man observed, "is the hobgoblin of little minds.") Use white space to make your code easy to follow.
- (Add some of of many possible guides on commenting.) My own choice would be to tell the programmers to use inline comments only for non-routine syntax or unusual construct (and I would provide some format guidlines: same line? minimum white space between code a # comment..., etc). Advise that the concepts behind most routine comments are better included in documentation, whether plain POD or something more elaborate.
- Documentation. The programmer(s) should know better than anyone else the high points and the lows; the capabilities and perhaps the shortcuts available to the end user. Don't simply hand that off to tech writers who may or may not have the skills and experience to fully explain your code.
PS: Don't mix as many fonts and styles as I've done here :(
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:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, 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, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.