📄 ch16_02.htm
字号:
<?label 16.2. Coding Guidelines?><html><head><title>Coding Guidelines (CGI Programming with Perl)</title><link href="../style/style1.css" type="text/css" rel="stylesheet" /><meta name="DC.Creator" content="Scott Guelich, Gunther Birznieks and Shishir Gundavaram" /><meta scheme="MIME" content="text/xml" name="DC.Format" /><meta content="en-US" name="DC.Language" /><meta content="O'Reilly & Associates, Inc." name="DC.Publisher" /><meta scheme="ISBN" name="DC.Source" content="1565924193L" /><meta name="DC.Subject.Keyword" content="stuff" /><meta name="DC.Title" content="CGI Programming with Perl" /><meta content="Text.Monograph" name="DC.Type" /></head><body bgcolor="#ffffff"><img src="gifs/smbanner.gif" alt="Book Home" usemap="#banner-map" border="0" /><map name="banner-map"><area alt="CGI Programming with Perl" href="index.htm" coords="0,0,466,65" shape="rect" /><area alt="Search this book" href="jobjects/fsearch.htm" coords="467,0,514,18" shape="rect" /></map><div class="navbar"><table border="0" width="515"><tr><td width="172" valign="top" align="left"><a href="ch16_01.htm"><img src="../gifs/txtpreva.gif" alt="Previous" border="0" /></a></td><td width="171" valign="top" align="center"><a href="index.htm">CGI Programming with Perl</a></td><td width="172" valign="top" align="right"><a href="ch17_01.htm"><img src="../gifs/txtnexta.gif" alt="Next" border="0" /></a></td></tr></table></div><hr align="left" width="515" /><h2 class="sect1">16.2. Coding Guidelines</h2><p>Programmers inevitably <a name="INDEX-3159" /> <a name="INDEX-3160" /> <a name="INDEX-3161" />develop their own style for writingcode. This is fine so long as the developer works alone. However,when multiple developers each attempt to impose their own style on aproject, it will inevitably lead to problems. Code that does notfollow one consistent style is much more difficult to read andmaintain than uniform code. Thus, if you have more than one developerworking on the same project, you should agree on a common style forwriting code. Even if you are working alone, it is a good idea tolook at common standards so that your style does not become sodifferent that you have problems adapting when you do work withothers.</p><p>Here are some topics that a style <a name="INDEX-3162" />guide should cover, along withsuggestions. These suggestions follow the syntax that was usedthroughout this book, largely based upon the style suggested inthe<em class="citetitle">perlstyle</em>manpage:</p><ul><li><p><em class="emphasis">Flags andpragmas</em><a name="INDEX-3163" /><a name="INDEX-3164" />. This covers the first couple oflines of your code:</p><blockquote><pre class="code">#!/usr/bin/perl -wTuse strict;</pre></blockquote><p>You may want to require taint mode on all your scripts or allowcertain exceptions. You may want to enable warnings by default forall of your scripts too. It is certainly a good idea to require thatall scripts use strict and minimize the use of global variables.</p></li><li><p><em class="emphasis">Capitalization</em><a name="INDEX-3165" /><a name="INDEX-3166" />. This includes thecapitalization of variables (both local and global), thecapitalization of subroutines, the capitalization of<a name="INDEX-3167" /><a name="INDEX-3168" /><a name="INDEX-3169" />modules, and thecapitalization of filenames. The most common convention in<a name="INDEX-3170" />Perl is to use lowercase for localvariables, subroutines, and filenames; words should be separated byan <a name="INDEX-3171" /> <a name="INDEX-3172" />underscore. Global variables should becapitalized to make them apparent. Module names typically use mixedcase without underscores. Note that this convention is quitedifferent from the mixed case conventions of other languages likeJavaScript or Java.</p></li><li><p><em class="emphasis">Indentation</em><a name="INDEX-3173" /><a name="INDEX-3174" /><a name="INDEX-3175" />. This should specify whether to use tabsor spaces. Most editors have the option to automatically expand tabsto a fixed number of spaces. If spaces are used, it should alsoindicate how many spaces are used for a typical indentation. Three orfour spaces are common conventions.</p></li><li><p><em class="emphasis">Bracketplacement</em><a name="INDEX-3176" /><a name="INDEX-3177" />. Whencreating the body of a subroutine, loops, or conditionals, theopening brace can go at the end of the statement preceding it or onthe following line. For example, you can declare a subroutine thisway:</p><blockquote><pre class="code">sub sum { return $_[0] + $_[1];}</pre></blockquote><p>Or you could declare it this way:</p><blockquote><pre class="code">sub sum{ return $_[0] + $_[1];}</pre></blockquote><p>This very trivial distinction somehow manges to generateserious discord among some developers. The latter is familiar toprogrammers who have written a lot of C, while the former is morecommon in Perl.</p></li><li><p><em class="emphasis">Documentation</em><a name="INDEX-3178" />. You don't need to decidewhether to document your code or not; obviously you should. However,you may want to decide certain standards for it. Remember that thereare different levels of documentation. Documentation can includecomments within your code adding explanation to sections of code.Documentation can also include an overview of the purpose of a fileand how it fits into the larger project. Finally, a project itselfmay have goals and details that don't fit within particularfiles but must be captured at a more general level.</p><p>Youshould decide how you will capture each of these levels in yourdocumentation. For example, will all of your files use Perl's<em class="emphasis">pod</em> format to capture an overview of theirpurpose? Or will you use standard comments or capture documentationelsewhere? If so, what about your shared modules? If developers mustinterface with these modules in the future, <em class="emphasis">pod</em>is a convenient way for them to find the information they need to doso.</p><p>You also may wish to create standard templates forcomments that appear at the beginning of a file and at the beginningof each subroutine. We have omitted large blocks of<a name="INDEX-3179" />comments in this book becausewe review each section of code afterwards. However, most productioncode should include details such as who wrote the code, when theywrote it, why they wrote it, what it does, etc. A revision controlsystem that captures some of these details can help immensely.</p></li><li><p><em class="emphasis">Grammar</em><a name="INDEX-3180" /><a name="INDEX-3181" />. This defines the rules forchoosing names of variables, subroutine calls, and modules. You maywish to decide whether to keep variable and subroutine names long orallow abbreviation. You may also want to make rules about whether touse plural terms for naming data structures that contain multipleelements. For example, if you pull data from a database, do you storethe list in an array named <tt class="literal">@rec</tt> or<tt class="literal">@record</tt> or <tt class="literal">@records</tt>? Long namesand plural names for compound data are probably more common.Similarly, the names of subroutines are typically actions while thenames of modules (which are also class names for object-orientedmodules) are typically nouns.</p></li><li><p><em class="emphasis">Whitespace</em><a name="INDEX-3182" />. One thing that cancertainly contribute to making code easier to read and thus maintainis an effective use of whitespace. Separate items in lists withspaces, including parameters passed to functions. Include spacesaround operators, including parentheses. Line up similar commands onadjacent lines if it helps make the code clearer. One the other hand,one shouldn't go overboard. Code with lots of formatting iseasier to read but you still want it to be easy to change too,without the maintainer needing to worry too much about reformattinglines.</p></li><li><p><em class="emphasis">Tools</em>. You may wish to standardize on<a name="INDEX-3183" />tools such as modules fordevelopment. It helps if everyone agrees on one particular method ofgenerating output, such as CGI.pm, an HTML template module, etc.</p></li><li><p><em class="emphasis">Additions</em>.This list is by no means exhaustive, so keep your style guidedynamic. If issues come up that are not covered by the style guide,work out a solution and then <a name="INDEX-3184" />update the guide.</p></li></ul> <p>Don't forget to document othergeneral development and architectural guidelines too, such as thosewe have discussed earlier in this chapter and throughout the book.However, keep in mind the goal is to be organized, not bureaucratic.You should not be heavy handed about guidelines. It is not possible,nor desirable, to make everyone's code look the same. The goalis simply to allow developers to work with each other's codewithout difficulty. Also, style decisions should be determined bydiscussion and consensus, not dictated. Keep it <a name="INDEX-3185" /> <a name="INDEX-3186" /> <a name="INDEX-3187" />fun.</p><hr align="left" width="515" /><div class="navbar"><table border="0" width="515"><tr><td width="172" valign="top" align="left"><a href="ch16_01.htm"><img src="../gifs/txtpreva.gif" alt="Previous" border="0" /></a></td><td width="171" valign="top" align="center"><a href="index.htm"><img src="../gifs/txthome.gif" alt="Home" border="0" /></a></td><td width="172" valign="top" align="right"><a href="ch17_01.htm"><img src="../gifs/txtnexta.gif" alt="Next" border="0" /></a></td></tr><tr><td width="172" valign="top" align="left">16. Guidelines for Better CGI Applications</td><td width="171" valign="top" align="center"><a href="index/index.htm"><img src="../gifs/index.gif" alt="Book Index" border="0" /></a></td><td width="172" valign="top" align="right">17. Efficiency and Optimization</td></tr></table></div><hr align="left" width="515" /><img src="../gifs/navbar.gif" alt="Library Navigation Links" usemap="#library-map" border="0" /><p><font size="-1"><a href="copyrght.htm">Copyright © 2001</a> O'Reilly & Associates. All rights reserved.</font></p><map name="library-map"><area href="../index.htm" coords="1,1,83,102" shape="rect" /><area href="../lnut/index.htm" coords="81,0,152,95" shape="rect" /><area href="../run/index.htm" coords="172,2,252,105" shape="rect" /><area href="../apache/index.htm" coords="238,2,334,95" shape="rect" /><area href="../sql/index.htm" coords="336,0,412,104" shape="rect" /><area href="../dbi/index.htm" coords="415,0,507,101" shape="rect" /><area href="../cgi/index.htm" coords="511,0,601,99" shape="rect" /></map></body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -