Investigation of Coding Violations Focusing on
Authorships of Source FilesAji Ery Burhandenny
Graduate School of Science and Engineering, Ehime University
Matsuyama, Ehime, Japan 790–8577
Engineering Faculty, Mulawarman University
Samarinda, East Kalimantan, Indonesia 75119
Email: a.burhandenny@ft.unmul.ac.id

Abstract—While static code analysis tools would be helpful
in reviewing source code, they have not been actively utilized
in practice. One of main reasons why they are not used bypractitioners has been said that such tools output many warnings(violations to predefined rules) but most of them are false positive.
Thus, there have been studies evaluating violations in the past.
This paper focuses on one of such studies, which evaluates
violations using their change patterns over releases. Then, thepaper examines an impact of authorship on those violation
evaluations because a preference of a certain programmer may
have an affect on a creation or modification of violation. This
paper collects violations made by a popular static code analysis
tool, PMD, from seven open source software projects. The setof collected data is divided into two subsets according to theauthorship of source file: the set of violations appearing insource files which have been developed and maintained by asingle programmer (single-authored files) vs. the set of ones
appearing in source files which have been done by two or moreprogrammers (multi-authored files). The results of data analyses
show the following findings: (1) the difference in the authoringtype has significant impacts on the trends of violations and theirevaluations; (2) while important violations tend to vary fromproject to project and from person to person, about 30% of
violations would be commonly worthless across projects for many
programmers.

I. I NTRODUCTION
Code review has been widely known for its usefulness indetecting latent faults as early as possible [1]. While it is ideal
to perform code reviews for all source files whenever they
are upgraded, it would be difficult due to their performing
costs. In order to support the code review activity, automatedtools, i.e., static code analysis tools have been developed in
the past. While those tools can quickly and automaticallydetect problematic code fragments or fault-prone ones andthey look to be great helps for code reviews, those tools havenot been actively used by practitioners in practice. According
to the report by Johnson et al. [2], one of key reasons why
practitioners do not use such tools is said that too many
warnings (violations to predefined rules) are outputted bytools but most of them are false-positive and worthless formany programmers. That is to say, many warnings are ones
that programmers do not consider to be fixed during theirprogrammings.

Hirohisa Amanand
Minoru Kawahara
Center for Information Technology
Ehime University
Matsuyama, Ehime, Japan 790–8577

In order to address the issue of many false-positive violations, there have been studies which evaluate or prioritize
violations. Shen et al. [3] proposed to leverage feedbacks fromtool’s users for providing rankings of violations which are
more suitable for the users, and improving the true-positive
rate. However, their method is not always reasonable since
it requires a lot of manual evaluations (feedbacks) by user’shand. As an automated way of collecting evaluations, Aji etal. [4] focused on change patterns of violations over releases,
and proposed a metric for evaluating violations, “Index of
Programmer’s Attention (IPA).” When some parts of a source
file were warned as a violation and the number of thosewarned parts have been decreased through their upgrades, sucha decreasing trend is a proof that the programmer paid anattention to the violation and fixed them. On the other hand,
if the number of warned parts have been constant or increased
through their upgrades, the programmer would disregard thecorresponding violation. IPA is a ratio of the former cases
to the latter cases as an index of violation’s importance.
While an empirical study using IPA was reported in literature[4], the study missed a consideration for the authorship ofsource files. When a source file has been developed andmaintained by a single programmer, the violations warned in
the source file depend on the programmer’s preference. If two
or more programmers are involved in the development andmaintenance of a source file, the violations appearing in the filewould be influenced by common sense of those programmers.
Thus, this paper will examine the impact of authorship on
the above evaluation of violations and report the results ofinvestigation.
The remainder of this paper is organized as follows: Section
II presents the research background and the definition of themetric we used, and sets up our research questions. Section
III reports our data collection from open source software(OSS) projects and the results of data analyses along with
our discussions. Section IV briefly describes the related workof this study. Finally, Section V gives the conclusions of thispaper and the future plan of our study.

II. E VALUATION OF V IOLATION AND
AUTHORSHIP OF S OURCE F ILE
In order to evaluate violations made by a static code analysis
tool, Aji et al. [4] focused on change patterns of violations overreleases: (1) one-shot, (2) sticky, (3) decreasing, (4) increasing,and (5) other. The one-shot pattern of a violation means that it
appeared only at one version through all releases. The sticky
pattern of a violation refers to the case that the number of
appearances is constant from its first warned version to thelatest one. The decreasing pattern of a violation corresponds
to the case that the number of appearances monotonicallydecreased after its first appearance version, and the increasing
pattern means a monotonically increasing case. The otherpattern is a mixed case of the above four patterns. Violations
belong to the one-shot pattern or the decreasing one seem to be
paid attentions by programmers since one or more violations
had been eliminated through a upgrade. On the other hand,violations of the sticky pattern or the increasing one would
be disregarded by programmers because those ones were notcleared throughout upgrades. Aji et al. proposed the following
metric, “Index of Programmers’ Attention (IPA)” using thesenotions: For a violation (warning) v,
IPA(v) =No (v) + Nd (v),Ns (v) + Ni (v)where No (v), Nd (v), Ns (v) and Ni (v) are the numbers ofparts warned as violation v belonging to “one-shot,” “decreasing,” “sticky” and “increasing,” respectively.
When Ns (v) + Ni (v) = 0, we define IPA(v) = ∞. Noticethat the study excludes violation v such that No (v) + Nd (v) +Ns (v) + Ni (v) = 0.
2
Based on the above notion, we can categorize violations
into the following three groups—priority “high,” “middle” and“low”:
1) When No (v) + Nd (v) > 0 and Ns (v) + Ni (v) = 0(IPA(v) = ∞), there were only cases that programmers
paid attentions. In these cases, violation v must be
related to problematic or fully-undesirable code. Such a
violation would be highly important in the code quality
management. We define v’s priority to be “high.”
2) When No (v) + Nd (v) ≥ Ns (v) + Ni (v) > 0 (1 ≤IPA(v) < ∞), there were both cases that programmers
paid attentions and disregarded, and the number of former cases is greater than or equal to the number of latter
cases. In these cases, violation v would be relatively
important: we define v’s priority to be “middle.”3) When No (v) + Nd (v) < Ns (v) + Ni (v) (IPA(v) < 1),there were more disregarded cases, so violation v would
be insignificant: we define v’s priority to be “low.”2
The above priorities of violations can be automaticallycomputed with using the code change history. It is an advantage of the proposal; while Shen et al. [3] proposed toadjust priorities for improving a static code analysis tool, theirapproach requires feedbacks from users and it would be hard

to collect a lot of data in the case of large-scale software
products.
Although the notion of IPA seems to be useful in evaluating
many violations automatically, it may be affected by differences in organization or style of development. If a source filehas been developed and maintained by a certain programmer
only, the paying-attention or disregarding would depend on
the programmer’s preference. Thus, we will focus on whether
a source file has been developed and maintained by a single
programmer or not, and examine its impact on the violation
evaluation in this paper. For the sake of convenience, we willcall a source file which has been developed and maintained bya single developer, as a “single-authored file”; we will refer toa source file which has been developed or maintained by two
or more developers, as a “multi-authored file.”
Toward a more sophisticated IPA-based evaluation of violations, we will tackle the following research questions:
RQ1: Does the difference in the authoring type have an impact on the trend of violations and their evaluations?
RQ2: How many violations are commonly important or
worthless across projects and authoring types?
III. E MPIRICAL S TUDY
A. Aim and Studied Projects
In order to answer the above RQs, we examine OSS products from the perspective of not only the coding violation’s
priority but also the file authorship. Table I shows the projects
surveyed in this study, which are the same as the dataset usedin the previous work [4]; Those projects had been randomly
selected from GitHub. By comparing IPA-based evaluationsof coding violations between the set of single-authored files
and the set of multi-authored ones, we study an impact ofauthorship on the priority of coding violations.
B. Data Collection
For each project, we conducted our data collection in thefollowing procedure:1) We cloned the repository on our local disk in order toanalyze the trends of coding violations smoothly.
2) For each release version, we checked out all files andperformed a static code checking by using the PMD (ver.
5.4.1) with its all rule sets.
3) For each file f , we examined who created f or madechanges to f by checking commit logs which f has been
involved in, i.e., author(s). Then, we counted the unique
number of authors associated with f , and decided if f
TABLE I: Surveyed OSS projects.
Project Name
Guava
Elasticsearch
Spring Framework
React Native
JabRefJUnit4Hibernate

Investigation Period
Jan. 2010 − Dec. 2015
Feb. 2010 − Feb. 2016
Dec. 2008 − Apr. 2016
Mar. 2015 − Feb. 2016
Dec. 2011 − Jan. 2016
Dec. 2004 − Dec. 2014
July. 2010 − Feb. 2016

# of Releases
59
143
85
56
23
20
111

is a single-authored file or a multi-authored one. Since
there may be an author who has two or more different
names or e-mail addresses, we integrated duplicatedauthors by the following rules [5]: (1) if two authors
have different addresses but the same name, then we
regard them as the same author; (2) if two authors havethe same address but different names, then we regard
them as the same author.
4) For each single-authored file fs and each violation v
warned by PMD, we traced the change of its occurrences
over releases and decided its change pattern from (1)one-shot, (2) sticky, (3) decreasing, (4) increasing and(5) other. Similarly, we decided change patterns of all
violations by checking all multi-authored files as well.
5) For each violation v appeared in single-authored files,
we obtained No (v), Ns (v), Nd (v) and Ni (v) by counting the decided patterns in all files, then computed
IPA(v) and decided its priority from “high,” “middle”
and “low.” We determined priorities of all violations
appeared in multi-authored files as well.
C. Analysis 1 (for RQ1): Comparison of Violations Appearingin Single-Authored Files vs. Multi-Authored Files
If the difference in the authoring type—single author vs.
multi authors—has an impact on the coding violations, there
are differences in the sets of violations or in the prioritiesof violations. That is to say, the former type is a distinct
difference such that the set of violations appearing in the
single-authored files differs from the set of ones appearing
in the multi-authored files. On the other hand, the latter
type of difference is more complicated: although appearing
violations are common regardless of the authoring type, there
is a discrepancy in their priorities. Thus, we checked these
two types of differences.
At first, for each OSS project, we examined the similarity
between the sets of violations which appear in the singleauthored files and in the multi-authored ones, respectively. We
computed the Jaccard index as the similarity: Let Vs and Vm
be the sets of violations appearing in the single-authored files
and in the multi-authored ones, respectively. The similarity
between them, Jac(Vs , Vm ), is computed with the following
equation:| Vs ∩ Vm |Jac(Vs , Vm ) =.
(1)| Vs ∪ Vm |The Jaccard index ranges from 0 to 1: a higher value corresponds to a pair of sets which are more similar, i.e., there are
more common elements in those sets.
Table II shows the computed similarities. As the results,
there is a variety in the similarity. Most violations appearing
in Guava or Elasticsearch are common between the sets ofsingle-authored files and of multi-authored ones, where theirsimilarities are around 0.8. On the other hand, JUnit4 shows alow-level similarity (0.115), so there are significant differences
between the sets of violations appearing in the single-authoredfiles and of the multi-authored ones.

TABLE II: Similarities between violation sets: single-authoredfiles vs. multi-authored files.
Project
Guava
Elasticsearch
Spring Framework
React Native
JabRefJUnit4Hibernate

Jaccard Index
0.813
0.791
0.637
0.547
0.398
0.115
0.659

Next, we focused on whether there is a difference inthe trends of violation priorities in accordance with the fileauthorship. Table III summarizes the numbers of violations
according to their priority levels and their authoring types.
From the table, we can see the common trend that mostappearing violations have low-level priorities, and only a few
violations are at the middle or high levels.
In order to examine a difference between violations according to the authorships, we singled out those middle or highlevel-priority violations. Table IV shows those violations andtheir priority levels according to authorships. While there are
29 violations1 having middle or high-level priorities in either
the single-authored files or the multi-authored ones, 15 outof 29 violations appear only in one of two authoring types.
Moreover, 12 out of the remaining 14 violations have lowlevel priorities in either the single-authored files or the multiauthored ones. That is to say, important violations getting
programmers’ attention tend to differ in accordance with theauthorship of source file; Even if a violations is considered to
be important at a single-authored file, it may be disregarded
by many other authors (programmers). Such a difference may
come from the preference of programmer.
TABLE III: Number of violations according to their priorities
and authoring types.
Project
Guava

Elasticsearch

Spring Framework

React Native

JabRefJUnit4Hibernate

Priority
Low
MiddleHigh
Low
MiddleHigh
Low
MiddleHigh
Low
MiddleHigh
Low
MiddleHigh
Low
MiddleHigh
Low
MiddleHigh

Single-Authored
146
0
0
140
0
3
119
0
0
66
0
4
63
0
3
14
0
0
119
0
4

Multi-Authored
161
1
2
169
3
2
177
1
1
110
1
0
161
2
3
111
0
1
184
0
0

1 Violations “AddEmptyString,” “PositionLiteralsFirstInCaseInsensitiveComparisons” and “ImportFromSapePackage” appears across projects.

TABLE IV: Appearing violations with middle or high level priorities in single-authored files or multi-authored files.
Project
Guava

Elasticsearch

SpringFramework

React Native

JabRefJUnit4Hibernate

Violation
AddEmptyString
EmptyStatementNotInLoop
ForLoopsMustUseBraces
JUnit4TestShouldUseTestAnnotation
PositionLiteralsFirstInCaseInsensitiveComparisons
CloneMethodMustBePublic
DoNotCallSystemExit
UseProperClassLoader
BadComparison
DontImportJavaLang
AddEmptyString
UnusedLocalVariable
UnnecessaryLocalBeforeReturn
ConfusingTernary
IfStmtsMustUseBraces
SimplifyBooleanReturns
UseLocaleWithCaseConversions
MisleadingVariableName
UnusedImports
AvoidUsingShortType
DuplicateImports
AppendCharacterWithChar
ImportFromSamePackage
SingletonClassReturningNewInstance
DoNotThrowExceptionInFinally
AvoidCatchingNPE
ImportFromSamePackage
PositionLiteralsFirstInCaseInsensitiveComparisons
TooManyStaticImports

In Table IV, only two violations—emphasized in boldface—have middle or high-level priorities in both of the authoringtypes: “UseProperClassLoader” in Elasticsearch and “ImportFromSamePackage” in JabRef. The former violation is a recommendation to replace the invocation of getClassLoarder()with Thread.currentThread().getContextClassLoader() because
the original code might not work properly in the J2EE environment. The latter violation is a warning that there is noneed to import classes within the same package. Since theformer violation seems to be related to a potential fault andnot to a programmer’s preference, it is natural that the violation
was fixed regardless of the authorship. On the other hand, thelatter violation would be on the way of coding and have alittle or no relation with a fault. Hence, making the violation
totally depends on who writes/maintains the code: While“ImportFromSamePackage” has also a high-level priority inthe single-authored files of Hibernate, it does not appear in
the multi-authored ones of the same project.
In order to examine further correspondence relationships
between the sets of violations warned in single-authoredfiles and in multi-authored ones, we compared their IPA
values which are original data to decide the priority levelsof violations—low, middle and high. For each project, we
computed the Spearman rank correlation coefficient between
the sets of IPA values corresponding to violations warned in
the single-authored files and in the multi-authored ones. Table
V shows the results; Notice that those correlation coefficientsare computed by using only IPA values of violations which
are common to both the set of single-authored files and that ofPriority
Single-AuthoredMulti-Authored
Low
Middle
—
High
Low
High
High
Low
High
Low
—
Middle—MiddleHigh
Middle
—
High
—
High
—
Middle—High—
Middle
High
Low
High
—
High
Low
High
Low
—
Middle—Middle
—
High
—
High
High
Low
High
High
High
Low
—
High
High
Low
High
—
High
Low
High
Low

TABLE V: Spearman rank correlation coefficients between theset of single-authored files and that of multi-authored ones interms of IPA value.
Project
Guava
Elasticsearch
Spring Framework
React Native
JabRefJUnit4Hibernate

Correlation Coefficient
0.492
0.339
0.433
0.127
0.160
0.000
0.344

multi-authored ones. In Table V, no strong correlation between
IPA values is observed in our data. That is to say, the priority—
the degree of attention paid by programmer—of a violation
appearing in single-authored files tends to be independent of
the priority in multi-authored ones, even when we focus only
on the common violations.
From the all results shown in this subsection, we can answer
to RQ1 as: the difference in the authoring type has significant
impacts on the trends of violations and their evaluations.
D. Analysis 2 (for RQ2): Comparison of Violations across
Projects
In the previous subsection, we have analyzed violations
by focusing on the difference in the authoring style. Now
we introduce another perspective of analysis: the comparison
across the projects.
For violations appearing in single-authored files, we computed similarities among projects as well. Table VI shows theTABLE VI: Similarities among projects in terms of the set of violations appearing in single-authored files.
Project(a) Guava(b) Elasticsearch(c) Spring Framework(d) React Native(e) JabRef(f) JUnit4(g) Hibernate

(a)
—
0.606
0.514
0.403
0.333
0.096
0.573

(b)
0.606
—
0.638
0.449
0.375
0.098
0.652

(c)
0.514
0.638
—
0.443
0.445
0.118
0.646

(d)
0.403
0.449
0.443
—
0.432
0.200
0.462

(e)
0.333
0.375
0.445
0.432
—
0.176
0.432

(f)
0.096
0.098
0.118
0.200
0.176
—
0.114

(g)
0.573
0.652
0.646
0.462
0.432
0.114
—

TABLE VII: Similarities among projects in terms of the set of violations appearing in multi-authored files.
(a)
—
0.673
0.657
0.599
0.650
0.533
0.665

(b)
0.673
—
0.783
0.575
0.735
0.529
0.817

results. The average of similarities (excluding the ones withthemselves) is 0.342. Thus, about 30–40% of violations seemto be common with other projects. Since (f) JUnit4 has lower
similarities with the others, it might have a special trend of
violations, caused by a particular author.
In a similar fashion, we computed similarities among
projects for violations appearing in multi-authored files. Table
VII presents the results. The average of similarities is 0.634:
about 60–70% of violations are common to other projects.
By comparing Tables VI and VII, the commonality of violations appearing in the multi-authored files is about 1.85 times
higher (on average) than the single-authored ones. Indeed, forall pairs of projects, similarities in multi-authored files arehigher than the ones in single-authored ones—“Table VI <Table VII”; for example, pair (a)-(b): 0.606 < 0.673, pair(b)-(c): 0.638 < 0.783, pair (c)-(d): 0.443 < 0.543, and soon. Trends of appearing violations are possibly generalized
through maintenances by two or more programmers.
Next, we examined which violations are common acrossprojects. Table VIII and Fig. 1 presents the numbers ofcommon violations across projects; Table VIII also shows
the numbers of violations corresponding to middle or highlevel priorities as the numbers enclosed in parentheses: forexample, 25 violations appearing in single-authored files arecommon to 6 projects, and 2 out of 25 violations have middle
or high-level priorities2 . In Table VIII, the maximum countof violations warned in single-authored files is at column “1,”thus, most violations appeared in a particular project only. On

(c)
0.657
0.783
—
0.543
0.742
0.523
0.833

(d)
0.599
0.575
0.543
—
0.547
0.517
0.545

(e)
0.650
0.735
0.742
0.547
—
0.536
0.777

(f)
0.533
0.529
0.524
0.517
0.536
—
0.526

(g)
0.665
0.817
0.833
0.545
0.777
0.526
—

the other hand, the maximum count of violations warned in
multi-authored files is at opposite side “7,” which mean thatmost violations are common to all projects. From these results,
we can say that: more project-specific violations tend to appear
in single-authored files, and more common violations do in
multi-authored files.
In multi-authored files, 67 (= 71−4) violations are common
to all projects but they have low-level priorities (see Table
VIII). That is to say, while those 67 violations must be popular,
all of them have been disregarded by many programmers.
Figure 2 presents the list of those 67 violations. They correspond to about 30% of all violations. In other words, about
30% of automatically-warned violations might be worthlessfor many programmers. On the other hand, we did not findany violations having middle or high-level priorities, which
are common to three or more projects3 . These results would
mean that critical violations vary from project to project.
Therefore, we can answer to RQ2 as: while importantviolations tend to vary from project to project and fromperson to person, about 30% of violations would be commonly
worthless across projects for many programmers. Thus, weshould prepare a proper rule set of violations in accordancewith the domain and organization of the project. It seems
to dovetail with the previous work saying the importance ofcustomization (flexibility) in static code analysis tools [3], [6].
type

multi
single60# of violations

Project(a) Guava(b) Elasticsearch(c) Spring Framework(d) React Native(e) JabRef(f) JUnit4(g) Hibernate

40
20

TABLE VIII: Number of common violations across projects
and of ones corresponding to middle or high-level priorities.
Authorship
Single
Multi

1
53(0)
33(2)

2
24(3)
19(1)

# of Appearing Projects
34528(2) 33(1) 26(2)24(2) 20(0) 32(4)2 It corresponds to “Single” row, “6” column.

0
1

2

3
4
5
# of appearing projects

67

Fig. 1: Number of common violations across projects.
6
25(2)
35(3)

7
12(0)
71(4)

3 Although Table VIII shows that 4 violations correspond to middle or highlevel priorities, it just means that these violations are “not common low-level(disregarded)” ones. In other words, these 4 violations are not commonlyregarded ones for all projects while one of them has a middle or high-level
priority at only one or two out of seven projects.

AbstractNaming, AccessorClassGeneration, AppendCharacterWithChar,
ArrayIsStoredDirectly, AssignmentInOperand, AtLeastOneConstructor,
AvoidCatchingGenericException, AvoidCatchingThrowable, AvoidDuplicateLiterals,
AvoidFieldNameMatchingMethodName, AvoidInstantiatingObjectsInLoops,
AvoidLiteralsInIfCondition, AvoidReassigningParameters,
AvoidSynchronizedAtMethodLevel, AvoidThrowingRawExceptionTypes,
AvoidUsingVolatile, BeanMembersShouldSerialize, BooleanGetMethodName,
CallSuperInConstructor, ClassWithOnlyPrivateConstructorsShouldBeFinal,
CommentDefaultAccessModifier, CommentRequired, CommentSize,
CompareObjectsWithEquals, ConfusingTernary, ConsecutiveLiteralAppends,
ConstructorCallsOverridableMethod, CyclomaticComplexity,
DataflowAnomalyAnalysis, DefaultPackage, DoNotUseThreads, EmptyCatchBlock,
EmptyMethodInAbstractClassShouldBeAbstract, ExcessiveImports,
ExcessivePublicCount, FieldDeclarationsShouldBeAtStartOfClass, GodClass,
ImmutableField, InefficientStringBuffering, InsufficientStringBufferDeclaration,
LawOfDemeter, LocalVariableCouldBeFinal, LongVariable, LooseCoupling,
MethodArgumentCouldBeFinal, ModifiedCyclomaticComplexity, NullAssignment,
OnlyOneReturn, PositionLiteralsFirstInComparisons, PreserveStackTrace,
RedundantFieldInitializer, ShortMethodName, ShortVariable,
SignatureDeclareThrowsException, SimplifyBooleanReturns,
StdCyclomaticComplexity, TooManyMethods, UncommentedEmptyConstructor,
UncommentedEmptyMethodBody, UnnecessaryFullyQualifiedName,
UnusedModifier, UseCollectionIsEmpty, UseConcurrentHashMap, UseUtilityClass,
UseVarargs, UselessParentheses, VariableNamingConventions

Fig. 2: Commonly-disregarded violations.

E. Threats to Validity
We heavily rely our data collection on Github repositories. It
may be a threat to validity in regard to a bias of data. Although
we mitigated the threat by selecting projects randomly, we
should perform a wider data collection and an analysis in orderto show a high-level generality of our results.
We examined Java source code only due to our tool (PMD)
limitation. There might be language-specific trends in our
results. Since we have just categorized violations and analyzed
their trends from a statistical perspective, we would like toexamine qualitative aspects of them in the future.
While we examined code changes in repositories, we are notsure whether the programmers used a static code analysis tool
or not during their programming activities. Thus, our results
might not be well-matched with the programmers’ real trends
of regarding/disregarding violations. Although our method is
one of available ways to observe programmers’ practices, wewould need to validate our data and results in the future.
IV. R ELATED W ORK
Spacco et al. [7] exploited a fuzzy algorithm to determine
commonalities among violations. Lee et al. [8] analyzed how
the readability of code is affected by coding violations. While
their studies are useful in detecting important or disregarded
violations, they missed change history of violations over time.
Kim et al. [9] focused on the lifetime of warning (violation)and used it for their prioritization. Their focus are similar
to our study. However, they did not consider the trends ofviolation changes: change patterns. Even if a violation has
a long lifetime, there is a significant difference between
a decreasing trend and an increasing one in terms of its
importance. Our work utilizes the change patterns of violations
through real code modifications and used metric “IPA” as aconnection between human factors (programmers’ attentions)and violation trends. Then, we have discussed an influence ofdifference in the style of authoring source files.

V. C ONCLUSION AND F UTURE W ORK
In this paper, we focused on the authorship of source files,
and considered two authoring types: single-authored files andmulti-authored ones. The trends of coding violations warned insingle-authored files might be influenced by the programmer’s
preference, then there may be a significant difference inevaluating violations. Thus, we examined the impacts of theauthoring type on evaluations of coding violations.
We collected violations warned by a popular analysis tool,
PMD, from seven OSS projects. Then, we analyzed the trendsof violations and their evaluations, by comparing the sets ofdata from single-authored files and from the multi-authoredones. From the results of analyses, we obtained the following
findings: (1) the difference in the authoring type has significant
impacts on the trends of violations and their evaluations; (2)while important violations tend to vary from project to project
and from person to person, about 30% of violations would becommonly worthless across projects for many programmers.
Hence, it is important to prepare an appropriate rule set
for the domain and organization of the target project whileconsidering the authorship of code, in order to utilize static
code analysis tools. Since the difference in programmers’
preferences may also cause the diversity of violations, weneed to focus on not only the number of developers but also
individual developers in the future. Our future work includes:(1) a further analysis with more data of not only Java but also
other language; (2) a more detailed analysis focusing on eachprogrammer and his/her trend of making violations.
ACKNOWLEDGMENT
This work was supported by JSPS KAKENSHI Grant Number 16K00099 and DIKTI Scholarships, Directorate Generaleof higher Education of Indonesia. The authors would like tothank the anonymous reviewers for their valuable comments.
R EFERENCES[1] M. E. Fagan, “Advances in software inspections,” IEEE Trans. Softw.
Eng., vol. SE-12, no. 7, pp. 744–751, July 1986.
[2] B. Johnson, Y. Song, E. Murphy-Hill, and R. Bowdidge, “Why don’t
software developers use static analysis tools to find bugs?” in Proc. 2013
Int’l Conf. Softw. Eng., May 2013, pp. 672–681.
[3] H. Shen, J. Fang, and J. Zhao, “Efindbugs: Effective error ranking forfindbugs,” in Proc. the 2011 Fourth IEEE Int’l Conf. Softw. Testing,
Verification and Validation, Mar. 2011, pp. 299–308.
[4] A. E. Burhandenny, H. Aman, and M. Kawahara, “Examination of coding
violations focusing on their change patterns over releases,” in Proc. 23rd
Asia-Pacific Softw. Eng. Conf., Dec. 2016, pp. 121–128.
[5] C. Bird, A. Gourley, P. Devanbu, M. Gertz, and A. Swaminathan, “Mining
email social networks,” in Proc. 2006 Int’l Workshop on Mining Softw.
Repositories, May 2006, pp. 137–143.
[6] C. Boogerd and L. Moonen, “Assessing the value of coding standards:
An empirical study,” in Proc. IEEE Int’l Conf. Softw. Maintenance, Sept.
2008, pp. 277–286.
[7] J. Spacco, D. Hovemeyer, and W. Pugh, “Tracking defect warnings acrossversions,” in Proc. 2006 Int’l Workshop on Mining Softw. Repositories,
May 2006, pp. 133–136.
[8] T. Lee, J. B. Lee, and H. P. In, “A study of different coding styles affectingcode readability,” Int’l J. Softw. Eng. & Its App., vol. 7, no. 5, pp. 413–
422, 2013.
[9] S. Kim and M. D. Ernst, “Which warnings should i fix first?” in Proc.
6th Joint Meeting European Softw. Eng. Conf. & ACM SIGSOFT Symp.
Foundations Softw. Eng., 2007, pp. 45–54.