Additional Resources

 < Free Open Study > 

cc2e.com/3208

In addition to the IEEE standards, numerous other resources are available on program documentation.

Spinellis, Diomidis. Code Reading: The Open Source Perspective. Boston, MA: Addison-Wesley, 2003. This book is a pragmatic exploration of techniques for reading code, including where to find code to read, tips for reading large code bases, tools that support code reading, and many other useful suggestions.

cc2e.com/3215

SourceForge.net. For decades, a perennial problem in teaching software development has been finding life-size examples of production code to share with students. Many people learn quickest from studying real-life examples, but most life-size code bases are treated as proprietary information by the companies that created them. This situation has improved dramatically through the combination of the Internet and opensource software. The Source Forge website contains code for thousands of programs in C, C++, Java, Visual Basic, PHP, Perl, Python, and many other languages, all which you can download for free. Programmers can benefit from wading through the code on the website to see much larger real-world examples than Code Complete, Second Edition, is able to show in its short code examples. Junior programmers who haven't previously seen extensive examples of production code will find this website especially valuable as a source of both good and bad coding practices.

I wonder how many great novelists have never read someone else's work, how many great painters have never studied another's brush strokes, how many skilled surgeons never learned by looking over a colleague's shoulder…. And yet that's what we expect programmers to do.

Dave Thomas

cc2e.com/3222

Sun Microsystems. "How to Write Doc Comments for the Javadoc Tool," 2000. Available from http://java.sun.com/j2se/javadoc/writingdoccomments/. This article describes how to use Javadoc to document Java programs. It includes detailed advice about how to tag comments by using an @tag style notation. It also includes many specific details about how to wordsmith the comments themselves. The Javadoc conventions are probably the most fully developed code-level documentation standards currently available.

Here are sources of information on other topics in software documentation:

McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998. This book describes the documentation required by a medium-sized businesscritical project. A related website provides numerous related document templates.

cc2e.com/3229

http://www.construx.com. This website (my company's website) contains numerous document templates, coding conventions, and other resources related to all aspects of software development, including software documentation.

cc2e.com/3236

Post, Ed. "Real Programmers Don't Use Pascal," Datamation, July 1983, pp. 263 265. This tongue-in-cheek paper argues for a return to the "good old days" of Fortran programming when programmers didn't have to worry about pesky issues like readability.

Checklist: Good Commenting Technique

cc2e.com/3243

General

  • Can someone pick up the code and immediately start to understand it?

  • Do comments explain the code's intent or summarize what the code does, rather than just repeating the code?

  • Is the Pseudocode Programming Process used to reduce commenting time?

  • Has tricky code been rewritten rather than commented?

  • Are comments up to date?

  • Are comments clear and correct?

  • Does the commenting style allow comments to be easily modified?

Statements and Paragraphs

  • Does the code avoid endline comments?

  • Do comments focus on why rather than how?

  • Do comments prepare the reader for the code to follow?

  • Does every comment count? Have redundant, extraneous, and self-indulgent comments been removed or improved?

  • Are surprises documented?

  • Have abbreviations been avoided?

  • Is the distinction between major and minor comments clear?

  • Is code that works around an error or undocumented feature commented?

Data Declarations

  • Are units on data declarations commented?

  • Are the ranges of values on numeric data commented?

  • Are coded meanings commented?

  • Are limitations on input data commented?

  • Are flags documented to the bit level?

  • Has each global variable been commented where it is declared?

  • Has each global variable been identified as such at each usage, by a naming convention, a comment, or both?

  • Are magic numbers replaced with named constants or variables rather than just documented?

Control Structures

  • Is each control statement commented?

  • Are the ends of long or complex control structures commented or, when possible, simplified so that they don't need comments?

Routines

  • Is the purpose of each routine commented?

  • Are other facts about each routine given in comments, when relevant, including input and output data, interface assumptions, limitations, error corrections, global effects, and sources of algorithms?

Files, Classes, and Programs

  • Does the program have a short document, such as that described in the Book Paradigm, that gives an overall view of how the program is organized?

  • Is the purpose of each file described?

  • Are the author's name, e-mail address, and phone number in the listing?


 < Free Open Study > 


Code Complete
Code Complete: A Practical Handbook of Software Construction, Second Edition
ISBN: 0735619670
EAN: 2147483647
Year: 2003
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net