Here is what I always suggest:
- Yes, develop clear guidelines for how the code should look ... indeed, for how the entire development process should be conducted by all concerned, from specification to quality-assurance to support. Involve every individual in establishing those procedures so that you can get both maximum “buy-in” and maximum professional input.
- No, don’t use a computer as a gatekeeper or an Enforcer. (Computers only understand if .. then .. else, and no programming language really understands unless.) Instead, make that a team responsibility along with everything else. The computer is wonderful at “never overlooking a single detail,” and you should of course exploit that power wherever possible, but it cannot think, therefore it must never be put in a position in opposition to those who can.
The best “trick of the trade” is peer review, yet the primary benefit of this is not to enforce (arbitrary ...) “coding standards,” but rather, to catch mistakes. Mistakes in code-writing are rare. What isn’t rare?: mistakes in the understandings that led up to the design/writing of that code. Stuff that might easily pass one pair of eyes is very unlikely to make it past two pairs. People who are looking over each others’ shoulders are also talking. Cubicle walls can become silo walls, and ... careful, now! ... if you are both “a coder” and “a manager,” the very-worst offender just might be you! (Sure, you know the system inside and out, but does everyone else in your team know as much as you do? Uh huh ... go fix that.) If people are in agreement about “best practices” for
your their shop, and if they are genuinely aware-of and involved in what their peers are doing alongside them, then high-quality code (and a high-quality total development environment) will be the result. In all my years, I have never met a “genuine slacker” who did not care about what s/he was dong, nor a “genuine incompetent.” Never. Software developers as a breed know how vital their work is, and strive to do it well. You just need to maintain an environment in which everyone including you can succeed.
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.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||