Achieving Software Quality through Source Code ... - CiteSeerX

Achieving Software Quality through Source Code Readability PREPARED BY

Phillip Anthony Relf for

Qualcon 2004

QUALCON 2004

1

ABSTRACT Software quality is not defined in terms of quality attributes but instead must be inferred from characteristics that correlate to quality attributes and defect attributes. One of these quality attributes is the readability of the software. However, the software engineer, who is ultimately responsible for software quality, is not supported well by their formal education, the software engineering culture, the existence of useful tools and where these tools do exist by their limited up-take by industry. Human cognitive limitations similarly frustrate the development of readable source code. This condition may be acceptable in the small (i.e., programs smaller than 5kSLOC) but are becoming untenable for large software systems development. Software characteristics have been identified, which correlate well to source code readability. One of these software characteristics, which have been supported by empirical research, is the choice of identifier name. This paper reports research identifying a number of identifier-naming style guidelines that direct towards improved source code readability. The paper also discloses attitudes of software engineers toward the acceptance of these guidelines.

Qualcon 2004 Paper Relf.doc

Page 2 of 18

QUALCON 2004

2

BIOGRAPHY Phillip Relf is currently working as the Research and Development Lead at Raytheon Australia. He has twenty-six years experience functioning as a professional software/systems engineer working at times in aerospace, defence and finance, both within the private and public sectors. During his professional career, Phillip has progressed from working as a coder through team leader to manager. Phillip has been actively involved with software quality and has held the positions of secretary and public officer in the South Australian Software Quality Association. During 2001 and 2002, he lead the software process improvement activity under a Capability Maturity Model (CMM) initiative at Raytheon Australia. Phillip gained his BSc in Computer Science and Logic at Adelaide University, Graduate Certificate in Software Engineering from the University of South Australia, Masters of Software Engineering from Deakin University and is a current PhD candidate at the University of Technology, Sydney.


Page 3 of 18

QUALCON 2004

3

INTRODUCTION The development of software, like any other manufacturing processes, can introduce defects in the resultant product. However, unlike other manufacturing processes, software is manufactured extensively once and then modified until sufficient defects have been removed such that the customer will accept the product. The customer may only be concerned with capability and will have no further interest in the internal software structure. However, some customers are becoming increasingly interested in the internal structure of software delivered to them as this has a flow-on effect to the cost of maintaining the product (i.e., the cost of modifying and adding new capability, which is distinct from the activity of software bug fixes). Customers may hence contractually impose software quality standards on their contractors. These standards are interpreted by the contractor and typically further standards are derived such as the project coding standard. No matter how prescriptive the software quality standards and the derived standards are the responsibility to deliver a defect free product ultimately rests with the software engineer. However, the software engineer suffers from various cognitive limitations that make the production of readable software a difficult task. In addition, the software engineer is not prepared well by their education to address quality in their software development practices. Often they are given very general instruction, regarding what constitutes software quality, and rarely are they instructed in how to achieve the quality production of software. Their education is heavily waited towards discussing the production phase of the software lifecycle, with the maintenance phase given a rudimentary treatment at best. Similarly their peer culture and the culture of their management places little emphasis on future maintenance of the software during the development phase. Nor is there industry wide adoption of software quality tools that actively assist the software engineer to produce a quality product. This is partly due to our inability to specify how software quality is to be achieved.


Page 4 of 18

QUALCON 2004

4

CONTENTS

4.1

Software Quality Defined ISO-9126 defines a set of six quality attributes, i.e.: efficiency, functionality, maintainability, portability, reliability and usability. However, standards like ISO-9126 only offer top-level guidance that define software quality, they do not prescribe how to insert quality into software (Dromey, 1995). Some objective measure of software quality is required in order to categorise acceptable practices (Vollman, 1993) and software quality will not improve until there is a comprehensive definition available (Dromey, 1995). Advances in computer hardware, and problem-solving techniques; the specification of software processes; and changing programmer backgrounds and practices have modified our understanding of what constitutes software quality (Rajlich, 2001).

4.2

Software Quality Issues Software has transitioned from being considered as a liability to that of a re-usable asset. This shift in understanding now requires that software be written for maintainability (Troy, 1995). Of the software quality attributes defined by ISO-9126, maintainability is recognised by many researchers as having the largest effect on software quality (Troy, 1995). At the 1992 Software Engineering Productivity conference, a HewlettPackard executive stated that 60 – 80% of their research and development staff were involved with maintaining 40 – 50 million SLOC (Troy, 1995). Glass (2002) states that software maintenance consumes from 40 – 80% of the total software cost, with a mean of 60%. Boehm and Basili (2001) report a mean of 70%. Glass (2002) identifies a 1983 survey of the USA Air Force cites that reports their second biggest problem facing software maintenance, past high staff turn over, was understandability of the source code. Oman and Cook (1990b) state that approximately half of a maintenance programmer’s effort is spent on reading source code. Tenny (1988) considers program readability to be an important aspect of maintenance and defines readability within the context of program maintenance. The Software Productivity Consortium (SPC, TBD) asserts that, over the complete software lifecycle, source code will be read potentially many times but written only once. From this they draw the conclusion that the added cost in ensuring that the source code is readable and understandable is acceptable i.e., that the cost of software quality is cost-effective.


Page 5 of 18

QUALCON 2004

4.3

Software Engineer In the early 1970’s Weinberg (1998) stated that executives desired the elimination of programmers and financed this desire with “staggering funds”. Twenty-five years latter, the funds allocated remain staggering (Weinberg, 1998). McConnell (2001) observes that it was previously argued, the need for software engineering had gone as FORTRAN had removed the need for programmers by allowing formula to be directly written. This same argument was resurrected for Visual Basic, were it was claimed that drag-and-drop of graphics components have eliminated the need for programmers McConnell, 2001). Software engineers are still required and that the management of software quality issues requires that their cognitive limitations, their education, the culture that they work in and their exposure to software quality tools be considered.

4.3.1

Software Engineer – Cognitive Limitations Brooks (1995) states that software is unable to be visualised and this deprives us of one of our most powerful cognitive tools during the programming activity. During programming, the programmer must imagine how the program should behave dynamically and capture this behaviour statically as they compose the source code which places a large burden on working memory (Lieberman and Fry, 2001). Spinellis (2003) observes that programmers are poor at choosing meaningful identifier names because they find it difficult to concurrently manage the expression of programming constructs along with the managing of natural language description, say to invent identifier names. This activity appears too taxing on the programmer as it requires rapid context shifting between two different cognitive processes that use the same underlying apparatus (Spinellis 2003).


Page 6 of 18

QUALCON 2004

4.3.2

Software Engineer – Education Laitinen and Mukari (1992) observe that the limit of instruction given for identifier-naming by most programming texts is that names should be “clear and understandable” without explaining how this can be achieved. Mengel and Yerramilli (1999) observe that assisting students to appreciate the relative quality of their source code is a difficult activity, which is further degraded by the limited time that staff allocated for exercise grading. Weinberg (1998) observes that university software projects are typically not required to be maintainable, testable or even usable. Glass (2002) observes that in many universities the software lifecycle past coding is ignored. Glass (2002) states that defect removal, from source code, almost certainly requires the use of software tools. However, there are few university courses that introduce these tools that are necessary for maintenance and testing (Glass, 2002). Rising (1989) commented that software professionals were concerned that most computer science students have little understanding of how to develop software for large computer systems, and that they have been taught that maintainability and readability may be sacrificed towards the path to produce a correct program. Rising (1989) observes that programs are only correct for a fleeting period and only until the user wants greater capability. Oman and Curtis (1990a) state that computer science students are introduced to a few simple coding style rules and that these coding styles are addressed as a very small part of the course. This practice fails to communicate the importance of writing readable source code and also fails to communicate a coding style philosophy that is to be adopted for future software projects (Oman and Curtis, 1990a).

4.3.3

Software Engineer – Culture Slaughter (1996) reports that 80% of software quality programs fail within the first year and that these failures are not because of poor measurement techniques but due to cultural resistance on the part of the programmers and their management. Elshoff and Marcotty (1982) studied commercial programming practices and conclude that software was more complex than it needed to be and was very difficult to read. Nakashima et al. (1999) concluded that 50% of the design errors found in an electronic funds transfer system had a root cause of designer carelessness. A regime of reviews failed to result in improved quality, leading the authors to suppose that the designers did not have the proper attitude towards design (Nakashima et al., 1999). Neumann (2002) concludes that not only don’t programmers care that they produce a quality product but that their managers don’t care either. Neumann (2002) asserts that programmers can write good quality code but that only “big liability judgements” will force organisations not to deliver poor quality source code.


Page 7 of 18

QUALCON 2004

Haneef (1998) observes that most organisations do not cultivate or reward their programmers to produce readable programmes and that those organisations that do may ultimately fail as what may seem readable to the author may be unreadable to another. Boehm and Basili (2001) state that software defects can be reduced by 75% when disciplined personal practices are employed by programmers. However, Haneef (1998) suggests that management will sacrifice source code readability as the extra cost can only be recovered in the next production cycle, which is a future problem that can be ignored in the present. Humans will typically accept a payoff in the near-term rather than accepting a larger payoff in the more distant future, particularly when this payoff may be collected by another individual (Spinellis, 2003). 4.4

Identifier-Naming Style Guidelines Crutchfield (1994) defines what constitutes an identifier-naming style guideline, and in the more general form is stated as: Software quality guidelines are unambiguous, language-sensitive rules or constraints relating to measurable features of a program’s structure, semantics and syntax that affect its quality either positively or negatively. The identifier-naming style guidelines used by this research were identified from the published work of software professionals and are identified in annex A – Identifier-Naming Style Guidelines. These identifier-naming style guidelines were investigated to identify whether software engineering professionals would accept these guidelines as directing towards the production of improved source code readability.


Page 8 of 18

QUALCON 2004

4.4.1

Identifier-Naming Style Guideline Questionnaire An automated questionnaire was used to concurrently present two source code methods skeletons to the respondent. One of the source code method skeletons containing an identifier declaration that supported the identifier-naming style guideline and the other in the pair deviated from the identifier-naming style guideline. Each pair of source code method skeletons was dedicated to a single identifier-naming style guideline. Twenty-one pairs were generated using the Ada programming language syntax and nineteen pairs were generated using the Java programming language. At the time that the questionnaire was administered, the Java programming language did not support enumeration identifiers and hence two of the identifier-naming style guidelines were not appropriate as questions for the Java programming language method skeletons. The respondent could choose the questionnaire presentation to correspond to their preferred programming language between the two options available. The identifier-naming style guidelines were presented in random order each time the questionnaire was executed and the positional presentation alternated left/right for each source code method skeleton pair displayed, in order to reduce response bias. The responses were coded from 1 (i.e., strong acceptance of the guideline) through to 5 (i.e., strong nonacceptance of the guideline).

4.4.2

Identifier-Naming Style Guideline Expectations The expectation was that software professionals would tend towards acceptance of the identifier-naming style guidelines (primary expectation). It was also expected that Novice software engineers would tend less strongly, than the Expert software engineers, towards acceptance of the identifier-naming style guidelines that required greater cognitive effort to identify a deviation from the identifier-naming style guideline (secondary expectation), particularly as some of these identifier-naming style guidelines readily exceed human cognitive ability to apply in all but a trivial sized source code listing and hence must be individually discovered by the software engineer via experience.

4.4.3

Identifier-Naming Style Guideline Results Data has been collected from twenty-seven individual respondents and has been tabulated across nineteen identifier-naming style guidelines as most respondents chose to use the Java language and hence limited their responses to nineteen questions. All but one of the identifier-naming style guidelines had response means that support the primary expectation. The guideline that, only marginally, was not accepted was the suggestion that the word “class” should be concatenated to the end of a class identifier name. Overall, this result supports the primary expectation.


Page 9 of 18

QUALCON 2004

The respondents were categorised by whether they were a software professional Academic, Novice, Intermediate, Expert or Quality software engineer. Categories of software engineer were ranked by the number of mean scores for the category that indicated a stronger acceptance for the identifier-naming style guideline than the sample population mean score. The ranking is listed below, where the number in brackets corresponds to the number of stronger than average means against the sample population mean: •

Expert (13)

•

Quality (10)

•

Academic (7)

•

Intermediate (5)

•

Novice (5)

The above results suggest that Expert software engineers know what constitutes more readable software than both Novice and Intermediate software engineers. That is assuming that the identifier-naming style guidelines really do direct towards improved source code readability. For the software professional category transition ranging from Novice through Intermediate to Expert, trends are apparent in the acceptance of the identifier-naming style guidelines in four cases. Identifier-naming style guidelines 2 and 3 show a trend where the mean decreases (i.e., a tendency for increased acceptance with experience), and identifiernaming style guidelines 4 and 9 show a trend where the mean increases (i.e., a tendency for decreased acceptance with experience). The results for identifier-naming style guideline 2 (i.e., the use of contiguous multiple underscore characters in an identifier name) is not significant. A number of responses indicated support for this practice. However, when questioned about their response, they stated that they would never use multiple contiguous underscores in an identifier name and suggested that the apparent questionnaire flaw actually showed that there is a difficulty in distinguishing between identifiers that employ this practice and that their inadvertent erroneous selection actually supports the notion that this practice decreases source code readability as they found little to separate one example from the other. Four strong results indicating non-acceptance of a specific identifiernaming style guideline were received for the following identifier-naming style guidelines: 4 (Quality), 7 (Intermediate) and 10 (Academic and Novice).


Page 10 of 18

QUALCON 2004

As expected, Expert software engineers had a stronger than average tendency to accept the identifier-naming style guidelines that required greater cognitive effort to evaluate (i.e., the secondary expectation was satisfied) and the negative slope on the graph1 below, see figure 1, graphically represents this tendency. What was unexpected was that there would be a crossover between the attitudes of the Novice and those of the Expert. It would have been expected that for the identifier-naming style guidelines requiring the least cognitive effort, that the Novice and the Expert would be at least in a position of equality. The Expert software engineers demonstrated a lesser degree of acceptance for the identifier-naming style guidelines that require little cognitive effort in order to identify a deviation from the guideline that the Novice software engineer’s level of acceptance of the same guideline. Novice/Expert Mean Difference

Novice

Novice

Scatter Plot

Expert

0.3

4.5

0.2

4.0 3.5

0.1

3.0

0 -0.1

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Mean

Delta Sample Mean

Expert

2.5 2.0 1.5

-0.2

1.0

-0.3

0.5

-0.4

0.0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

-0.5 Identifier-Naming Style Guideline Number

figure 1 – Novice/Expert Mean Difference

Identifier-Naming Style Guideline Number

figure 2 – Mean Novice/Expert Scatter Plot

1

The graph was constructed by use of the mean squares method and used the deviation from the mean for the Novice and Expert software engineer categories.


Page 11 of 18

QUALCON 2004

The data used to generate the graph in figure 1 is presented in a scatter diagram, see figure 2. It is interesting to note that for identifier-naming style guideline 1, the Expert and the Novice software engineer have differing attitudes concerning the importance of un-named constants towards the readability of source code (i.e., Experts strongly accept the guideline and Novice are weak in their non-acceptance of the guideline). The data values for identifier-naming style guideline 1 was not used in the construction of figure 1 as the guideline does not relate to an identifier declaration but instead to the use of numeric literals within the body of a method.


Page 12 of 18

QUALCON 2004

5

CONCLUSION A software quality characteristic that has the potential to improve software quality is the choice of identifier name, and this is particularly so in large software systems. Identifier-naming style guidelines, supported by empirical evidence and generally accepted by software professionals to direct towards improved source code readability are candidates for automation by a tool. Such an automated tool could make visible aspects of software quality that are less keenly perceived by the novice programmer and could assist in their eduction along the path to expert status.


Page 13 of 18

QUALCON 2004

6

ACKNOWLEDGMENTS I would like to thank my PhD supervisor David Lowe for his patient direction and pertinent review comments. I would also like to thank the participants who responded to the questionnaire, without their support, I would not have gained an appreciation of what other software professionals believe.


Page 14 of 18

QUALCON 2004

7

BIBLIOGRAPHY

Boehm, Barry; Basili, Victor (2001) Software Defect Reduction Top 10 List. IEEE: Computer Innovative Technology for Computer Professions. January 2001, Vol: 34, No: 1, pp: 135-137 Brooks, Frederick P. Jr. (1995) The Mythical Man-Month, Essays on Software Engineering. Addison-Wesley. 1995, Anniversary Edition, ISBN: 0471154059 Crutchfield, Richard; Workman, David A (1994) Quality Guidelines = Designer Metrics. ACM: Proceedings of the Conference on TRI-Ada. November 1994, pp: 29-40 Dromey, R. Geoff (1995) A Model for Software Product Quality. IEEE: Transactions on Software Engineering. February 1995, Vol: 21, No: 2, pp: 146-162 Glass, Robert L. (2002) Facts and Fallacies of Software Engineering. Addison-Wesley. 2002, ISBN: 0-321-11742-5, Elshoff, James L.; Marcotty, Michael (1982) Improving Computer Program Readability to Aid Modification. ACM: Communications of the ACM. August 1982, Vol: 25, No: 8, pp: 512-521 Haneef, Nuzhat J. (1998) Software Documentation and Readability: A Proposed Process Improvement. ACM SIGSOFT Software Engineering Notes. May 1998, Vol: 23, No: 3, pp: 75-77 Laitinen, Kari; Mukari, Timo (1991) DNN - Disciplined Natural Naming: A Method for Systematic Name Creation in Software Development. Proceedings of the Twenty-Fifth Hawaii International Conference on System Sciences, 1991, Vol: ii, pp: 91-100 Laitinen, Kari; Taramaa, Jorma; Heikkila, Markky; Rowe, Neil C. Enhancing (1997) Maintainability of Source Programs Through Disabbreviation. Elsevier: Journal of Systems and Software. May 1997 Vol: 37, No: 2, pp: 117-128 Lieberman, Henry; Fry, Christopher (2001) Bridging the Gulf Between Code and Behavior in Programming. Available from: Accessed 18 October 2001 McConnell, Steve (2001) Who Needs Software Engineering. IEEE Software, January/Feburary 2001, Vol: 18, No: 1, pp: 5-8 Mengel, Susan A.; Yerramilli, Vinay (1999) A Case Study of the Static Analysis of the Quality of Novice Student Programs. ACM: SIGCSE Bulletin, Proceedings of the Thirteenth SIGCSE Technical Symposium on Computer Science Education. March 1999, Vol: 31, No: 1, pp:78-82


Page 15 of 18

QUALCON 2004

Nakashima, T.; Oyama, M.; Hisada, H.; Ishii, N. (1999) Analysis of Software Bug Causes and its Prevention. Elsevier: Information and Software Technology. December 1999, Vol: 41, pp: 1059-1068 Neumann, Peter G. (2002) Risks to the Public in Computers and Related Systems. ACM: SIGSOFT Software Engineering Notes. March 2002, Vol: 27, No: 2, pp: 5-19 Oman, Paul W., Cook, Curtis R. (1990a) A Taxonomy for Programming Style. ACM: Proceedings of the ACM Annual Conference on Cooperation. January 1990, pp: 244 250 Oman, Paul W.; Cook, Curtis R. (1990b) Typographic Style is More than Cosmetic. ACM: Communications of the ACM. May 1990, Vol. 33, No. 5, pp 506-520 Pearse, Troy; Oman, Paul (1995) Maintainability Measurements on Industrial Source Code Maintenance Activities. IEEE: Proceedings of the International Conference on Software Maintenance, 1995. October 1995, pp: 295-303 Rajlich, Vaclav; Wilde, Norman; Buckellew, Michelle (2001) Software Cultures and Evolution. IEEE Computer. September 2001, Vol: 34, No: 9, pp: 24-28 Rising, Linda (1989) Removing the Emphasis on Coding in a Course on Software Engineering. ACM: SIGCSE Bulletin, Proceedings of the Twentieth SIGCSE Technical Symposium on Computer Science Education. Feb-89, Vol: 21, No: 1, pp: 185-189 Slaughter, Sandra (1996) Assessing the Use and Effectiveness of Metrics in Information Systems. ACM: Proceedings of the 1996 ACM SIGCPR/SIGMIS Conference on Computer Personnel Research. April 1996, pp: 384-391 Spinellis, Diomidis (2003) Reading Writing and Code. ACM: Queue. October 2003, Vol: 1, No: 7, pp:84-89 Tenny, Ted (1988) Program Readability: Procedures Versus Comments. IEEE Transactions on Software Engineering. September 1988, Vol: 14, No: 9, pp: 1271-1279 Pearse, Troy; Oman, Paul (1995) Maintainability Measurements on Industrial Source Code Maintenance Activities. IEEE: Proceedings of the International Conference on Software Maintenance, 1995. October 1995, pp: 295-303 Vollman, Thomas E. (1993) Software Quality Assessment and Standards. IEEE Computer. June 1993, Vol: 26, No: 6, pp: 118-120 Weinberg, Gerald M. (1998) The Psychology of Computer Programming. Dorset House Publishing, New York. 1998, Silver Anniversary Edition ISBN: 0-932633-42-0


Page 16 of 18

Annex A – Identifier-Naming Style Guidelines Guideline Id

Guideline Name & Description

Example Deviating from Guideline

1

Un-named Constant i.e., a numeric value other than -1, 0 or +1, used in an expression

Radius * 3.141592

2

Multiple Underscore Characters

Apple__Count

3

Outside Underscore Character

_Apple_Count

4

Numeric Digit(s) i.e., identifier duplication differentiated only by a digit

Apple_Count_1

(for multiple identifiers an array should be defined)

Apple_Count_2

5

Naming Convention Anomaly i.e., a non-standard mixture of character case

Apple_COUNT

6

Identifier Encoding i.e., the use of Hungarian notation to attach the identifier data type to the identifier name

iApple_Count

7

Short Identifier Name i.e., an identifier name shorter than eight characters, excluding: i, j, k. l, m, n, t, x, y or z

Count

8

Long Identifier Name i.e., an identifier name longer than twenty characters

Foreign_And_Domestic_Apple_Count

9

Number of Words i.e., an identifier should consist of two, three or four words

Count

Class/Type Qualification i.e., class names and type names should be qualified to identify their nature

Fruit

10

(FruitClass and Fruit_Tree is considered more readable) 11

Abstract Words i.e., the construction of an identifier only using abstract words

Do_It

12

English Word(s) i.e., the use of ‘words’ not found in the English language

App_Cnt

13

Constant/Variable Qualification i.e., numeric range constants should be fully qualified

Minimum_Apple_Count (Apple_Count_Minimum is considered more readable)

14

Numeric Identifier Name i.e., the composition of an identifier from only numeric words and numeric values

One_Hundred

QUALCON 2004

Guideline Id

Guideline Name & Description

Example Deviating from Guideline

Ten4 15

Singular Word(s) i.e., identifier names should be composed of words in the singular

Apple_Counts

16

Duplicate Identifier Names i.e., the appearance of two identical identifier names both in scope

Apple_Count Procedure … Apple_Count

17

Similar Identifier Names i.e., the appearance of two similar identifier names both in scope

Apple_Count Procedure … Apple_Counts

18

Unused Identifier i.e., an identifier declared by never used

N/A

19

Same Words i.e., two identifiers composed of the same words but used in a different order

Apple_Count Count_Apple

20

Enumeration Identifier Definition Order i.e., enumeration constants declared in non-alphabetical order

Type Colour_Type is (Colour_Red, Colour_Blue, Colour_Green)

21

Enumeration Identifier Qualification i.e., the non-qualification of enumeration constants to identify their base type

Type Colour_Type is (Blue, Green, Red)


Page 18 of 18