Information Technology Reference
In-Depth Information
The team will work with the customer to decide which stories and in what order
they will be grouped and produced for various releases of the software.
2. Design. The design phase of XP encourages simple design, CRC cards, and
spike solution prototypes. CRC cards, or class-responsibility cards, designate
classes to be used in the development of the current software increment; the
team produces only these are their method for organizing design. A spike
solution is a working prototype of a specific portion of the design that is
potentially difficult; these are made in order to reduce problems and risk related
to the portions future implementation.
3. Coding. Often recommending two programmers coding at once, XP will have
team members develop tests for the various stories in the current increment.
Code created by the pairs will be implemented as a part of the whole increment
with other pairs' code, often integrating these parts on a continuous basis.
4. Testing. While testing and small problem correction is done by the team on a
continuous basis, rather than fixing major problems near the end, the customer
will specify and review tests as well before the release of the increment.
Once completed, the increment is released and the next is began. It is worth
noting that the XP paradigm often times prefers to make use of the object-oriented
approach.
9.8 Code Style Standards
Coding standards can be both a blessing and a curse. A useful rule of thumb is that
if statements should not be nested to a depth that is greater than three. If pro-
grammers are shown examples of unreadable code resulting from nesting if
statements too deeply, then it is likely that they will conform to such regulation.
Below are the few rules Schach describes
• Nesting of if-statements should not exceed a depth of three
• Modules should consist of between 35 and 50 statements
• The use of goto statements should be avoided
The aim of coding standards is to make maintenance easier. However, if the
effect of a standard is to make the life of software developers difficult, then such a
standard should be modified, even if such a modification must occur in the middle
of a project. Overly restrictive coding standards such as those just listed regarding
nesting of if statements, module size, and goto statements, coupled with a
mechanism for deviating from those standards, can lead to improved software
quality, which, after all, is a major goal of software engineering (Schach
1999
).
Many recommendations on good coding style are language specific. Here are a
few
programming
practices
that
are
generally
considered
to
be
acceptable.
(Schach
1999
).
