The document discusses key concepts and best practices for code inspections, including using meaningful variable names, writing self-documenting code, treating constants as parameters, improving layout and readability, and following coding standards. It emphasizes that the goal of code inspections and analysis is to make code maintenance easier by ensuring the code is understandable and unambiguous. It also suggests considering tools that integrate with development environments to support automated code inspections and analysis.

1. Code Inspections
Ideas & Conceptualization

2. Before

3. Before
http://thenextweb.com/shareables/2011/01/
08/how-to-write-good-code-cartoon/

4. Agenda
• A set of ideas about code inspection

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…

6. Key Issues
• Meaningful Variable Names
• Self-Documenting Code
• Parameters
• Layout & Readability
• Coding Standards

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.

9. Meaningful Variable Names
Source: The Art of Readable code

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.

11. Self-Documenting Code
Source: Object-Oriented and Classical Software Engineering Eighth Edition

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

14. Layout & Readability
X-(
X-(
=)

15. Layout & Readability
=)

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?

21. Thanks for your attention
fdgiraldo@uniquindio.edu.co