Bring Your Own Coding Style

Transcription

1 Bring Your Own Coding Style Naoto Ogura, Shinsuke Matsumoto, Hideaki Hata and Shinji Kusumoto Graduate Shool of Information Siene and Tehnology, Osaka University, Japan {n-ogura, shinsuke, Graduate Shool of Information Siene, Nara Institute of Siene and Tehnology, Japan Abstrat Coding style is a representation of soure ode, whih does not affet the behavior of program exeution. The hoie of oding style is purely a matter of developer preferene. Inonsisteny of oding style not only dereased readability but also an ause frustration during programming. In this paper, we propose a novel tool, alled STYLECOORDINATOR, to solve both of the following problems, whih would appear to ontradit eah other: ensuring a onsistent oding style for all soure odes managed in a repository and ensuring the ability of developers to use their own oding styles in a loal environment. In order to validate the exeution performane, we apply the proposed tool to an atual software repository. Index Terms oding style, style feature, style inonsisteny, software repository, Git I. INTRODUCTION Coding style is a textual representation of soure ode, whih does not affet the behavior of program exeution. Examples of oding style inlude the type of indentation (i.e., tabs or spaes), the existene of a whitespae harater around arithmeti operators, and naming onventions of variables and methods. Although oding style has no effet on the program behavior itself, it does have a signifiant influene on readability and maintainability for developers [1][2]. In a pratial programming environment, a wide variety of styles must be defined in various loations of soure ode. In Elipse, over 3 detailed items of oding style onfiguration, suh as whether a spae is inserted before an open parenthesis in an if statement, are provided. The hoie of oding style is purely a matter of developer preferene [3], whih has generally evolved from his/her programming experiene. For example, the following hoies are known to vary depending on the developer: whether a whitespae is inserted after if/for keywords and method names, whether an open brae { is inserted onto a new line or the same line. The general oding style hanges aording to the evolution of the programming environment. The style limitation of 8 haraters per line originally omes from the physial limit of IBM s punh ard [4]. However, the limit is being relaxed as monitor resolution improves. Currently, Google s Java oding onvention 1 sets the limit to 1. Unifying on a ommon oding style for all soure odes is a signifiant ativity in a o-development environment [5][6]. Inonsisteny of oding style not only dereases readability, but also hinders developer onentration. A developer may 1 feel frustration by being fored to use a style that he/she does not usually use. From the perspetive of understanding software evolution, a history of style modifiations usually beomes noise in a software repository. When a developer ontributes both bug fix and style fix in a single ommit, the resulting problem is referred to as the problem of tangled ode hanges [7]. Despite the fat that a style is defined as a oding onvention for eah projet, it is impossible to fore all of developers to follow the onvention for the entire soure ode. An IDE and style formatter 2 an be used to unify oding style in a loal environment. However, ensuring a onsistent style within a projet (i.e., remote environment) is still diffiult beause default style onfigurations are different for individual tools. In this paper, we takle the following hallenges, whih would appear to ontradit eah other: Ensuring a onsistent oding style for all soure odes managed in a repository. Developers an use their own oding styles (and own tools) in a loal environment. In order to ahieve the above hallenges, we propose a novel tool, alled STYLECOORDINATOR, whih provides bidiretional oding style onversion between individual and projet-defined styles. The tool provides a style-onversion feature and is exeuted by a standard Git lient. The tool formats to a projet-defined style when a developer ommits soure odes to a repository. This behavior solves the first hallenge. The seond hallenge is solved by formatting to an individual style when a developer pulls from a repository. In addition, the tool supports automati extration of style preferene from written soure odes. This feature helps to redue the ost of tool installation. The main ontributions of this paper are: We formulated speifi ases of oding style as style features. We improved an existing extration method of style features. We developed a tool for overoming oding style frustration in a o-development software projet. The tool is still an early prototype in the sense that it only overs one of five ategories of oding styles. However, we believe that our onept may be one of a peaeful solution to holy wars [8] about oding preferenes. 2

2 II. CODING STYLE A. Classifiation of Coding Styles We define a representation of a soure ode as a oding style, whih has no impat on program behavior. The oding style an be broadly lassified as follows, The items are sorted in asending order of influene on program ompilation. Separation of tokens (e.g., spae before open parenthesis in an if statement) Indentation (e.g., spae or tab, number of indentation spaes) Name onvention (e.g., amel ase or snake ase or kebab ase) Delaration order (e.g., alphabetial order or publi method first) Sugar syntax (e.g., if-else statement or ternary operator) Most of the ommon IDEs provide ustomization of eah ategory of oding style. In this paper, we fous only on the first ategory, separation of tokens, beause this ategory inludes a greater number of detailed items as ompared to other ategories. Elipse defines 161 items for the ategory. All of the detailed items may be diffiult to ompletely desribe as oding onventions. We onsider automated style onversion for the ategory to be pratial for use in atual development. B. Style Features In this paper, we define a style feature as a set of information related to oding style. The style feature is omposed of the following three attributes. Type (e.g., spae-before-open-paren-in-if-statement) Loation (e.g., line 3) Value (e.g., presene) The above example means that a whitespae before open parenthesis in if statement in present in line 3. For the style ategory onsidered (separation of tokens), the value an only be presene or absene. The style feature exists in various loations of soure ode. Automati inferene of style onfiguration an be enabled by olleting style features from the developer s own written soure odes. C. Style Inonsisteny Spinellis et al. [9] proposed a degree of style inonsisteny () to show how a soure ode inludes inonsistenies of oding styles. Let a and b be values of a style feature (i.e., presene and absene), and let i be an ID of a style feature. Moreover, let a i be the number of ourrenes of a for style feature i. The degree of style inonsisteny of style feature i, denoted by i, is defined as i = min(a i, b i ) a i + b i Let n be the total number of types of style feature (1 i n). Then, the overall degree of style inonsisteny for all soure odes, denoted by all, is defined as n i all = min(a i, b i ) n i a i + b i developer X int fat( int n ) { if ( n==1 ) return 1; return n*fat( n-1 ); 3. extrat style projet.xml style my.xml int fat( int n ) { if ( n<=1 ) return 1; return n*fat( n-1 ); 1. stage & ommit 2. referred 5. referred 6. hekout proposed tool formatted style rev. n rev. n+1 Git repository int fat(int n) { if (n == 1) return 1; return n * fat(n - 1); 4. modify & ommit int fat(int n){ if (n <= 1) return 1; return n * fat(n - 1); modified soure ode file style definition file Fig. 1: Overview of the STYLECOORDINATOR i takes a value from to.5. A larger value indiates that a higher degree of style inonsisteny exists. For example, when a style type spae-before-open-brae-in-if-statement ours in ten instanes, and only two of the ten instanes inlude a spae, and i takes a value of.2 (2/1). Here, i beomes maximum (.5) when the number of ourrenes of presene and absene are exatly the same. A. Overview III. STYLECOORDINATOR We propose a tool, STYLECOORDINATOR, that solves the following seemingly ontraditory hallenges: ensuring a onsistent oding style for all soure odes managed in a repository and ensuring that developers an use their own oding styles in a loal environment. Figure 1 shows an overview of the proessing flow of the tool. The tool is working on Git as software onfiguration management (SCM). Using a standard Git feature, alled Git attribute, the tool exeuted on both stage and hekout operations in a loal environment. Here, we introdue three use ases of using the tool. Stage and ommit: Developer X uses our tool for the first time. When X stages and ommits his/her written soure ode (step 1), the tool refers a style onfiguration file, whih is provided as a ommon onvention of the projet (step 2). The soure ode is formatted based on the onfiguration and is stored to a repository. In this ase, X s unusual oding style is formatted to the popular oding style. Thus, the first hallenge, unifying the oding style in a repository, is solved. Extrat a style onfiguration file: The tool helps to make a style onfiguration file by extrating style features from their written soure ode (step 3). This extration is based on the onept of. In other words, a major

3 oding style within the developer s ode is assumed to be his/her preferred style. The onrete method of the style extration is desribed in the next Setion. Chekout: Another developer modifies and ommits the soure ode (step 4). When X hekouts from a repository, the tool refers the extrated onfiguration file (step 5) and transforms the soure ode to his/her own style (step 6). Thus, the seond hallenge is solved. soure ode publi void run(int n) { if (n > ) { Step1: Searh style andidates publi void run(int n) { if (n > ) { Step2: Token analysis & syntax analysis syntax tree B. Style Feature Extration 1) Problem of Existing Tehnique: In a o-development environment, the key to dealing with individual oding styles is detailed and aurate style feature extration. Spinellis published a metris measurement tool, alled qmetris 3, in a study on s [9]. The tool supports style feature extration as one of many funtions of metris measurement. However, the tool annot follow syntati information, beause the extration is based only on token analysis. Therefore, extratable types of style feature are oarse and inomplete. Here, we illustrate the problem using a speifi example. The blak triangle ) represents a style feature that annot be aurately extrated by qmetris. if a1 n > ) return b2 ; for a1 int i = b1 ; i < n b1 ; i ++ ) { dosomething a2 i ) b2 ; The tool does not distinguish between ontrol flow keywords (e.g., if, for, and while). As suh, both a 1 s illustrated in the example are regarded have the same oding style as spae-before-open-paren-in-ontrol-statement. On the other hand, a spae before an open parenthesis in method invoation (a 2 ) annot be extrated. Every type of spae before a semiolon (b 1 and b 2 ) is undistinguished beause the tool also ignores the ontext of the program statement. In addition, there are many ases () in whih a style feature is negleted. 2) Proposed Style Extration Tehnique: In order to improve the existing extration method, we propose a method by whih to extrat fine-grained style features based on syntax analysis. Figure 2 illustrates an overview of the proessing flow. The input of the method is a set of Java soure odes, and the output is a set of style features. Step1: Searh spae haraters that are andidates of a style feature. The tool filters some spaes that annot be syntatially omitted (e.g., publi void, and int i). Step2: Generate an abstrat syntax tree by onduting token analysis and syntax analysis. Step3: Extrat all style features from the andidates by heking the syntax tree. Based on the above disussion, we implemented an improved extration tool of style feature 4. The tool is a sub n-ogura/216 format-feature-extrator orresponds to Step3: Resolve style type from syntax tree & make a list of style features type: spae-before-open-parenin-if-statement loation: 76 value: absene style features Fig. 2: Proessing flow of the proposed style extration <profile kind="codeformtterprofile"> type="insert-spae-before-open-parenin-if-statement" value="insert"/> type="insert-spae-before-open-parenin-for-statement" value="insert"/> type="insert-spae-before-open-parenin-method-invoation" value="do not insert"/> </profile> Fig. 3: Example of a style onfiguration file omponent of STYLECOORDINATOR. Although the tool urrently supports Java, the basi onept of extration an be applied to many programming languages. C. Style Configuration A file for style onfiguration is shown in Figure 3. The file is written in XML. Eah individual setting tag orresponds to a style feature. A spae is inserted or omitted based on the value attribute for various loations orresponding to a style type speified in the type attribute. This file is ompatible with a style onfiguration file used on Elipse. Therefore, the onfiguration file of STYLECOORDINATOR an be easily ustomized using Elipse s style onfiguration GUI. D. Implementation and Usage STYLECOORDINATOR is written in Java and published on our website 5. The tool provides style transformation and style extration. In order to ooperate with Git, we use a Git standard feature, alled gitattributes, whih enables ustomization 5 n-ogura/218 style-oordinator

4 of the pre-proessor of the stage and hekout operations. In general, the feature is used to enfore the orret line endings poliy. Here, we desribe the tool usage on a speifi repository. First, a ustom filter sformat must be defined in a gitattributes file. Pre-proessing for all java files is enabled by this definition. $ eho '*.java filter=sformat' >> \.git/info/gitattributes Next, we need to define a preferred style file in a loal environment. The definition is provided by automati style extration or Elipse GUI. In this introdution, the preferred style is designated my.xml and the projet-defined style is designated projet.xml, whih should be managed in a Git repository beause the file is shared in a projet. Finally, we define the atual pre-proessing behavior for the defined filter. The proposed tool is speified to exeute at stage and hekout operations (i.e., filter.format.smudge and filter.format.lean). $ git onfig filter.sformat.smudge \ styleoordinator my.xml $ git onfig filter.sformat.lean \ styleoordinator projet.xml IV. EVALUATION A. Style Inonsisteny in Atual Projets 1) Purpose and Method: The purpose of the study is to survey style inonsisteny during the evolution of Java projets, whereas Spinellis s study foused on the evolution of the C language. We alulate hanges of all from a Java repository. The proposed tool is used for the alulation. The alulation is onduted for all soure odes within the master and trunk branhes. The subjet projets are JUnit4 and log4j. An overview of the projets is shown in Table I. The development histories for over 15 years are stored in GitHub. 2) Result and Disussion: Figure 4 shows the hanges of all and lines of ode (). From Figure 4(a), JUnit4 has inreasing. Although all was higher at the beginning of the projet, the value has been dereasing over time. In partiular, all dereased drastially in 212 by applying a style formatter for all soure odes. A new oding onvention was disussed at the time 6. Even though the onvention was introdued, all has been inreasing slightly with inreasing. From Figure 4(b), log4j has a similar tendeny as JUnit4 between 2 and 27 when the projet was in early development. After that, varies around.3. In 27, 21 and 212, and were drastially hanged beause the projet performed branh merging, feature addition, and feature deletion (a) JUnit e+4.4 3e+4 2e+4.2 1e (b) log4j Fig. 4: Change of all and for eah projet 215 1e+6 5e+5 In summary, style inonsisteny tends to our in early development and to be affeted by hanging. With the software evolution, the inonsisteny annot be solved even if a style formatter is applied. Some developers may get frustrated by the inonsisteny. We onlude that a tool to support a onsistent oding style may be helpful in a odevelopment environment. B. Performane Evaluation 1) Purpose and Method: Using the proposed tool, the exeution performane of Git operation is expeted to derease beause of token and syntax analysis. In this experiment, we onfirm whether the performane derease is pratial. All stage and ommit operations that were exeuted in atual software are reprodued. We measured and ompared the exeution times for every operation with and without the proposed tool. The subjet projet is JUnit4, whih inludes 2,115 revisions during years 2 through ) Result: Figure 5(a) shows the performanes with and without the proposed tool. The distribution of the exeution time is shown as a box plot. The y-axis shows the exeution time in log sale. Most original ommits were aomplished within a single seond. In ontrast, using the proposed tool, the exeution time was inreased approximately 17-fold. However, we found that 75% of ommits were aomplished within 2.5 seonds. In the worst ase, the exeution time inreased from 1.1 seonds to seonds, whih was the longest time with and without the proposed tool. In this ase, 35 files were ommitted at the same time in order to apply a new oding style in 212. The drasti style hange is also shown in Figure 4(a). Figure 5(b) illustrates the relationship between the rate of performane redution and the total number of java files. The x-axis indiates the rate of performane redution obtained using our tool, and the y-axis indiates the number of files. Note that a few ases, in whih the number of java files exeeds 1, are omitted. We an onfirm that the performane is dereased as the number of java files inreases. TABLE I: Summary of subjet projets projet name years # revisions # developers JUnit4 15 2, ,722 log4j 15 3, ,78

5 se w/o tool w/ tool (a) Comparison of exeution time of ommit operation #files performane redution rate (b) Relationship between the performane redution rate of the ommit operation and the number of java files Fig. 5: Results of the performane evaluation experiment 3) Disussion: In summary, the most ommits were aomplished within 5 seonds when the proposed tool was used as a pre-proessor. In a pratial situation, the perentage of the ommit time during development is extremely small beause the ommit is exeuted after a ertain task is ompleted. We believe that the performane derease by the proposed tool may be aeptable. We also found that the exeution performane dereases by ommitting multiple files simultaneously. The reason for this is that the onstrution of the syntax tree requires more time as the number of total program statements inreases. In reent software development, it is reommended that all ommits should be kept smaller [1]. This pratie is known to be key to ontinuous integration. Therefore, we believe that the influene of the performane redution may be smaller with the spread of agile praties. V. RELATED WORK A number of software projets have published oding guidelines 7,8,9 that inlude some speifi rules of oding style. Of ourse, there are many differenes between these styles. This means that oding style is not only a preferene of the projet but is also a non-trivial problem that annot be negleted in a o-development environment. Some researhers have onduted a survey of oding styles in pratial environments. Spinellis et al. [9] have studied longterm hanges in style inonsisteny in Unix for 43 years. They onluded that the projet suessfully ahieved a onsensus of oding style beause the inonsisteny dereased year by year. Bahelli and Bird [11] reported that ode improvements, suh as heking that soure ode follows ode onvention, are important motivation for ode review. Li et al. [12] studied students opinions on oding styles in programming ourses. From these studies, it is diffiult to follow the oding onvention for all developers. 7 US.ISO8859-1/books/fdp-primer/ Various style formatters have been published 1 and many popular IDEs also inlude these formatters by default. Moreover, in the aademi field, a number of style formatters have been proposed [3][13][14][15]. These tools have some features in ommon with the proposed tool. However, the tools an only work in a stand-alone or loal environment. The proposed tool an ensure onsistent style in both loal and remote environments by exeution with Git operation. VI. CONCLUON In this paper, we proposed a tool for use in development environments to easily maintain style onsisteny. The tool inludes an improved algorithm of style extration. We onduted an experiment to evaluate performane of the tool. From the evaluation, the performane derease by the tool may be aeptable. In the future, we intend to extend to over other ategories of oding styles suh as indentation and name onvention. To deal with these ategories, we need to onsider further style extration and inonsisteny riteria. In order to onfirm the usefulness of the tool, we are going to ondut qualitative evaluation with industrial pratitioners. ACKNOWLEDGMENT This study was supported by JSPS/MEXT KAKENHI Grant Numbers JP25223 and JP REFERENCES [1] P. W. Oman and C. R. Cook. A taxonomy for programming style. In Pro. Annual Conf. Cooperation, pages , 199. [2] A. Bosu, M. Greiler, and C. Bird. Charateristis of useful ode reviews: An empirial study at mirosoft. In Pro. Working Conf. Mining Software Repositories, pages , 215. [3] T. Parr and J. Vinju. Towards a universal ode formatter through mahine learning. In Pro. Int l Conf. Software Language Engineering, pages , 216. [4] IBM Arhives: 1928, January 218. [5] M. Allamanis, E. T. Barr, C. Bird, and C. Sutton. Learning natural oding onventions. In Pro. Int l Symp. Foundations of Software Engineering, pages , 214. [6] C. Boogerd and L. Moonen. Assessing the value of oding standards: An empirial study. In Pro. Int l Conf. Software Maintenane, pages , 28. [7] K. Herzig and A. Zeller. The impat of tangled ode hanges. In Pro. Working Conf. Mining Software Repositories, pages , 213. [8] D. Cohen. On holy wars and a plea for peae. Computer, 14(1):48 54, [9] D. Spinellis, P. Louridas, and M. Kehagia. The evolution of programming praties: A study of the unix operating system In Pro. Int l Conf. Software Engineering, pages , 216. [1] M. Meyer. Continuous integration and its tools. IEEE Software, 31(3):14 16, 214. [11] A. Bahelli and C. Bird. Expetations, outomes, and hallenges of modern ode review. In Pro. Int l Conf. Software Engineering, pages , 213. [12] X. Li and C. Prasad. Effetively teahing oding standards in programming. In Pro. Conf. Information Tehnology Eduation, pages , 25. [13] D. C. Oppen. Prettyprinting. ACM Trans. Programming Languages and Systems, 2(4): , 198. [14] L. F. Rubin. Syntax-direted pretty printing - a first step towards a syntax-direted editor. IEEE Trans. Software Engineering, 9(2), [15] R. D. Cameron. An abstrat pretty printer. IEEE Software, 5(6):61 67,