09-08-2012, 01:14 PM
Software Development Guidelines
Software Development.pdf (Size: 308.65 KB / Downloads: 72)
Introduction
The intent of this document is to create a guide for software source code quality. The guidelines
appearing herein apply to anyone who creates, modifies, or reads software source code.
This document is not a description of a complete software process. A particular group will need to
develop their own methodologies and procedures for the specification, design, implementation, testing,
and deployment of their software systems. This document is simply a set of rules to follow during the
implementation phase that will help produce a higher quality result.
This document addresses general and language-specific topics. The general concepts apply on any
project regardless of any implementation details. The language specific topics apply to a project in
addition to the general guidelines once a given programming language has been chosen for the project.
One restriction often found in corporations involving software engineering is the choice of programming
language for a project. Many IS shops are "one-language" houses. A corporation, for example, may hire
only COBOL programmers and insist that all programs, regardless of their nature, be written in COBOL.
Other companies do not have this policy. This allows engineers the flexibility to choose the appropriate
tool for the job; it also demands a certain amount of flexibility insofar as engineers must be capable of
working with legacy code written in any of several different languages.
What This Process Will Achieve
You can hope to achieve three goals by requiring a consistent source code style:
l Improve the productivity of existing programmers.
Allow new programmers to become comfortable with existing source code in less time than would
otherwise be necessary.
l
Allow existing programmers to move around to different projects easily without having to adjust
to the programming style in use by other groups.
l
Standardizing the "look and feel" of the source code will reduce the time to market, it will reduce the
time spent correcting problems in the product line, and it will give engineers the flexibility to jump on
and off projects without a large learning curve. This means that you will be able to spend less time on
legacy products and jump into the more interesting task of designing and implementing future products.
How These Guidelines Will Affect You
This coding standard is not intended to be down to the level of dotting i's and crossing t's. It is flexible
enough to allow some breathing room while still achieving a visual standard in the way code is written.
Nevertheless, we all have coding habits we've developed over the years that we will need to change. As
noted above, human nature resists change. However, with the right attitude, perhaps approaching
learning this new style with the same sense of curiosity or excitement you would have when learning a
new language, you will find that the process of changing these old habits is straightforward.
Almost everyone will need to make some changes to their coding styles. Many people view this as an
assault on their personality. After all, we all like to believe we are unique (especially software
development types) and many of us tend to exhibit our personality in our programming style. Individuals
often view any attempt to conform their programming style to some "standard" as a step in conforming
their personality as well. However, this is really no different than expecting programmers to write their
comments in English rather than, say, French or Spanish.
What the Style Guidelines do Cover
Software development occurs in different languages, environments, and on different machines. These
style guidelines attempt to generalize programming style across these divergent systems. For example,
assume you've written a program in two different languages. If those two languages share some
approximately equivalent statements and semantics (e.g., BASIC and C), the two programs should look
very similar. Obviously, some language pair choices (e.g., Pascal/assembly, BASIC/LISP, or C++/SETL)
will look quite a bit different, but many elements in the pairs should be identical, including variable
names, comments, etc.
Although this specification attempts to be generic, there are some language-specific issues that any set of
generic style guidelines must address. Language-specific issues appear in later sections.