Kurs, Jan

Lungu, Mircea

English

ARTS repository - University of Groningen

   University of GroningenOn Planning an Evaluation of the Impact of Identifier Names on the Readability andMaintainability of ProgramsLungu, Mircea; Kurs, JanPublished in:Proceedings of the 2nd Workshop on User evaluations for Software Engineering Researchers (USER)IMPORTANT NOTE: You are advised to consult the publisher's version (publisher's PDF) if you wish to cite fromit. Please check the document version below.Document VersionPublisher's PDF, also known as Version of recordPublication date:2013Link to publication in University of Groningen/UMCG research databaseCitation for published version (APA):Lungu, M., & Kurs, J. (2013). On Planning an Evaluation of the Impact of Identifier Names on theReadability and Maintainability of Programs. In Proceedings of the 2nd Workshop on User evaluations forSoftware Engineering Researchers (USER) (pp. 13 - 15)CopyrightOther than for strictly personal use, it is not permitted to download or to forward/distribute the text or part of it without the consent of theauthor(s) and/or copyright holder(s), unless the work is under an open content license (like Creative Commons).The publication may also be distributed here under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license.More information can be found on the University of Groningen website: https://www.rug.nl/library/open-access/self-archiving-pure/taverne-amendment.Take-down policyIf you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediatelyand investigate your claim.Downloaded from the University of Groningen/UMCG research database (Pure): http://www.rug.nl/research/portal. For technical reasons thenumber of authors shown on this cover page is limited to 10 maximum.On Planning an Evaluation of the Impact ofIdentifier Names on the Readability andMaintainability of ProgramsMircea Lungu, Jan Kurš{lungu,kurs}@iam.unibe.chSoftware Composition GroupUniversity of BernSwitzerlandAbstract—One of the long running debates between program-mers is whether camelCaseIdentifiers are better thanunderscore_identifiers. This is ultimately a matter ofprogramming language culture and personal taste, and to ourbest knowledge none of the camps has won the argument yet. Itis our intuition that a solution exists which is superior to both theprevious ones from the point of view of usability: the solutionwe name sentence case identifiers allows phrases as nams forprogram entities such as classes or methods. In this paper wepropose a study in which to evaluate the impact of sentence caseidentifiers in practice.Index Terms—user evaluation, programming languages, em-pirical software engineering.I. INTRODUCTIONThere are two ways of conveying domain information ina program: through the names of the program entities andthrough comments in the source code. Since the commentstend to become out of sync, it follows that the naming ofentities is a critical factor when it comes to the readabilityand future maintainability of a piece of software.In most of the currently popular programming languages themethod names and the class names are the ones conveying thissemantic information [3] and different programming languagesimpose different constraints on these names in order to makethe parsing of these programs easier. One almost universalsuch constraint is that names of programming entities mustexclude spaces.Let us consider Smalltalk, a classical OO programminglanguage with a simple syntax and powerful semantics. Tra-ditionally, in the language, a unary message send (calling amethod without parameters on an object) has the followingsyntax (1):anObject aMessage.where both the object that is the receiver of the messageand the message are identifiers, that is sequences of alphanu-meric characters excluding spaces. For complex identifiersprogrammers use the camelcase convention. In fact, Smalltalkprogrammers are notorious for using long identifier names andcode snippets like the following are not uncommon (2):HierarchicalGraphimportFromDownlodedStackOverflowData.The length of the identifier makes it awkward to read1.We say that by allowing spaces in the identifier names weenable sentence case or phrase case – a way of writing iden-tifiers that look like natural language phrases. We hypothesizethat this would increase the readability and maintainability ofsource code.To allow sentence case in Smalltalk, we slightly modify thegrammar of the language by introducing a separator characterin all the places in the grammar where two identifiers couldbe adjacent. With such a syntax change we can allow spacesin the name of the identifiers, or what we call sentence caseidentifiers.Let us modify the syntax for the message send (1) andintroduce a required comma between the object and themessage that it receives (1’):anObject , aMessage.This will allow the example (2) to become:Hierarchical Graph,import from downloaded StackOverflow data.We find this second example to be more elegant. It has theadded benefit of the editor being able to check the spelling ofindividual words.II. RESEARCH QUESTIONS AND USER EVALUATIONNot only that we believe that example (2) is more elegant,but we believe that a language which would be using sentencecase would would have a series of benefits: it would encourageprogrammers to think more about their identifiers (H1), willlook friendlier to newcomers (H2), and will ultimately lead toan increased readability and maintainability of programs (H3).These are our intuitions, but they would need to be verified.1And sometimes results in a useless comment being added to the methodsuch as "create example from the downloaded StackOverflow data".However, the approach is not without drawbacks: the ex-tra “ink” required for adding commas everywhere betweenpossible colliding identifiers might be tiring (H4) and it willbe received with suspicion by old Smalltalkers (H5). Also,the sentence case identifiers idea might not scale to otherlanguages with other grammars.We are working on implementing the necessary languagemodifications which would allow us to run user evaluationsand learn whether our intuitions are correct. Particularly weplan to answer the hypotheses (H1-H5).Since most of these hypotheses can be validated throughuser evaluations, we plan to have a working prototype runningby the time the USER workshop will be conducted and tobe able to discuss experiment designs with the workshopparticipants and, if the context is favorable, involve the otherparticipants in small experiments.If evidence supports our intuition, this knowledge would beuseful and guidance for the designers of the future languagesand IDEs. Indeed, the solution could be designed either at theprogramming language level, or at the IDE level. One couldalso imagine a compatibility layer on top of existing code thatwould unCamelcase-ise it and then camelcase it back.III. RELATED WORKA very good introduction and discussion on naming inprogramming is delivered by Liblit et al. [3] who observethat the public identifiers have longer and more informativenames, and that the grammar of natural languages influencesthe choice of identifier names.Binkley et al. conducted a study in which they evaluated theimpact of camel case and underscore conventions on sourcecode readability. They found differences between experts andbeginners [1].Sharif and Maletic performed an empirical study to comparethe same two identifier styles using eye tracking software.They found that subjects recognize identifiers with underscorestyle more easily [4].Applescript is a popular scripting language which has acertain natural language feel and philosophy [2]. As far aswe are aware there are no user studies published about itsdesign.IV. CONCLUSIONWe have proposed an empirical evaluation of our proposedmodification to a classical programming language. This modi-fication consists in enabling phrases instead of identifiers. Webelieve this would make a language easier to understand forbeginners, and would encourage the experienced developersto higher quality code. However, since these are only assump-tions, we plan to design a series of user evaluations to learnwhether our hypotheses will hold. As far as we are aware, thisis quite a novel approach to language design but we believe apowerful one.APPENDIX: A SLIGHTLY LARGER EXAMPLEIn order to illustrate our idea with a longer example, wemust introduce a few other details of the Smalltalk syntax.When a message sent to an object takes multiple parameters,the parameters are interleaved between the keywords of themessage as in (3)anObject fooWith: aString andBarWith: aNumberOne added benefit of our approach over traditional Smalltalksyntax, is the situation in which multiple messages are chained.The snippet (4):anObject foo barsends foo to anObject and to the resulting object it sends bar.When the messages take arguments we need to surround all ofthem with parentheses, so there is no ambiguity whether wehave a single message with three parameters or three chainedmessages with one parameter, as in the example (5):((( anObject foo :1) bar : ’two’) baz: #three ) quxIn our implementation the previous can simply be written as:anObject , foo: 1, bar : ’two’, baz: #three , qux.With this rule, consider now the following Smalltalk code:| shortPaper |shortPaper ←ShortPaper createNewNamed: ’Planning an Evaluation’shortPaper authorsaddWithFirstName: ’Mircea’ andLastName: ’Lungu’;addWithFirstName: ’Jan’ andLastName: ’Kurs’;shortPaperaddAffiliation: ’University of Bern’;addAbstract: (FileInputStream createFromFile: ’abstract.txt’)getStreamContents.(((Net getProtocol: #HTTP) createRequest: #Post) for: shortPaper)send.The same example written with sentence case identifiers wouldlook like this:| short paper |short paper←Short Paper, create new named: ’Planning an Evaluation’short paper, authors,add with first name: ’Mircea’ and last name: ’Lungu’;add with first name: ’Jan’ and last name: ’Kurs’.short paper,add affiliation: ’University of Bern’;add abstract: (File Input Stream, create from file: ’abtract.txt’) getstream contents.Net, get protocol: #HTTP, create request: #Post, for: short paper, send.REFERENCES[1] D. Binkley, M. Davis, D. Lawrie, and C. Morrell. To camelcase orunderscore. In Program Comprehension, 2009. ICPC ’09. IEEE 17thInternational Conference on, pages 158 –167, may 2009.[2] W. R. Cook. Applescript. In Proceedings of the third ACM SIGPLANconference on History of programming languages, HOPL III, pages 1–1–1–21, New York, NY, USA, 2007. ACM.[3] B. Liblit, A. Begel, and E. Sweetser. Cognitive perspectives on the roleof naming in computer programs. In Proceedings of the 18th AnnualPsychology of Programming Workshop. Psychology of ProgrammingInterest Group, September 2006.[4] B. Sharif and J. I. Maletic. An eye tracking study on camelcaseand under_score identifier styles. International Conference on ProgramComprehension, 0:196–205, 2010.

On Planning an Evaluation of the Impact of Identifier Names on the Readability and Maintainability of Programs

https://pure.rug.nl/ws/files/33883653/Lung13a_Planning.pdf

On Planning an Evaluation of the Impact of Identifier Names on the Readability and Maintainability of Programs

Abstract

Similar works

Full text

Available Versions

ARTS repository - University of Groningen