5. Sources
• Schach, Stephen R. Object-Oriented and Classical
Software Engineering Eighth Edition. Mc Graw Hill,
2010
• Boswell and Foucher. The Art of Readable Code.
O’Reilly Media, Inc., 2012.
• Robert C. Martin. Clean Code - A Handbook of Agile
Software Craftsmanship. Pearson Education, 2009.
• Max Kanat-Alexander. Code Simplicity. O’Reilly
Media, Inc., 2012
• And so others…
7. Meaningful Variable Names
• meaningful variable names means: “meaningful
from the viewpoint of future maintenance
programmers.”
• consistent variable names, examples
• averageFreq , frequencyMaximum , minFr , and
frqncyTotl (X)
• frequencyMaximum / minimumFrequency (X)
• frequencyAverage, frequencyMaximum,
frequencyMinimum, and frequencyTotal, (OK)
• averageFrequency, maximumFrequency,
minimumFrequency, and totalFrequency (OK).
8. Meaningful Variable Names
• The idea is that the name of a variable should
incorporate type information.
• The best known of such schemes are the
Hungarian Naming Conventions, popularized
by Microsoft.
10. Self-Documenting Code
• The code artifact can be understood easily and
unambiguously by all the other programmers who have to
read it, starting with the software quality assurance group and
including a number of different postdelivery maintenance
programmers
• The problem becomes more acute in the light of the
unfortunate practice of assigning postdelivery maintenance
tasks to inexperienced programmers and not supervising
them closely. The undocumented code of the artifact may be
only partially comprehensible to an experienced programmer.
How much worse, then, is the situation when the
maintenance programmer is inexperienced.
12. Parameters
• All such apparent constants should be treated as
parameters. If a value should change for any
reason, this change can be implemented quickly
and effectively
• Better still, the value of the constants should be
read in from a parameter file at the beginning of
the run
13. Layout & Readability
• No more than one statement should appear on a
line, even though many programming languages
permit more than one.
• Another useful aid is blank lines. Methods should
be separated by blank lines; in addition, it often is
helpful to break up large blocks of code with
blank lines. The extra “white space” makes the
code easier to read and, hence, comprehend
16. Coding Standards
• 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 in the middle
of a project.
• Overly restrictive coding standards are
counterproductive, in that the quality of software
production inevitably must suffer if programmers
have to develop software within such a
framework
17. So…
• Think about code inspection
• Look for tools for supporting your code
inspections
• How are integrated the tool(s) with your
development environment?
(Including CI, development platform,
versioning)
• How the tool(s) make inspections/analysis to
the code in the chosen language?
18. So…
• ¿Code Inspection and Code analysis are the
same?
• ¿Which is the role of debugging in the code
analysis?
• The tool supports static and/or dynamic analysis?
• How can you configure the rules for code
analysis / inspections?
19. So…
• What advantages gives you SONAR for the code
inspection process?
• SONAR “contains” the chosen tool(s)?
• Are there some ways for linking the code
inspection tool (and SONAR) with your
development environment?
• The chosen tool(s), and SONAR, give you some
sub-tools or plugins for improving the productivity
of your developer team? ¿Which?
20. So…
• ¿Are there any previous coding standard that you
can use?
• ¿Are there any guideline for reviewing your code
in the language that you work?
