Investigation of Coding Patterns over Version History
Hironori Date, Takashi Ishio, Katsuro Inoue
Graduate School of Information Science and Technology, Osaka University
1-5, Yamadaoka, Suita, Osaka 565-0871, Japan
Email: {h-date, ishio, inoue}@ist.osaka-u.ac.jp

Abstract—A coding pattern is a sequence of method calls
and control structures, which appears repeatedly in the sourcecode. In this paper, we have extracted coding patterns of eachversion of two Java applications, and then explored the lifespan of all of the coding patterns across those versions. This
paper reports the characteristics of coding patterns of various
life-spans. While learning from coding patterns enables us toperform appropriate modiﬁcations and enhancements for thesoftware, many coding patterns are unstable as similar to theresult of clone genealogy research.
Keywords-Repository Mining; Coding Pattern; Sequential
Pattern Mining; Java;

I. I NTRODUCTION
A coding pattern is a frequent sequence of method calls
and control statements to implement a particular kind of concerns that are not modularized in the software [1]. Coding
patterns include API usage patterns and application-speciﬁcbehavior patterns. For example, a method call hasNext
followed by a method call next is a typical usage of an
Iterator object in Java. In addition to many instancesof such API usage patterns, a large-scale application often
includes its own coding patterns. For example, Apache Tomcat 6.0.14 has a logging feature for debugging. The feature
is implemented by 304 pairs of isDebugEnabled anddebug method calls. Azureus 3.0.2.2 is a multi-threaded
program; it includes 151 methods using AEMonitor classto synchronize multi-threaded execution. A text editor jEdit
4.3 often calls isEditable with an if statement so thatthe text editor can prevent users from modifying a read-onlyﬁle. Since coding patterns reﬂect implicit rules in a program,knowledge of patterns helps developers understand source
code, and detect potential defects in the program [2], [3],[4].
Our research group developed a Coding Pattern Mining
Tool named Fung, and in the previous research [1] wemined coding patterns from several applications. Figure
1 shows an example of coding pattern extracted from
JHotDraw. From two class deﬁnitions, we obtain a coding
pattern for “Undo” with length 4 and support (instance)
2, createUndoActivity(), setUndoActivity(), getUndoActivity(), setAffectedFigures(). This means that the four method
calls appear in those two classes in such order.
While existing work [5], [6], [7] used patterns extracted
from source code as useful source code fragments, some

Subclasses of AbstractCommandorg.jhotdraw.standard.DuplicateCommand
public void execute() {super.execute();setUndoActivity(createUndoActivity());
FigureSelection selection = view().get...
//create duplicate figure(s)FigureEnumeration figures = (Figure...
getUndoActivity().
setAffectedFigures(figures);view().clearSelection();}Subclasses of AbstractHandle

instanceoforg.jhotdraw.standard.ResizeHandle
public void invokeStart(
int x, int y,
DrawingView view) {setUndoActivity(
createUndoActivity(view));
getUndoActivity().
setAffectedFigures(...
((RseizeHandle.Undo...
}Figure 1.

Undo Pattern(length=4)
createUndoActivity()
setUndoActivity()
getUndoActivity()
setAffectedFigures()Undo pattern in JHotDraw 5.4b1 [1]patterns may be involved only in a particular version ofsource code. If a pattern appears in multiple versions, thestable pattern is likely more reusable; in addition, the knowledge about such stable patterns may be effective for sourcecode reading tasks. However, a long pattern of method calls
always implies many shorter patterns of method calls. It isdifﬁcult to manually select likely stable patterns from thesimilar patterns.
In this research, we have investigated how many versionsof an application include the same pattern, as similar to
Clone Genealogy [8], [9]. Our pattern mining tool uses
PreﬁxSpan, a sequential pattern mining algorithm [10]. Eachcoding pattern is a sequence of method calls and control
elements such as if, while and try-catch. A patternsurvives until the sequential order of method calls andcontrol elements are modiﬁed.
We have applied our pattern mining to each version of
two applications, dnsjava and JmDNS. We have chosen these
middle-size applications so that we can extract all possible

patterns which have at least two instances and comprise atleast two elements. In other words, if two methods include
the same two method calls in the same order, we recognize
the method calls as one of the shortest patterns. If the pairof method calls are not modiﬁed across versions, the patternis recognized as a stable pattern.
We have analyzed 51 versions of dnsjava and 20 versionsof JmDNS. Our results show that many patterns disappear
in a few versions. Although we have extracted 25,909
patterns in source code, only 35 patterns are found in the allversions of an application. While the generalizability of ourinvestigation is limited since we could not detect renamed
methods, the result indicated that coding patterns should be
extracted from a number of latest versions.
II. C ODING PATTERN M INING
The mining process of coding pattern we use here comprises two steps: normalization step and mining step. The
normalization step translates each Java method, constructor
or initializer in a program into a single sequence of callelements and control elements.
A method call is translated into a method call elementwith the method name and argument list. A constructor callis also translated into a constructor call element with the
package name, class name and argument list.
The control elements are taken by the normalization rules
shown in Table I. Some of these rules come from ourprevious work [1], but we have extended them by including additional control elements, try-catch-finally andsynchronized, to enrich coding patterns.
In the mining step, we use a sequential pattern mining
algorithm named PreﬁxSpan[10]. Sequential pattern mining
extracts frequent subsequences from a set of sequences.
Fung extracts only closed patterns; in other words, Fungﬁlters out redundant shorter subpatterns whose instances arecompletely covered by the instances of a longer pattern.
III. R ESEARCH Q UESTION
Our research question for the investigation of the life-spanof the coding patterns is as follows.
RQ: Are the coding patterns generally stable over theversion history?
In our previous paper, we have investigated the coding
patterns in a single version of a software system [1]. In thiswork, we will trace the coding patterns through multiple
versions of the software system. We would like to know if
the coding patterns are fragile in the sense that a patternfound in a version can be easily disappear in the later
versions. Or the patterns are fairly stable in the later versions.
If a pattern might be fragile, we would think that thepattern is temporary one, so we should not reuse the patternin other systems. If it is stable, the pattern would be an
important one to the later reuse for efﬁcient and reliable
coding.

Table IN ORMALIZATION RULES OF CONTROL ELEMENTS
SourceSequence
SourceSequence
SourceSequence
SourceSequence
SourceSequence
SourceSequence
SourceSequence
SourceSequence
SourceSequence
SourceSequencefor (<init>; <cond>; <inc>) <body><init>, <cond>, LOOP, <body>, <inc>, <cond>,
END-LOOP
for ( : <init>) <body><init>, LOOP, <body>, END-LOOP
while (<cond>) <body><cond>, LOOP, <body>, <cond>, END-LOOP
do <body> while (<body>)
LOOP, <body>, <cond>, END-LOOP
if (<cond>) <then> else <else><cond>, IF, <then>, ELSE, <else>, END-IF<cond> ? <then> : <else><cond>, IF, <then>, ELSE, <else>, END-IF
try <try> catch ( ) <catch> ... ﬁnally <ﬁnally>
TRY, <try>, CATCH, <catch>, ..., FINALLY,<ﬁnally>, END-TRY
synchronized(<exp>) <body><exp>, SYNCHRONIZED, <body>,
END-SYNCHRONIZEDsynchronized return-type method-name(args) <body>SYNCHRONIZED, <body>, END-SYNCHRONIZED
throw <exp><exp>, THROW
Table IITARGET PROGRAMSApplication
dnsjava
JmDNS

Version Range
0.1 to 2.0.1
0.2 to 3.4.1#Version
51
20#Pattern
17,284
8,625

IV. OVERVIEW OF E XPERIMENTS
To answer the research question, we have extracted coding
patterns over multiple versions. We have mined for patterns
from each single version individually, and then we havesearched identical patterns in multiple versions. Two coding
patterns are judged as identical if all the elements of thepatterns are identical. It is necessary to check not only
consecutive two versions but all pairs of arbitrary two
versions, since the identical patterns may be found at nonconsecutive two versions. For example, a pattern extracted
in version 1 can temporarily disappear from version 2, andappear in version 3 again.
We deﬁne the life-span of a pattern as the number ofversions where we ﬁnd the identical pattern. For example,
if a pattern is found in the version 1, 2 and 3, then its lifespan is 3. If a pattern is found in the version 1 and 3 but
not in 2, then its life-span is 2.
Fung takes two parameters: the minimum length of apattern and the minimum number of occurrences (instances)of a pattern. We have extracted patterns which comprise atleast 2 method calls and appear in at least 2 methods. We
have chosen these values so that we can extract all possible
patterns. If we extract only patterns which have at least 10
instances, we cannot distinguish a pattern which still have
9 instances (but not reported by Fung) and a completely
deleted pattern.

ϱϬϬϬ

ϯϱϬϬϬ
ϯϬϬϬϬ

ϰϬϬϬ

ϮϱϬϬϬ
ϮϬϬϬϬ

ϯϬϬϬ

ϭϱϬϬϬ

ϮϬϬϬ

ϭϬϬϬϬ

>K
ηWĂƚƚĞƌŶ

ϭϬϬϬ

ϱϬϬϬ

Ϭ

Ϭ͘ϭ
Ϭ͘Ϯ
Ϭ͘ϯ
Ϭ͘ϰ
Ϭ͘ϱ
Ϭ͘ϲ
Ϭ͘ϳ
Ϭ͘ϴ
Ϭ͘ϴ͘ϭ
Ϭ͘ϴ͘Ϯ
Ϭ͘ϴ͘ϯ
Ϭ͘ϵ
Ϭ͘ϵ͘ϭ
Ϭ͘ϵ͘Ϯ
Ϭ͘ϵ͘ϯ
Ϭ͘ϵ͘ϰ
Ϭ͘ϵ͘ϱ
ϭ͘Ϭ
ϭ͘Ϭ͘ϭ
ϭ͘Ϭ͘Ϯ
ϭ͘ϭ
ϭ͘ϭ͘ϭ
ϭ͘ϭ͘Ϯ
ϭ͘ϭ͘ϯ
ϭ͘ϭ͘ϰ
ϭ͘ϭ͘ϱ
ϭ͘ϭ͘ϲ
ϭ͘Ϯ͘Ϭ
ϭ͘Ϯ͘ϭ
ϭ͘Ϯ͘Ϯ
ϭ͘Ϯ͘ϯ
ϭ͘Ϯ͘ϰ
ϭ͘ϯ͘Ϭ
ϭ͘ϯ͘ϭ
ϭ͘ϯ͘Ϯ
ϭ͘ϯ͘ϯ
ϭ͘ϰ͘Ϭ
ϭ͘ϰ͘ϭ
ϭ͘ϰ͘Ϯ
ϭ͘ϰ͘ϯ
ϭ͘ϱ͘Ϭ
ϭ͘ϱ͘ϭ
ϭ͘ϱ͘Ϯ
ϭ͘ϲ͘ϭ
ϭ͘ϲ͘Ϯ
ϭ͘ϲ͘ϯ
ϭ͘ϲ͘ϰ
ϭ͘ϲ͘ϱ
ϭ͘ϲ͘ϲ
Ϯ͘Ϭ͘Ϭ
Ϯ͘Ϭ͘ϭ

Ϭ

Figure 2.

LOC and the number of patterns of dnsjavaϱϬϬϬ ϰϵϮϵ

ϮϱϬϬ

ϭϴϬϬϬ

ϰϱϬϬ

ϭϲϬϬϬ
ϮϬϬϬ

ϭϰϬϬϬ
ϭϮϬϬϬ

ϰϬϬϬ
ϯϰϮϮ

ϯϱϬϬ

ϭϱϬϬ

ϭϬϬϬϬ

ϯϬϬϬ

ϴϬϬϬ

ϭϬϬϬ

ϲϬϬϬ
ϰϬϬϬ

>K
ηWĂƚƚĞƌŶ

ϮϱϬϬ
ϮϬϬϬ

ϱϬϬ

ϭϱϵϭ

ϮϬϬϬ

ϭϱϬϬ
ϭϭϲϳ

Ϭ

ϭϬϬϬ

Ϭ͘Ϯ
ϭ͘Ϭ͘Zϭϭ͘Ϭ͘ZϮϭ͘ϬͲ&ŝŶĂů
Ϯ͘Ϭ
Ϯ͘ϭ
ϯ͘Ϭ
ϯ͘ϭ
ϯ͘ϭ͘Ϯ
ϯ͘ϭ͘ϯ
ϯ͘ϭ͘ϰ
ϯ͘ϭ͘ϱ
ϯ͘ϭ͘ϲ
ϯ͘ϭ͘ϳ
ϯ͘ϭ͘ϴ
ϯ͘Ϯ͘Ϭ
ϯ͘Ϯ͘ϭ
ϯ͘Ϯ͘Ϯ
ϯ͘ϰ͘Ϭ
ϯ͘ϰ͘ϭ

Ϭ

ϳϴϮ

ϳϵϰ
ϲϰϳ

ϰϲϳ

ϱϬϬ

ϰϱϰ
ϰϬϯ
ϯϳϳ ϯϮϬϯϭϯϮϳϯϮϮϴϭϯϲ ϭϰϵϭϯϰϭϮϭϬϰϴ ϰϯ ϱϭ Ϯϵ ϰϰ Ϯϲ Ϯϱ ϯϬ ϯϵ Ϯϱ ϭϵ Ϯϰ ϮϬ ϭϯ ϭϲ ϭϰ ϭϯ ϱ ϲ ϱ ϴ ϯ ϭϬ ϳ Ϯϭ ϴ ϭ ϭ ϰ ϱ Ϭ ϭϰϭ Ϯ ϯ ϰ ϱ ϲ ϳ ϴ ϵ ϭϬ ϭϭ ϭϮ ϭϯ ϭϰ ϭϱ ϭϲ ϭϳ ϭϴ ϭϵ ϮϬ Ϯϭ ϮϮ Ϯϯ Ϯϰ Ϯϱ Ϯϲ Ϯϳ Ϯϴ Ϯϵ ϯϬ ϯϭ ϯϮ ϯϯ ϯϰ ϯϱ ϯϲ ϯϳ ϯϴ ϯϵ ϰϬ ϰϭ ϰϮ ϰϯ ϰϰ ϰϱ ϰϲ ϰϳ ϰϴ ϰϵ ϱϬ ϱϭ

Figure 3.

Figure 4.

LOC and the number of patterns of JmDNS

Life-span of patterns in dnsjava

ϮϱϬϬ

1

We have analyzed two open source systems, dnsjava and
JmDNS2 . Table II shows the target versions we have used in
the experiments. Also it shows the number of patterns foundby Fung.
V. R ESULT OF E XPERIMENTS

Ϯϭϱϯ

ϮϮϰϰ

ϮϬϬϬ
ϭϱϯϭ
ϭϱϬϬ

ϭϬϬϬ

ϴϳϬ

A. Life-Span and Pattern Length
Figure 2 and Figure 3 show LOC (Lines Of Code) and thenumber of patterns extracted in each version of dnsjava and
JmDNS. We can easily recognize that LOC grows over theversions, and that the number of pattern mostly grows along
the LOC growth with minor decreases. We have investigatedthe correlation between LOC and the number of patterns.
As a result, the correlation coefﬁcients become 0.912 on
dnsjava and 0.721 on JmDNS. Thus there is a strong positive
correlation between LOC and the number of patterns.
Figure 4 presents the frequency distribution of the lifespan in dnsjava, and Figure 5 in JmDNS. The life-span ofpatterns mined in dnsjava range from 1 to 51, and that in
JmDNS range from 1 to 20. The most frequent life-span is
1 in dnsjava and 2 in JmDNS.
Figure 6 indicates that the frequency of pattern length andlife-span in dnsjava, and Figure 7 indicates that in JmDNS.
The range of pattern length is 2 to 45 in dnsjava, and 2
to 79 in JmDNS. In dnsjava, the peak 425 appears at 2 in
1 dnsjava, http://sourceforge.net/projects/dnsjava/
2 JmDNS, http://sourceforge.net/projects/jmdns/

ϰϭϱ ϰϮϲ

ϱϬϬ

ϯϱϳ
ϭϴϴ
ϱϬ

ϲϱ

ϰϲ

ϰϭ

ϴϰ

ϭϬ

ϭϭ

ϭϮ

ϭϯ

Ϭ
ϭ

Ϯ

ϯ

ϰ

ϱ

ϲ

Figure 5.

ϳ

ϴ

ϵ

ϮϮ

ϭϲ

ϰϯ

ϵ

Ϯ

ϰϮ

Ϯϭ

ϭϰ

ϭϱ

ϭϲ

ϭϳ

ϭϴ

ϭϵ

ϮϬ

Life-span of patterns in JmDNS

life-span and 2 in pattern length. In JmDNS, the peak 204
appears at 2 in life-span and 6 in pattern length. In JmDNS,
compared to dnsjava, there exist patterns including many
elements. In both cases, there are a few long-lived patterns
including many elements.
B. Examples of Patterns
You can see the complete list of the patterns which appear
in all versions of dnsjava in Table III and JmDNS in Table
IV. There are only 14 patterns out of total 17,284 patterns
in dnsjava, and 21 patterns out of total 8,625 patterns in
JmDNS. As the number of instances of a pattern differs
depending on software versions, we show the minimum andmaximum values, and the values in the ﬁrst and the last

version. Characteristics of these patterns with the longest
life-span are as follows.
••

VI. O BSERVATIONS
We answer to the following research question.
RQ: Are the coding patterns generally stable over theversion history?
A: No, the coding patterns are NOT generally stable over

Most patterns are related to the usage of Java library.
Pattern length tends to be short.

ϰϱϬ
ϰϬϬ
ϯϱϬ
ϯϬϬ
ϮϱϬ
ϮϬϬ
ϭϱϬ
Ϯ
ϳ
ϭϮ
ϭϳ
ϮϮ
Ϯϳ
ϯϮ

ϭϬϬ
ϱϬ
Ϭ

ϭ

ϯ

ϱ

ϳ

ϵ ϭϭ ϭϯϭϱ ϭϳϭϵ Ϯϭ ϮϯFigure 6.

Ϯϱ Ϯϳ Ϯϵϯϭ ϯϯ ϯϱϯϳ ϯϵ ϰϭ
ϰϯ ϰϱ
ϰϳ ϰϵ
ϱϭ

ϯϳ
ϰϮ

Pattern length and life-span in dnsjava

ϮϬϬ

ϭϱϬ

ϭϬϬ

ϱϬ

Ϭ
ϭ ϯ
ϱ ϳ
ϵ ϭϭ
ϭϯ ϭϱ

ϭϳ ϭϵ ϳϴϳϰ

Figure 7.

ϳϬ

ϲϲ

ϲϮ

ϱϴ

ϱϰ

ϱϬ

ϰϲ

ϰϮ

Pattern length and life-span in JmDNS

ϯϴ

ϯϰ

ϯϬ

Ϯϲ

ϮϮ

ϭϴ

ϭϰ ϭϬ

ϲ Ϯ

Table III
PATTERNS WHICH APPEARS IN ALL VERSIONS OF DNSJAVA
Len.
2
2
2
3
3
3
3
3
3
3
4
4
5
5

Min. Max.
2
6
3
8
5
7
3
11
3
23
3
4
2
4
5
18
7
13
6
11
5
12
4
8
4
10
3
6

#Instance
Ver. 0.1 Ver. 2.0.1
2
5
3
7
5
5
3
11
3
23
3
3
3
4
5
7
7
12
8
9
5
7
7
6
4
6
5
5

PatterngetHeader(), getRcode()
getHeader(), getName()
java.io.InputStreamReader.<init>(java.io.InputStream), java.io.BufferedReader.<init>(java.io.Reader)
LOOP, equals(java.lang.Object), END-LOOPLOOP, get(int), END-LOOPLOOP, getCount(int), END-LOOPLOOP, startsWith(java.lang.String), END-LOOPhasMoreTokens(), nextToken(), hasMoreTokens()
LOOP, charAt(int), END-LOOPLOOP, length(), END-LOOPLOOP, nextToken(), hasMoreTokens(), END-LOOP
length(), LOOP, length(), END-LOOPhasMoreTokens(), LOOP, nextToken(), hasMoreTokens(), END-LOOP
length(), LOOP, charAt(int), length(), END-LOOP
Table IVPATTERNS WHICH APPEARS IN ALL VERSIONS OF J M DNS

Len.
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
3
4
4
7
9

#Instance
Min. Max. Ver. 0.2 Ver. 3.4.1
2
2
2
2
2
2
2
2
2
5
2
3
2
3
3
2
3
15
3
12
3
4
4
3
2
33
2
33
2
14
2
14
2
5
2
5
2
12
2
9
2
13
2
13
2
2
2
2
3
3
3
3
3
4
3
4
3
12
4
5
2
11
4
10
4
9
4
7
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2

PatterncharAt(int), writeByte(int)
parseInt(java.lang.String), registerService(javax.jmdns.ServiceInfo)
toLowerCase(), remove(java.lang.Object)
substring(int, int), parseInt(java.lang.String)
toLowerCase(), get(java.lang.Object)
getAddress(), getPort()
TRY, close(), END-TRYLOOP, get(java.lang.Object), END-LOOPLOOP, put(K, V), END-LOOPIF, equals(java.lang.Object), END-IF
IF, get(java.lang.Object), END-IFisQuery(), getAddress(), getPort()
LOOP, charAt(int), END-LOOPLOOP, writeByte(int), END-LOOPSYNCHRONIZED, get(java.lang.Object), END-SYNCHRONIZEDIF, length(), END-IF
IF, put(K, V), END-IFSYNCHRONIZED, getProperties(), get(java.lang.Object), END-SYNCHRONIZEDLOOP, length(), startsWith(java.lang.String), END-LOOPIF, write(int), ELSE, write(int), ELSE, write(int), END-IF
LOOP, IF, write(int), ELSE, IF, write(int), END-IF, END-IF, END-LOOP

the version history.
As described in Section V, there are few coding patterns
with long life-span. On the other hand, coding patterns withshort life-span account for a large part of all patterns.
According to Figure 4 and Figure 5, most patterns live
very short in the history, and there are few patterns appearing
in all versions. The total of the patterns living through lessthan 15 versions is 90% of all dnsjava’s patterns, and the
median life-span is 3. Similarly, the total of the patterns
living through less than 8 versions covers 90% of all in
JmDNS patterns, and the median is 2.
Our results on coding patterns are consistent with theresult of code clone genealogy research [8]. Many code
clones also disappear in a few versions, and code clones
including method calls imply coding patterns. Some disappeared coding patterns are affected by code cloning activityof developers.

VII. T HREATS TO VALIDITY
A. Experimental Objects
We chose 2 as the threshold of the minimum occurrenceof a pattern so that we can extract all possible patterns inpattern mining process. As pattern mining under this severe
condition consumes huge time, we cannot adopt large size of
applications as targets of experiments. An effective solution
to this limitation is the reimplementation of Fung with more
efﬁcient sequential pattern mining algorithm.
As dnsjava and JmDNS have the word “dns” in the namesof the applications, you may think these applications to be
unfair (biased) experimental objects. However, each “dns”
implies different kind of service; dnsjava is an implementation of DNS, while JmDNS is an implementation of multicast DNS used in local networks. The implementations are
not related to each other.

The generality of our ﬁndings is limited since we haveanalyzed only 2 applications. Further experiments with various kinds of software make it clear whether our ﬁndings
are general or not.

ACKNOWLEDGMENT
This research was supported by JSPS KAKENHI Grant
Number 23680001.

B. Change of Method Name

[1] T. Ishio, H. Date, T. Miyake, and K. Inoue, “Mining coding
patterns to detect crosscutting concerns in java programs,”
in Proceedings of the 15th Working Conference on Reverse
Engineering, 2008, pp. 123–132.

In case that a callee method name has changed, we cannot
tie the renamed methods over versions. Thus, we cannot
bind the before and after versions of the patterns which
include the call of the renamed method. As the change ofa method name should imply the change of the contents inthe method body, the meaning of the related patterns maychange. Therefore, there is no need to treat patterns as thesame ones before and after the change of the method name.
C. Verbose Subpatterns
Our pattern tracking algorithm in this paper cannot
track relationships among super/sub-patterns. Suppose thata method has a sequence of method calls A, B, C andanother method has a sequence of method calls A, B, C,
D. Fung recognizes a pattern A, B, C in these methods.
If a developer added a method call D to the former method,
Fung recognizes a new pattern A, B, C, D and ﬁlters out
A, B, C because the shorter pattern is covered by the newpattern. In this case, we regard the pattern A, B, C as adisappeared pattern. We did not track this kind of super/subpatterns because a longer pattern implies a huge number ofpatterns. For example, the pattern A, B, C, D implies four
3-element patterns (A, B, C, A, B, D, A, C, D and B,C, D) and six 2-element patterns (A, B, A, C, A, D,B, C, B, D and C, D). In general, a pattern comprising
N elements implies nearly 2N subpatterns.
According to the limitation, the life-span in this paper
is possibly underestimated. For more detailed investigation,
we should improve the tracking algorithm to deal withsuper/subpatterns.
VIII. C ONCLUSION
In this paper, We investigated the stability of coding
patterns across versions. We deﬁned a life-span of coding
pattern as the number of versions where we ﬁnd the identical
pattern, and investigated the 51 versions of dnsjava and 20
versions of JmDNS.
As a result, many patterns disappear in a few versions.
90% of all dnsjava’s patterns are found in at most 15
versions. The median life-span is 3. Similarly, 90% of all
JmDNS’s patterns are found in at most 8 versions. The
median life-span is 2.
While the generalizability of our investigation is limited
since we could not detect renamed methods and super/sub
patterns, the result indicated that coding patterns should be
extracted from a number of latest versions so that developers
can ﬁlter out temporary patterns.

R EFERENCES[2] T. T. Nguyen, H. A. Nguyen, N. H. Pham, J. M. Al-Kofahi,
and T. N. Nguyen, “Graph-based mining of multiple object
usage patterns,” in Proceedings of the Joint Meeting of the
12th European Software Engineering Conference and the 17th
ACM SIGSOFT Symposium on the Foundations of Software
Engineering, 2009, pp. 383–392.
[3] H. Kagdi, M. Collard, and J. Maletic, “An approach to mining
call-usage patterns with syntactic context,” in Proceedings ofthe 22nd International Conference on Automated Software
Engineering, 2007, pp. 457–460.
[4] Z. Li and Y. Zhou, “PR-Miner: Automatically extracting
implicit programming rules and detecting violations in large
software code.” in Proceedings of the Joint Meeting of the10th European Software Engineering Conference and the 13th
ACM SIGSOFT International Symposium on Foundations ofSoftware Engineering, 2005, pp. 306–315.
[5] M. Acharya, T. Xie, J. Pei, and J. Xu, “Mining API patterns
as partial orders from source code: From usage scenarios to
speciﬁcations,” in Proceedings of the Joint Meeting of the
11th European Software Engineering Conference and the 15th
ACM SIGSOFT Symposium on the Foundations of Software
Engineering, 2007, pp. 25–34.
[6] A. T. Nguyen, T. T. Nguyen, H. A. Nguyen, A. Tamrawi,
H. V. Nguyen, J. Al-Kofahi, and T. N. Nguyen, “Graph-based
pattern-oriented, context-sensitive source code completion,”in Proceedings of the 34th International Conference on Software Engineering, 2012, pp. 69–79.
[7] S. Thummalapenta and T. Xie, “PARSEWeb: A programmer
assistant for reusing open source code on the web,” in Proceedings of the 22nd International Conference on AutomatedSoftware Engineering, 2007, pp. 204–213.
[8] M. Kim, V. Sazawal, D. Notkin, and G. C. Murphy, “Anempirical study of code clone genealogies,” in Proceedings of
the Joint Meeting of the 10th European Software Engineering
Conference and the 13th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2005, pp.
187–196.
[9] N. Bettenburg, W. Shang, W. Ibrahim, B. Adams, Y. Zou, andA. E. Hassan, “An empirical study on inconsistent changes
to code clones at release level,” in Proceedings of the 16th
Working Conference on Reverse Engineering, 2009, pp. 85–
94.
[10] J. Pei, J. Han, B. Mortazavi-Asl, H. Pinto, Q. Chen, U. Dayal,and M. Hsu, “Preﬁxspan: Mining sequential patterns by
preﬁx-projected growth,” in Proceedings of the 17th International Conference on Data Engineering, 2001, pp. 215–224.