Automatically Customizing Static
Analysis Tools to Coding Rules
Really Followed by Developers
Yuki Ueda, Takashi Ishio and Kenichi Matsumoto
Nara Institute of Science and Technology
SANER2021
Static Analysis Tools or Linters
2
Static analysis tools or linters can detect:
1. Security Vulnerabilities,
2. Performance Issues,
3. Bad Programming Practices, Code Smells
These violations are defined by Coding Rules
Example of coding rule violations
3
if (a=b) {
return True
} else {
threw new
Error();
}
return False
JavaScript
Rule 1:
Limit the assignment in
conditional statement
a=b a==b
Example of coding rule violations
4
if (a=b) {
return True
} else {
threw new
Error();
}
return False
JavaScript
Rule 2:
Limit the unreachable code
return False
Linters in SE Research
5
Code Review [1]
[1] Carvalho, A., Luz, W., Marc´ılio, D., Bonif´acio, R.,Pinto, G. and Canedo, E. D.: C-3PR: A Bot for Fixing Static Analysis Violations via Pull Requests,
SANER’20
[2] Bavishi, Rohan, Hiroaki Yoshida, and Mukul R. Prasad. "Phoenix: Automated data-driven synthesis of repairs for static analysis violations." ESEC/FSE’19
[3] Trautsch, Alexander, Steffen Herbold, and Jens Grabowski. "Static source code metrics and static analysis warnings for fine-grained just-in-time defect
prediction." ICSME’20
Defect Prediction [3]
Bug Repair [2]
Linters in SE Research
6
Code Review [1]
These Studies Assume the Linters Are Correct
[1] Carvalho, A., Luz, W., Marc´ılio, D., Bonif´acio, R.,Pinto, G. and Canedo, E. D.: C-3PR: A Bot for Fixing Static Analysis Violations via Pull Requests,
SANER’20
[2] Bavishi, Rohan, Hiroaki Yoshida, and Mukul R. Prasad. "Phoenix: Automated data-driven synthesis of repairs for static analysis violations." ESEC/FSE’19
[3] Trautsch, Alexander, Steffen Herbold, and Jens Grabowski. "Static source code metrics and static analysis warnings for fine-grained just-in-time defect
prediction." ICSME’20
Defect Prediction [3]
Bug Repair [2]
Default Rules != Followed Rules
7
Dataset: 4 JavaScript Projects
• Used in BugsJS [4]
• Using ESLint [5]
[4] Gyimesi, Péter, et al. "BUGSJS: a benchmark and taxonomy of JavaScript
bugs." Software Testing, Verification and Reliability (2019): e1751.
[5] N. C. Zakas, B. Mills, T. Nagashima, and M. Djermanovic, “ES-Lint -
Pluggable JavaScript linter,” https://eslint.org/, 2020
N = 241 Default Rules: 57 Non-default Rules: 184
Followed by All Projects: 64 True Positives: 38 False Negatives: 26
Unfollowed by 1+ Projects: 177 False: Positives: 19 True Negatives: 158
1. 40% (26 / 64) of followed rules are not default
Default Rules != Followed Rules
8
N = 241 Default Rules: 57 Non-default Rules: 184
Followed by All Projects: 64 True Positives: 38 False Negatives: 26
Unfollowed by 1+ Projects: 177 False: Positives: 19 True Negatives: 158
1. 40% (26 / 64) of followed rules are not default
2. 33% (19 / 57) of default rules are ignored
Dataset: 4 JavaScript Projects
• Used in BugsJS [4]
• Using ESLint [5]
[4] Gyimesi, Péter, et al. "BUGSJS: a benchmark and taxonomy of JavaScript
bugs." Software Testing, Verification and Reliability (2019): e1751.
[5] N. C. Zakas, B. Mills, T. Nagashima, and M. Djermanovic, “ES-Lint -
Pluggable JavaScript linter,” https://eslint.org/, 2020
Default Rules != Followed Rules
9
N = 241 Default Rules: 57 Non-default Rules: 184
Followed by All Projects: 64 True Positives: 38 False Negatives: 26
Unfollowed by 1+ Projects: 177 False: Positives: 19 True Negatives: 158
1. 40% (26 / 64) of followed rules are not default
2. 33% (19 / 57) of default rules are ignored
Dataset: 4 JavaScript Projects
• Used in BugsJS [4]
• Using ESLint [5]
[4] Gyimesi, Péter, et al. "BUGSJS: a benchmark and taxonomy of JavaScript
bugs." Software Testing, Verification and Reliability (2019): e1751.
[5] N. C. Zakas, B. Mills, T. Nagashima, and M. Djermanovic, “ES-Lint -
Pluggable JavaScript linter,” https://eslint.org/, 2020
Linter Rules should be customized
Goal: Optimizing the Coding Rules
1. Reduce False Negative (non-default but followed) rules
Enabling the rules that are followed by the all of project files
2. Reduce False Positive (default but unfollowed) rules
Disabling the rules that are violated by the one or more files
10
Linter-Maintainer:
Tracing Followed Coding Rules
11
Project Code Files Coding Rule
Configuration File
Followed Rule List
When developer installed linter, execute
Input Output
$linter-maintainer --generate --eslint-js ./your/project/path > .eslintrc.json
Evaluation Process 1 / 4
12
Generate
Version 1.0.0
Configuration File 1.0.0
Evaluation Process 2 / 4
13
Apply and
Calc False Positive/Negative
Version 1.0.1
Version 1.0.0
Configuration File 1.0.0
Evaluation Process 3 / 4
14
Generate
Version 1.0.1 Version 1.0.2
Configuration File 1.0.1
Evaluation Process 4 / 4
15
Version 1.0.2
Apply both of
Major and Maintainance Rules
Version 1.0.1
Version 1.0.0
Configuration File 1.0.0 Configuration File 1.0.1
Rule Updates Reduce Median False Positives
by >49%
16
0.00-0.89
Precision 1.00
0.70-0.99
Maintainance
Major
0.00-0.39
Recall 1.00
0.88-0.99
Original
1.0.0 -> 1.0.2 1.0.1 -> 1.0.2
Rule Updates Reduce Median False Positives
by >49%
17
0.00-0.89
Precision 1.00
0.70-0.99
Maintainance
Major
0.00-0.39
Recall 1.00
0.88-0.99
Original
Rule updates for each major version are effective enough
1.0.0 -> 1.0.2 1.0.1 -> 1.0.2
Conclusion
• Linter-Maintainer traces the latest followed rules
• Linter-maintainer reduced false negatives by >49%
Future Plan
• Increasing evaluated languages and projects
• Improving rule selecting approach by using Git history
18
Install
Source
Unsupported Supported Evaluated
C/C++ Java JavaScript
Ruby Python
TypeScript

Automatically Customizing Static Analysis Tools to Coding Rules Really Followed by Developers

  • 1.
    Automatically Customizing Static AnalysisTools to Coding Rules Really Followed by Developers Yuki Ueda, Takashi Ishio and Kenichi Matsumoto Nara Institute of Science and Technology SANER2021
  • 2.
    Static Analysis Toolsor Linters 2 Static analysis tools or linters can detect: 1. Security Vulnerabilities, 2. Performance Issues, 3. Bad Programming Practices, Code Smells These violations are defined by Coding Rules
  • 3.
    Example of codingrule violations 3 if (a=b) { return True } else { threw new Error(); } return False JavaScript Rule 1: Limit the assignment in conditional statement a=b a==b
  • 4.
    Example of codingrule violations 4 if (a=b) { return True } else { threw new Error(); } return False JavaScript Rule 2: Limit the unreachable code return False
  • 5.
    Linters in SEResearch 5 Code Review [1] [1] Carvalho, A., Luz, W., Marc´ılio, D., Bonif´acio, R.,Pinto, G. and Canedo, E. D.: C-3PR: A Bot for Fixing Static Analysis Violations via Pull Requests, SANER’20 [2] Bavishi, Rohan, Hiroaki Yoshida, and Mukul R. Prasad. "Phoenix: Automated data-driven synthesis of repairs for static analysis violations." ESEC/FSE’19 [3] Trautsch, Alexander, Steffen Herbold, and Jens Grabowski. "Static source code metrics and static analysis warnings for fine-grained just-in-time defect prediction." ICSME’20 Defect Prediction [3] Bug Repair [2]
  • 6.
    Linters in SEResearch 6 Code Review [1] These Studies Assume the Linters Are Correct [1] Carvalho, A., Luz, W., Marc´ılio, D., Bonif´acio, R.,Pinto, G. and Canedo, E. D.: C-3PR: A Bot for Fixing Static Analysis Violations via Pull Requests, SANER’20 [2] Bavishi, Rohan, Hiroaki Yoshida, and Mukul R. Prasad. "Phoenix: Automated data-driven synthesis of repairs for static analysis violations." ESEC/FSE’19 [3] Trautsch, Alexander, Steffen Herbold, and Jens Grabowski. "Static source code metrics and static analysis warnings for fine-grained just-in-time defect prediction." ICSME’20 Defect Prediction [3] Bug Repair [2]
  • 7.
    Default Rules !=Followed Rules 7 Dataset: 4 JavaScript Projects • Used in BugsJS [4] • Using ESLint [5] [4] Gyimesi, Péter, et al. "BUGSJS: a benchmark and taxonomy of JavaScript bugs." Software Testing, Verification and Reliability (2019): e1751. [5] N. C. Zakas, B. Mills, T. Nagashima, and M. Djermanovic, “ES-Lint - Pluggable JavaScript linter,” https://eslint.org/, 2020 N = 241 Default Rules: 57 Non-default Rules: 184 Followed by All Projects: 64 True Positives: 38 False Negatives: 26 Unfollowed by 1+ Projects: 177 False: Positives: 19 True Negatives: 158 1. 40% (26 / 64) of followed rules are not default
  • 8.
    Default Rules !=Followed Rules 8 N = 241 Default Rules: 57 Non-default Rules: 184 Followed by All Projects: 64 True Positives: 38 False Negatives: 26 Unfollowed by 1+ Projects: 177 False: Positives: 19 True Negatives: 158 1. 40% (26 / 64) of followed rules are not default 2. 33% (19 / 57) of default rules are ignored Dataset: 4 JavaScript Projects • Used in BugsJS [4] • Using ESLint [5] [4] Gyimesi, Péter, et al. "BUGSJS: a benchmark and taxonomy of JavaScript bugs." Software Testing, Verification and Reliability (2019): e1751. [5] N. C. Zakas, B. Mills, T. Nagashima, and M. Djermanovic, “ES-Lint - Pluggable JavaScript linter,” https://eslint.org/, 2020
  • 9.
    Default Rules !=Followed Rules 9 N = 241 Default Rules: 57 Non-default Rules: 184 Followed by All Projects: 64 True Positives: 38 False Negatives: 26 Unfollowed by 1+ Projects: 177 False: Positives: 19 True Negatives: 158 1. 40% (26 / 64) of followed rules are not default 2. 33% (19 / 57) of default rules are ignored Dataset: 4 JavaScript Projects • Used in BugsJS [4] • Using ESLint [5] [4] Gyimesi, Péter, et al. "BUGSJS: a benchmark and taxonomy of JavaScript bugs." Software Testing, Verification and Reliability (2019): e1751. [5] N. C. Zakas, B. Mills, T. Nagashima, and M. Djermanovic, “ES-Lint - Pluggable JavaScript linter,” https://eslint.org/, 2020 Linter Rules should be customized
  • 10.
    Goal: Optimizing theCoding Rules 1. Reduce False Negative (non-default but followed) rules Enabling the rules that are followed by the all of project files 2. Reduce False Positive (default but unfollowed) rules Disabling the rules that are violated by the one or more files 10
  • 11.
    Linter-Maintainer: Tracing Followed CodingRules 11 Project Code Files Coding Rule Configuration File Followed Rule List When developer installed linter, execute Input Output $linter-maintainer --generate --eslint-js ./your/project/path > .eslintrc.json
  • 12.
    Evaluation Process 1/ 4 12 Generate Version 1.0.0 Configuration File 1.0.0
  • 13.
    Evaluation Process 2/ 4 13 Apply and Calc False Positive/Negative Version 1.0.1 Version 1.0.0 Configuration File 1.0.0
  • 14.
    Evaluation Process 3/ 4 14 Generate Version 1.0.1 Version 1.0.2 Configuration File 1.0.1
  • 15.
    Evaluation Process 4/ 4 15 Version 1.0.2 Apply both of Major and Maintainance Rules Version 1.0.1 Version 1.0.0 Configuration File 1.0.0 Configuration File 1.0.1
  • 16.
    Rule Updates ReduceMedian False Positives by >49% 16 0.00-0.89 Precision 1.00 0.70-0.99 Maintainance Major 0.00-0.39 Recall 1.00 0.88-0.99 Original 1.0.0 -> 1.0.2 1.0.1 -> 1.0.2
  • 17.
    Rule Updates ReduceMedian False Positives by >49% 17 0.00-0.89 Precision 1.00 0.70-0.99 Maintainance Major 0.00-0.39 Recall 1.00 0.88-0.99 Original Rule updates for each major version are effective enough 1.0.0 -> 1.0.2 1.0.1 -> 1.0.2
  • 18.
    Conclusion • Linter-Maintainer tracesthe latest followed rules • Linter-maintainer reduced false negatives by >49% Future Plan • Increasing evaluated languages and projects • Improving rule selecting approach by using Git history 18 Install Source Unsupported Supported Evaluated C/C++ Java JavaScript Ruby Python TypeScript

Editor's Notes

  • #2 Hello, I am Yuki Ueda at Nara Institute of Science and Technology in Japan. Today, I will present about "Automatically Customizing Static Analysis Tools to Coding Rules Really Followed by Developers"
  • #3 First, I introduce what static analysis tools and coding rules are. The tools detect Security Vulnerabilities, Performance Issues, and Bad Programming Practices that are called Code Smells. And, Coding rules are documents that defined these violations.
  • #4 As the example, the right side source code violates for two coding rules in JavaScript. First is the assignment in conditional statement it should be double equal
  • #5 Second is unreachable code. The orange code has no impact for the execution process. So, it should be removed. Using static analysis tool, developer can avoid bugs automatically.
  • #6 These tools are not only for the real development.. The linters are also widely used in the software engineering research fields. Such as the Code Review, Auto Bug repair, and Defect Prediction researches.
  • #7 These great studies Assume the Linters violations and rules Are Correct for the developers
  • #8 However widely used coding rules are different with actually followed coding rules. Sometimes coding rules are too much or too little for developers In our preliminary study, we selected 4 JavaScript Projects as the Dataset, these are used in BugsJS for bug benchmark, and using JavaScript Linter ESLint. ESLint has 241 rules and enables only 57 rules. We found two problems in target projects. First for the False Negative, all of the target projects followed 64 rules, however 40% of rules are not enabled as the default rules
  • #9 Another problem is about False Positives. One or more our target projects unfollowed 177 rules. From these rules, 19 rules are enabled as the default rules Not only in our preliminal study, similar results are reported by the many exisitng researches
  • #10 Totally, current linter rules should be customized for the each developers  ここまで5ふん
  • #11 To solving current coding rules problems, our goal is optimizing the linters’ coding rules We have two ideas for the sub-goals. First for the reducing false negative rules. We enable the rules that are followed by the all of the projects’ files Next for the reducing false positve rules. We disable the rules that are violated by the one or more files.
  • #12 To achieve our goals, we developed the tool linter-maintainer, that trace the followed coding rules from project source code files. It is available as the command line interface. As the Input, the tool will use project source code file, and illuminate the followed rule list. Finally as the output, the tool generate linter configuration file
  • #13 In the evaluation process, First we generate linter configuration file that has followed rule list from one versions’ source code files.
  • #14 Next we applied generater configuration file to the next version of source code file. And we caluculate the false positives and false negatives by comparing with configurations rules and latest followed rules.
  • #15 We repeat this process in the next and subsequent versions.
  • #16 Finally, We also evaluated the major, minor, and maintenance version configuration files to investigate the optimal rule update frequency. In that case, we use major versions’ file 1.0.0 and maintainance version file 1.0.1
  • #17 Here is the result for the rule precision and recall from the projects’ original configuration file and our updated configuration files. Totally, our approach improve the both of the values. Especially for the recall, using our tool is effective for finding potential coding rules.
  • #18  Even rough major updates, it is better than nothing.
  • #19 I will summarize our researh We developed the tool Linter-Maintainer that will traces the latest followed rules And in the evaluation, Linter-maintainer reduced false negatives by >49% As the Future Plan Increasing evaluated languages and projects Improving rule selecting approach by using Git history Finally our tool is available as the npm packages and we published our source code on the github from right QR code. Please send me the your feedback. Thank you