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…
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).
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.
Meaningful Variable Names Source: The Art of Readable code
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.
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
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
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
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?
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?
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?
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?
Thanks for your firstname.lastname@example.org