How is IF Statement Fixed Through Code Review? A Case Study of Qt Project

全文

(1)奈良先端科学技術⼤学院⼤学学術リポジトリ Nara Institute of Science and Technology Academic Repository: naistar. Title. Author(s). How is IF Statement Fixed Through Code Review? A Case Study of Qt Project Ueda, Yuki; Ihara, Akinori; Hirao, Toshiki; Ishio, Takashi; Matsumoto, Kenichi ISSREW 2017 : 2017 IEEE International Symposium on Software. Citation. Reliability Engineering Workshops, 23-26 Oct. 2017, Toulouse, France. Issue Date. 2017. Resource Version. author © 2017 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media,. Rights. including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.. DOI. 10.1109/ISSREW.2017.32. URL. http://hdl.handle.net/10061/12721.

(2) How is IF Statement Fixed Through Code Review? -A case study of Qt project∗. Yuki Ueda∗ , Akinori Ihara∗ , Toshiki Hirao ∗ , Takashi Ishio∗ , and Kenichi Matsumoto∗ Graduate School of Information Science, Nara Institute of Science and Technology (NAIST), Japan Email: {ueda.yuki.un7, akinori-i, hirao.toshiki.ho7, ishio, matumoto}@is.naist.jp. Abstract—Peer code review is key work to ensure the absence of software defects. To improve the review process, many code review tools provide OSS projects CI tests that automatically verify the code quality issues such as a code convention issue and a syntax issue. However, it does not cover every issues such as project policy issue and a code readability issue. In this study, our main goal is to understand how a code owner fixes conditional statement issues based on reviewers feedback. As a first step to achieve this goal, we conduct an empirical study to understand if statement changes after reviewing. Using 69,325 review requests in the Qt project, we analyze changes of the if conditional statement (1) that are requested to review, and (2) that are implemented after reviewing. As a result, we find that most common symbolic changes are “(” and “)” (35%) , “!” operator (20%) and “->” operator (12%). Also, “!” operator is frequently replaced with “(” and “)”.. Fig. 1. The overview of the code review processes in Gerrit Code Review. I. I NTRODUCTION Peer code review, a manual inspection of code changes by developers who do not create them, is a well-established practice to ensure the absence of software defects. Nowaday, many open source software (OSS) and commercial projects have adapted the peer code review. While code review plays an important work in software development processes, it is expensive and time consuming [1]. For example, Alberts [2] describes how code review spends around 50% of the software development resources. One of the reasons is because patch authors spend much time to revising their own patches due to various issues (e.g., technical, feature, scope and process issues) [1]. What cases patch authors to fix their patches several times? Pan et al. [3] and Martinez et al. [4] conducted an empirical study to understand what code changes a patch author commit. They found that if statement change is the most frequent than any other changes. Also, Tan et al. [5] found that binary operators in conditional expression are more frequent changes in a programming contest. Why do developers often change if statement? In our best knowledge, little is known how the code owner fixes if statement. if statement changes would include various issues such as bug fix and reliability. In this study, our main goal is to understand how patch author fixes conditional statement issues based on reviewers feedback. As a first step to achieve this goal, we conduct an empirical study to analyze if statement changes after reviewing because the conditional statement issues are likely to be changed more frequently than any other ones [3]. As a case study using 69,325 patches in the Qt project, we analyze. the changes of the conditional statements (1) that are requested to review (Section IV), and (2) that are implemented after the review completion (Section V). The contribution of this study is to find out frequent patterns to fix if statement through code review. We conjecture that it may help to design an issue detection approach. This paper is structured as follows. Section II describes the background of our study. Section III introduce our target if statement changes. Section IV describes an empirical study to analyze the changes in code review requests, and Section V describes to analyze the changes after reviewing. Section VI describes the validity of our empirical study. Section VII introduce the related works. Finally, section VIII concludes our study and discuss future works. II. BACK G ROUND Nowadays, we have various dedicated tools for managing the peer code review processes. For example, Gerrit 1 and ReviewBoard 2 are commonly used by OSS practitioners to receive the lightweight reviews. Technically, the code review tools are used for patch submission trigger, an automatic test and manual reviewing to decide whether or not a patch should be integrated into a version control system. For automatic test, OSS projects often use CI (Continuous Integration) tests that automatically verify the fundamental 1 Gerrit. Code Review: https://code.google.com/p/gerrit/ https://www.reviewboard.org/. 2 ReviewBoard:.

(3) flaws by such as Jenkins 3 , Travis CI 4 . However, it is not able to cover high level (e.g., requirement) issues such as performance and security issues [6]. To detect these issues, reviewers may need to conduct manual review with their eyes. Fig. 1 shows an overview of the code review process in Gerrit Code Review which our target Qt project is using as a code review management tool. 1. A patch author submit a patch to Gerrit Code Review. We define the submitted patch is P atch1 . 2. The reviewer(s) evaluate the P atch1 , and provide feedback to the patch author. If the P atch1 has any issues, the reviewer(s) require to revise the patch. 3. The patch author then revises the P atch1 , then submit the revised patch as a P atch2 . If the patch is revised n times, we define the patch as P atchn . 4. Once the patch author complete to address concerns of reviewers, the patch will be integrated into the repository. Raymond et al. [7] mentioned that code review is able to detect crucial issues a large-scale code before releasing. Indeed, the validity of code review has been demonstrated by many prior studies [8], [9], [10], [11], [12]. The prior studies show the relationship of software defects after release, antipatterns in software design and security vulnerability issues. While code review is effective to improve the quality of software artifacts, it spend a large amount of time and request many human resources [2]. Indeed, Rigby et al. [13] found that six large-scale OSS projects spend approximately 1 month for code review. There are mainly two reasons why code review spends a large amount of time and human resources. The first factor is a process to identify the appropriate reviewer(s) before the code review starts. Previous research proposes a method of selecting an appropriate reviewer based on past reviewer’s experience [14], [15], [16], [17], [18]. The second factor is the process of reviewing source codes. The code changes suggested by developers has some problems and need to be fixed multiple times [1]. Sometimes, when reviewers disagree with one another, the review time is likely to be longer [19]. Most published code review studies focused on review process or reviewers communication. In this paper, we focused source code changes, especially if changes, to reveal why submitted code were changed. We believe if statement causes many source code changes in software development [3], [4]. Especially, Tan et al. [5] discussed logical operators in conditional expression are frequently fixed in programming contests. We believe that if statement changes are one of the most difficult works. However, how if statement was not clear in previous studies. In this paper, we conduct two analyses. The first one is to analyze what kinds of symbols in P atch1 are likely to be fixed in a code review request. The second one is to analyze what kinds of symbol changes are likely to be fixed after reviewing. In second analysis, we investigate changes between P atch1 3 Jenkins: 4 Travis. https://jenkins.io/index.html CI: https://travis-ci.org/. Listing 1. IF-CC pattern Example. − i f ( g e t V i e w ( ) . c o u n t S e l e c t e d ( ) == 0 ) { + i f ( g e t V i e w ( ) . c o u n t S e l e c t e d ( ) <= 1 ) {. Listing 2. Example 1. − i f ( n >= 1 && p a t h . a t ( 0 ) == Q L a t i n 1 C h a r ( ’/ ’)) + i f ( n == 0 ) + return f a l s e ; + c o n s t QChar a t 0 = p a t h . a t ( 0 ) ; + i f ( a t 0 == Q L a t i n 1 C h a r ( ’ / ’ ) ) return true ;. and P atchn in Fig. 1. The second one is to analyze what kinds of symbol changes between P atch1 and P atchn after reviewing. III. C ONDITIONAL S TATEMENT IN C ODE R EVIEW IF-CC pattern is changing the condition expression of an if condition like Listing 1. Pan et al. [3] found that conditional statements are most likely to be fixed than another syntax issues and the common pattern of conditional statement that are changed by developers (defined as IF-CC pattern) In the Listing 1, although the IF-CC pattern is able to detect the condition change, it does not detect what string developer change in if statement (e.g., the change from “==” operator to “<=” operator). we focus how the conditional statements are changed in code reviews. To investigate the possible patterns of conditional statements, we conduct the empirical study on the Qt project. The Qt project is a cross-platform application framework using C++ language that is supported by the Digia corporation 5 . In our study, we target 69,325 review requests in Qt project. We sample 380 patches from the original review dataset (a sample selected to obtain proportion estimates that are within 5% bounds of the proportion with 95% confidential level). Listings 2 through 4 show the example patterns that we manually extracted. Listings 2 is an example devide if statement that using “&” symbol 6 . Listings 3 is an example remove "(", ")" with De Morgan’s laws7 . Listings 4 is an example replace “(” and “)” to function 8 Listings 2 through 4 describe symbol changes, In Listings 2, “&” operator disappear. In Listings 3, “&” operator symbol is replaced with “|” operator symbol, and “!” operator increase. In Listings 4, “!=” operator and “==” operator are replaced with function. Then, “(” and “)” arise. 5 http://qt.digia.com/ 6 https://codereview.qt-project.org/#/c/16570/1..2/src/lib/tools/fileinfo.cpp 7 https://codereview.qt-project.org/#/c/53881/1..3/src/libs/utils/ consoleprocess.cpp 8 https://codereview.qt-project.org/#/c/6041/1..6/src/plugins/geoservices/ nokia/places/qplacesuppliersrepository.cpp.

(4) TABLE I S YMBOL LIST.. Listing 3. Example 2. − i f ( ! ( nonEmpty && v a l u e . i s E m p t y ( ) ) ) + i f ( ! nonEmpty | | ! v a l u e . i s E m p t y ( ) ). Listing 4. Example 3. − i f ( t a r g e t . i c o n ( ) == Q P l a c e I c o n ( ) && s r c . i c o n ( ) != QPlaceIcon ( ) ) + i f ( t a r g e t . i c o n ( ) . i s E m p t y ( ) && ! s r c . icon ( ) . isEmpty ( ) ). We conduct two quantitative analysis on Qt project. In our first analysis, we analyze what kinds of code changes of conditional statements are added in a first submitted patch. In our second analysis, we analyze what kinds of code changes of conditional statements are fixed after reviewing.. symbols = == != ! & | ( ) -> + * / % < > <= >=. purpose assignment compare same or not compare not same or same switch logical result and condition or condition surround condition or call function surround condition or call function call member from pointer plus operator minus operator multiple operator devide operator ramaind operator compare(greater than) compare(less than) compare(greater than or equal) 比較 (less than or equal). example if((a = b)) if(a == b) if(a != b) if(!a) if(a & b) if(a | b) if((a | b) & c()) if((a | b) & c()) if(a->b()) if((a + b) == 0) if((a - b) == 0) if((a * b) == 0) if((a / b) == 0) if((a % b) == 0) if(a < b) if(a > b) if(a <= b) if(a >= b). IV. A NALYSIS 1: S OURCE C ODE C HANGES IN R EVIEW R EQUEST A. Approach For analysis 1, this study analyze if statement changes included in the diff file which is generated by the review management system for reviewing. Indeed, we would like to analyze the changes based on the diff file and the original source code to identify a spot with if statement. However, it takes time to collect the original source code. When we use only diff file to analyze if statement changes, there is one limitation which is not able to get all if changed contents across multiple lines. However, we believe that problem will not affect to our results since the number of if statement changes across multiple lines is 425 patches of our target 69,325 patches (0.006%). For this analysis, we identify the number of each symbols in the condition of if statement changes in P atch1 by syntax analysis. Then, we use ANTLR 9 for parsing syntax and count changed symbols for each changed block. Fig.2 described overview to get symbol changes. Table I shows common symbol, the description, and example in conditional expression. To analyze frequent of changed symbols in the same change, we use closed frequent itemset mining which is one of the well-known and popular data mining methods. The frequent itemset mining is to identify a frequent item sets that is both closed and its support is greater than the any other item sets. For frequent itemset mining, we use arules package of R. Since the frequent itemset mining suggest much item sets, we target item sets with less than 7 items and the support values are 0.001 or more to filter out some item sets. When we find the item sets have inclusion relation (e.g., {“(”} and {“(”, “)”}) with same support values, the set with fewer items will be filtered out. 9 http://www.antlr.org/. Fig. 2. Approach to extract changed symbols in if statement from diff file.. B. Result In our target 69,325 review requests, we found that there were 6,956 requests (10%) including the change of if statement. Fig.3 shows the frequent of symbols changed in if statements of the submitted patch. And, the Table II shows the top 50 item sets with higher support value of 477 item sets analyzed by frequent itemset mining. For example, id3 in table II shows “(” ∧ “)” that means “(” and “)” was changed in the same time of if statement changes..

(5) Listing 6. Example include “->”. 3000. 3500. + i f ( e d i t o r −> f i l e ( )−>h a s H i g h l i g h t W a r n i n g () ) return ;. 2000 1500. execution like Listing 5 or to use the output of a function like Listing 712 .. 1000. frequency. 2500. Listing 7. Example include “!”. + i f ( ! i s C o m p o n e n t C o m p l e t e ( ) | | ! d−>model | | ! d−>model−>i s V a l i d ( ) ) return ;. 500. V. A NALYSIS 2: S OURCE C ODE C HANGES AFTER R EVIEWING. > <= >=. <. / %. −. *. +. ) −>. |. (. !. &. !=. = ==. 0. A. Approach. Fig. 3. Symbol change frequency with if statement changes.. Listing 5. Example include “(” and “(”. + +. i f ( ! Q F i l e I n f o ( systemRoot ( ) + ” / epoc32 / r e l e a s e / udeb / e p o c . e x e ” ) . e x i s t s ( ) ) return f a l s e ;. Observation 1: Parentheses(e.g., “(” and “)”) is the most frequent changed symbol with “if” statement changes. Fig. 3 shows that parentheses are likely to be fixed with if statement. Also, Table II shows 55% of the “if” statement changes including “(” and “)” changes (id1). This target parentheses don’t include begin or end parenthesis for if statement. Although parentheses are often used for define priority in statement, we interestingly found that Qt project often uses parentheses to call a function in the statement like Listing 5 10 . Observation 2: “Arrow” operator and “not” symbol are likely to be added with parentheses frequency. Fig. 3 shows that “Arrow” and “not” are likely to be fixed with if statement. In Table II, 55% of if statement changes is with the adding parentheses. The 44.7% of them (24.6% of if statement changes) were changed with the adding the arrow operator (id12 to id19) since the arrow operator often call a function like Listing 6 11 . Also, 34.7% of them (19.1% of if statement changes) were changed with the adding the not “!” operator (id8 to id10) since the not operator is often used to detect the fail of function 10 https://codereview.qt-project.org/#/c/1368/1/src/plugins/ qt4projectmanager/qt-s60/symbianqtversion.cpp 11 https://codereview.qt-project.org/#/c/32/1/src/plugins/texteditor/ plaintexteditorfactory.cpp. For analysis 2, we analyze how code owner fixed if statements after reviewing. As Fig. 4 shows, we count the number of symbol which the code owner changes from P atch1 to P atchmerged . For example, in Fig. 4, we find one & and two in P atch1 . After reviewing the P atch1 , we can find that the patch owner added “|”, “(” and “)” as , and deleted “&” and “!”. Then, we count the difference number of symbols between P atch1 and P atchmerged like “&_delete: 1”. Using this dataset, this analysis conducts an empirical study to understand the updates after reviewing using the same frequent itemset mining as Analysis 1. B. Result Table III shows top 50 rules with the highest support score in 364 rules which were detected by frequent itemset mining. Observation 3: 35% of code fixes after reviewing includes the adding or deleting parentheses. 23% of all fixes with if statements includes the adding parentheses (id1 in Table III). On the other hand, 12% of all fixes with if statements includes the deleting parentheses (id5-id9 in Table III). Totally, 35% of all fixes with if statements includes the parentheses fixes because of too many function calls or lacking function calls like the following examples 13 ,14 . Observation 4: Patch owner is likely to add “->”, “&” after reviewing. 8% of all fixes with if statements includes the adding “->” (id15 in Table III). The number of the adding “->” is more than the deleting one (id27 in Table III). Same as “->”, 7% of all fixes with if statements includes the adding “&” (id22 in Table III) like the Listing 8. Observation 5: Patch owner is likely to delete “!” after reviewing. 13% of all fixes with if statements includes the 12 https://codereview.qt-project.org/#/c/2481/1/src/declarative/items/ qsggridview.cpp 13 https://codereview.qt-project.org/#/c/1843/1..2/src/plugins/ qt4projectmanager/qt-desktop/simulatorqtversion.cpp 14 https://codereview.qt-project.org/#/c/1779/1..2/src/plugins/ qmlprojectmanager/qmlprojectruncontrol.cpp.

(6) TABLE II F REQUENT OF CHANGED SYMBOL SETS WITH I F CHANGES . id 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50. symbols “(” “)” “(” ∧ “)” “!” “->” “==” “(” ∧ “->” “!” ∧ “(” “!” ∧ “)” “!” ∧ “(” ∧ “)” “)” ∧ “->” “(” ∧ “)” ∧ “->” “&” “==” ∧ “(” “&” ∧ “(” “==” ∧ “(” ∧ “)” “&” ∧ “)” “&” ∧ “(” ∧ “)” “!=” “!” ∧ “->” “|” “!” ∧ “(” ∧ “->” “!” ∧ “)” ∧ “->” “!” ∧ “(” ∧ “)” ∧ “->” “!=” ∧ “(” “!=” ∧ “(” ∧ “)” “<” “|” ∧ “(” “|” ∧ “(” ∧ “)” “==” ∧ “->” “&” ∧ “->” “>” “!” ∧ “&” “&” ∧ “(” ∧ “->” “&” ∧ “(” ∧ “)” ∧ “->” “(” ∧ “<” “(” ∧ “)” ∧ “<” “==” ∧ “&” “!” ∧ “&” ∧ “(” “!” ∧ “&” ∧ “)” “!” ∧ “&” ∧ “(” ∧ “)” “==” ∧ “(” ∧ “->” “=” “==” ∧ “(” ∧ “)” ∧ “->” “−” “*” “==” ∧ “&” ∧ “(” “(” ∧ “>” “)” ∧ “>” “(” ∧ “)” ∧ “>”. support * 100 56.7 55.1 55.1 31.4 24.6 22.5 19.4 19.4 19.1 19.1 19.1 19.0 15.1 12.5 12.1 11.8 11.7 11.7 10.8 8.8 7.9 7.5 7.4 7.4 7.2 7.1 7.0 6.5 6.4 6.1 6.0 5.7 5.6 5.5 5.4 5.2 5.2 5.2 5.1 5.0 5.0 4.7 4.7 4.7 4.6 4.5 4.3 4.3 4.2 4.2. deleting “!” (id4 in Table III). The number of the deleting “!” is more than the adding one (id16 in Table III). Same as “->”, 7% of all fixes with if statements includes the adding “&” (id22 in Table III) like the Listing 8. Especially, 69% of the deleting “!” (9% of all fixes with if statements) is fixed with the adding “(”, “)” because the patch owner often use any functions instead of “!” like Listing1015 . The other case, “==” is also likely to delete after reviewing because “==” also replace to function(e.g., isEmpty()). 15 https://codereview.qt-project.org/#/c/2422/1..8/src/declarative/items/ qsgcanvas.cpp. Fig. 4. Approach to extract changed symbols after reviewing.. Listing 8. Example add “(” and “)”. − i f ( qmlviewerCommand ( ) . i s E m p t y ( ) ) + i f ( q t V e r s i o n ( ) >= Q t S u p p o r t : : QtVersionNumber ( 4 , 7 , 0 ) && qmlviewerCommand ( ) . i s E m p t y ( ) ). VI. T HREATS TO VALIDITY Internal validity. To analyze code changes before and after reviewing, we extracted symbol changes in textttif statement changes by syntax analysis.Indeed, we would like to analyze the changes based on the diff file and the original source code to identify a spot with if statement. However, since it takes time to collect the original source code, we simply focus on only diff files. we believe that any problems will not affect to our results since the number of if statement changes across multiple lines is 425 patches of our target 69,325 patches (0.006%). External validity. We conduct the empirical study using only Qt project code review dataset. When we target the other projects, some findings of our study may be different. For example, the other project may be often use “<” or “>=” in Table 3 instead of “>” or “<=”. We believe that our approach would be helpful to understand individual rules or trend fixes in each project..

(7) TABLE III S AME TIME CHANGED ITEMS IN CODE REVIEW id 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50. symbols “(” add “)” add “(” add ∧ “)” add “!” delete “)” delete “(” delete “(” delete ∧ “)” delete “(” ∧ “)” delete “)” ∧ “(” delete “!” ∧ “)” add “!” ∧ “(” add “!” ∧ “(” add ∧ “)” add “(” add ∧ “!” delete “(” add ∧ “)” add ∧ “!” delete “->” add “!” add “(” ∧ “)” add “(” ∧ “(” add “(” ∧ “(” add ∧ “)” add “(” ∧ “)” ∧ “(” add “(” ∧ “)” ∧ “)” add “&” add “(” ∧ “)” ∧ “(” add ∧ “)” add if. add “(” add ∧ “->” add “(” add ∧ “)” add ∧ “->” add “->” delete “==” delete “(” ∧ “&” add “(” ∧ “)” ∧ “&” add “&” delete “==” add “!” ∧ “)” delete “(” ∧ “->” delete “!” ∧ “(” ∧ “)” delete “(” ∧ “)” ∧ “->” delete “(” ∧ “!” add “(” ∧ “)” ∧ “!” add “!” ∧ “(” delete “->” ∧ “(” delete “!” ∧ “(” delete ∧ “)” delete “->” ∧ “)” delete “->” ∧ “(” delete ∧ “)” delete “)” ∧ “->” ∧ “(” delete “!” ∧ “)” ∧ “(” delete “(” ∧ “->” ∧ “)” delete “(” ∧ “!” delete “(” ∧ “)” ∧ “!” delete “(” ∧ “->” add “(” ∧ “)” ∧ “&” delete. support * 100 23.32 23.32 23.09 13.27 12.46 12.20 12.05 12.00 11.59 11.24 11.24 11.18 9.12 9.09 8.02 7.46 6.94 6.85 6.71 6.65 6.59 6.59 6.51 4.97 4.82 4.79 4.71 4.59 4.47 4.39 4.36 4.33 4.24 4.15 4.12 4.10 4.10 4.04 3.98 3.95 3.92 3.92 3.89 3.86 3.86 3.86 3.80 3.78 3.60 3.60. VII. R ELATED W ORK A. Code Review Many studies have conducted an empirical studies to understand code review works [8], [9], [10], [11], [12], [22], [23], [24], [25]. Most published code review studies focused review process or reviewers communication. For example, Tsay et al. found that patch authors and reviewers often discuss and propose solutions to fix a patch each other [22]. In particula, Czerwonka et al. [23] found that 15% of the discussion for a patch fix is about functional issues. Also, Mäntylä et al. [24] and Beller et al. [25] found that 75% of the discussion for a patch fix is about software maintenance. Listing 9. Example delete “(” and “)”. − i f ( c o n f i g −>q t V e r s i o n ( ) && Q t S u p p o r t : : Q m l O b s e r v e r T o o l : : c a n B u i l d ( c o n f i g −> qtVersion () ) ) + i f ( QtSupport : : QmlObserverTool : : c a n B u i l d ( c o n f i g −>q t V e r s i o n ( ) ) ). Listing 10. Example delete “!”. − +. i f ( ! hoverItems ) i f ( hoverItems . isEmpty ( ) ). and 15% of the discussion is about functional issues. From these studies, we could understand issues which we should solve in code review process. Next, we should focus on how we fix those issues. As the first step, we focused source code changes through code review, especially if changes. B. Coding Conventions Appropriate coding conventions prevent software faults [?]. As a code fix study, refactoring study is the most popular one in software engineering field [20]. Particularly, code convention issue is much relate to our study. Smit et al. [20] found that CheckStyle is useful to check whether or not a source code follows their coding rule. Also, some convention tool has released to check a format of coding convention such as Pylint16 . Furthermore, Allamanis et al. [21] developed a tool to fix code convention. However, in our best knowledge, little is known how a code owner fixes conditional statement issues based on reviewers feedback. VIII. C ONCLUSION In this paper, our empirical study discuss how a patch author fix if statement based on reviewer feedback. According to the results of our case study on Qt project, While 55% of the “if” statement changes including “(” and “)” changes, 35% of code fixes after reviewing includes the adding or deleting parentheses. In the most of cases, a patch author often add parentheses to call a function. In addition, we found “->” and “&” are likely to be added, and “!” is likely to be deleted after reviewing. These might be changed to fix a potential bug. And, if patch authors check the possible to change these before request code review, the reviewers could spend more time for the other review requests. In the future, we would like to propose a method to review and fix a symbol in if statement automatically. ACKNOWLEDGMENT Support Center for Advanced Telecommunications (SCAT) Technology Research, Foundation This work was supported by Grant-in-Aid for JSPS Research Fellow Number 17J09333. 16 https://www.pylint.org/.

(8) R EFERENCES [1] P. C. Rigby and M.-A. Storey, “Understanding broadcast based peer review on open source software projects,” in Proceedings of the 33rd International Conference on Software Engineering, 2011, pp. 541–550. [2] D. S. Alberts, “The economics of software quality assurance,” in Proceedings of the June 7-10, 1976, National Computer Conference and Exposition. New York, NY, USA: ACM, 1976, pp. 433–442. [3] K. Pan, S. Kim, and E. J. Whitehead, “Toward an understanding of bug fix patterns,” Empirical Software Engineering, vol. 14, no. 3, pp. 286–315, 2009. [4] M. Martinez, L. Duchien, and M. Monperrus, “Automatically extracting instances of code change patterns with AST analysis,” IEEE International Conference on Software Maintenance, ICSM, pp. 388–391, 2013. [5] S. H. Tan, J. Yi, S. Mechtaev, A. Roychoudhury et al., “Codeflaws: a programming competition benchmark for evaluating automated program repair tools,” in Proceedings of the 39th International Conference on Software Engineering Companion. IEEE Press, 2017, pp. 180–182. [6] Y. Tao, D. Han, and S. Kim, “Writing acceptable patches: An empirical study of open source project patches,” in Proceedings of the International Conference on Software Maintenance and Evolution, 2014, pp. 271–280. [7] E. S. Raymond, “The cathedral and the bazaar,” Knowledge, Technology & Policy, vol. 12, no. 3, pp. 23–49, 1999. [8] S. McIntosh, Y. Kamei, B. Adams, and A. E. Hassan, “The impact of code review coverage and code review participation on software quality: A case study of the qt, vtk, and itk projects,” in Proceedings of the 11th Working Conference on Mining Software Repositories, 2014, pp. 192– 201. [9] A. Meneely, A. C. R. Tejeda, B. Spates, S. Trudeau, D. Neuberger, K. Whitlock, C. Ketant, and K. Davis, “An empirical investigation of socio-technical code review metrics and security vulnerabilities,” in Proceedings of the 6th International Workshop on Social Software Engineering, 2014, pp. 37–44. [10] P. Thongtanunam, S. McIntosh, A. E. Hassan, and H. Iida, “Investigating code review practices in defective files: An empirical study of the qt system,” in Proceedings of the 12th Working Conference on Mining Software Repositories, 2015, pp. 168–179. [11] R. Morales, S. McIntosh, and F. Khomh, “Do code review practices impact design quality? a case study of the qt, vtk, and itk projects,” in Proceedings of the 22nd International Conference on Software Analysis, Evolution, and Reengineering, 2015, pp. 171–180. [12] S. McIntosh, Y. Kamei, B. Adams, and A. E. Hassan, “An empirical study of the impact of modern code review practices on software quality,” Empirical Software Engineering, vol. 21, no. 5, pp. 2146–2189, 2016. [13] P. C. Rigby and C. Bird, “Convergent contemporary software peer review practices,” in Proceedings of the 9th Joint Meeting on Foundations of Software Engineering, 2013, pp. 202–212.. [14] P. Thongtanunam, C. Tantithamthavorn, R. G. Kula, N. Yoshida, H. Iida, and K. Matsumoto, “Who should review my code? a file location-based code-reviewer recommendation approach for modern code review,” in Proceedings of the 22nd International Conference on Software Analysis, Evolution, and Reengineering, 2015, pp. 141–150. [15] V. Balachandran, “Reducing human effort and improving quality in peer code reviews using automatic static analysis and reviewer recommendation,” in Proceedings of the 35th International Conference on Software Engineering, 2013, pp. 931–940. [16] M. Zanjani, H. Kagdi, and C. Bird, “Automatically recommending peer reviewers in modern code review.” Transactions on Software Engineering, vol. 42, no. 6, pp. 530–543, 2015. [17] M. M. Rahman, C. K. Roy, and J. A. Collins, “Correct: Code reviewer recommendation in github based on cross-project and technology experience,” in Proceedings of the 38th International Conference on Software Engineering, 2016, pp. 222–231. [18] X. Xia, D. Lo, X. Wang, and X. Yang, “Who should review this change? putting text and file location analyses together for more accurate recommendations.” in Proceedings of the 31st International Conference on Software Maintenance and Evolution, 2015, pp. 261–270. [19] T. Hirao, A. Ihara, Y. Ueda, P. Phannachitta, and K. Matsumoto, “The impact of a low level of agreement among reviewers in a code review process,” in The 12th International Conference on Open Source Systems, 2016, pp. 97–110. [20] J. Tsay, L. Dabbish, and J. Herbsleb, “Let ’s talk about it: Evaluating contributions through discussion in github.” in Proceedings of the 22nd International Sym posium on Foundations of Software Engineering, 2014, pp. 144–154. [21] J. Czerwonka, M. Greiler, and J. Tilford, “Code reviews do not find bugs: How the current code review best practice slows us down,” in Proceedings of the 37th International Conference on Software Engineering, 2015, pp. 27–28. [22] M. V. Mäntylä and C. Lassenius, “What types of defects are really discovered in code reviews?” IEEE Transactions on Software Engineering, vol. 35, no. 3, pp. 430–448, 2009. [23] M. Beller, A. Bacchelli, A. Zaidman, and E. Juergens, “Modern code reviews in open-source projects: Which problems do they fix?” in Proceedings of the 11th Working Conference on Mining Software Repositories, 2014, pp. 202–211. [24] C. Boogerd and L. Moonen, “Assessing the value of coding standards: An empirical study,” IEEE International Conference on Software Maintenance, ICSM, pp. 277–286, 2008. [25] M. Smit, B. Gergel, H. J. Hoover, and E. Stroulia, “Code convention adherence in evolving software,” in Software Maintenance (ICSM), 2011 27th IEEE International Conference on. IEEE, 2011, pp. 504–507. [26] M. Allamanis, E. T. Barr, C. Bird, and C. Sutton, “Learning natural coding conventions,” in Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. ACM, 2014, pp. 281–293..

(9)