Grasping Primitive Enthusiasm

Approaching Primitive Obsession in Steps

Edit Peng

o and P

eter G

Department of Software Engineering, University of Szeged, Dugonics ter 13, 6720, Szeged, Hungary

Keywords:

Code Smells, Primitive Obsession, Primitive Enthusiasm, Static Analysis, Refactoring.

Abstract:

Primitive Obsession is a type of a code smell that has lacked the attention of the research community. Alt-

hough, as a code smell it can be a useful indicator of underlying design problems in the source code, there was

only one previously presented automated detection method. In this paper, the Primitive Obsession is discussed

and multiple variants for Primitive Enthusiasm is deﬁned. Primitive Enthusiasm is a metric designed to high-

light possible Primitive Obsession infected code parts. Additionally other supplemental metrics are presented

to grasp more aspects of Primitive Obsession as well. The current implementation of the described metrics is

for Java and the evaluation was done on three open-source Java systems.

1 INTRODUCTION

During the development the initial structure of the

source code will degrade. It will be more difﬁcult to

identify the original design and understand the code,

therefore later changes and bug ﬁxes will have hig-

her costs. Refactorings, i.e, modiﬁcations that im-

prove different attributes (e.g., readability, complex-

ity, or maintainability) without changing the external

a functionallity (Fowler, 1999), should be applied re-

gularly to preserve the quality of the code.

Several indicators are already known that suggest

the need for refactoring in the code. The 22 code bad

smells listed by Fowler and Beck (Fowler, 1999) can

act as such indicators. Code smells are not actual co-

ding erros, although they are the symptoms of deeper

design problems that might cause trouble in the fu-

ture. Thus, it is not surprising that there is a lot of

discussion within the research community about code

smells, their signiﬁcance and impact on maintenance

costs. Over the years, many new smell types were in-

troduced besides the original 22 and various detection

techniques were recommended for them to help deve-

lopers identify and refactor problems in the code.

Some code smells received much less attention

than the others. Primitive Obsession, that can be va-

guely interpreted as the overuse of primitive data ty-

pes, is one of them. Besides our previous work (G

and Peng

o, 2018), we have found only one work (Ro-

peria, 2009) that suggests an automated detection ap-

proach, whilst most of the research papers consider

this smell on the periphery. Therefore, we have de-

cided to study Primitive Obsession and work out a

novel detection technique for Java programs. Since

its deﬁnition can be broadly interpreted multiple de-

tection criteria were investigated and several metrics

were deﬁned based on them. The introduced metrics

were implemented as parts of a Java static source code

analyser framework. The authors evaluated them on

three open-source Java systems, then manually vali-

dated and compared the results.

The rest of the paper is organised as follows. In

Section 2, the related work is discussed. Section 3 in-

troduces Primitive Obsession through an example and

examines the difﬁculties in its deﬁnition. The pro-

posed detection methods are presented in Section 4,

whilst the results can be found in Section 5. Finally,

the paper is concluded in Section 6.

2 RELATED WORK

Primitive Obsession previously lacked the interest of

the research community. Zhang and his team analy-

sed the state of the art knowledge about code smells

in a systematic literature review (Zhang et al., 2011).

They collected 319 papers from 2000 to 2009, and

examined 39 in detail. In their ﬁrst research ques-

tion, they investigated which code smells attracted the

most research attention. The results showed that Du-

plicated Code smell was discussed the most – in 21

papers out of 39 – whilst many code bad smells re-

Pengõ, E. and Gál, P.

Grasping Primitive Enthusiasm - Approaching Primitive Obsession in Steps.

DOI: 10.5220/0006918803890396

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 389-396

ISBN: 978-989-758-320-9

389

ceived very little attention. Primitive Obsession was

among the unpopular smells having only 5 correspon-

ding papers, although these papers examined all 22

of Fowler’s bad smells. This indicates that Primitive

Obsession was not studied individually in the inves-

tigated period. A more recent systematic literature

review (Gupta et al., 2017) came to a similar conclu-

sion. Gupta et al. examined 60 research papers bet-

ween 1999 and 2016, and found that four of Fowler’s

bad smells – including Primitive Obsession – had no

detection method in any of the papers. A study on

ﬁve known tools which could detect code smells as

well (Fontana et al., 2011) reported that none of them

was capable of ﬁnding Primitive Obsession.

Only one occurrence was found about how to de-

tect Primitive Obsession in the literature (Roperia,

2009). In his thesis, Roperia introduced an automa-

ted bad smell detection tool, named JSmell for Java

programs. He proposed a detection technique for Pri-

mitive Obsession based on the number of primitive

data types declared in a class. If the number of pri-

mitive data types was above than the average for the

whole project and the class was not instantiated JS-

mell reports Primitive Obsession. Unfortunately, we

were unable to get hold of JSmell, therefore no com-

parison or closer study was possible.

antyl

a et al. carried out an empirical study

on the subjective smell evaluations of develo-

pers (M

antyl

a et al., 2004). They found that human

factors (knowledge, work-experience, role in the pro-

ject) have an impact on the identiﬁcation of a code

part as bad smell. Moreover, they compared the re-

sults of the subjective evaluations and metric based

detection techniques for three smells, and found that

the metrics and smell evaluations did not always cor-

relate. One of the smells they used in the compari-

son was the Long Parameter List that had the largest

correlation value. They also observed that the Long

Parameter List smell mainly consisted of primitives,

which could indicate a connection with the Primitive

Obsession smell.

Many papers discuss how good indicators of

maintenance problems are the code smells (Yamashita

and Moonen, 2013; Moonen and Yamashita, 2012).

Although they are not silver bullets for defect pre-

diction code smells, they can still provide valuable in-

sights on some important maintainability factors, es-

pecially when more of them are combined.

3 BACKGROUND

In most programming languages there are two cate-

gories of data types: primitive and complex. Primi-

tive types are the most basic data types provided by

a language, e.g. boolean, integer, char etc. Com-

plex types like classes and structs are the composites

of other existing data types. Complex types have the

advantage that they usually also include some seman-

tic knowledge about the data they represent. Instead

of using scattered functions all over the source code

they let the programmer encapsulate the operations on

the data, which is an important principle of object-

oriented programming. For example, it is a conve-

nient and more readable solution to place three inte-

gers that represent a 3D point into a class instead of

using them separately. However, in the pressure of de-

adlines programmers – especially novice ones – tend

to neglect small, but necessary refactorings. Adding

one or two new method parameters to an already long

parameter list might seem a fast and effortless solu-

tion, although in the long run changes like this will

decrease the maintainability of the source code.

3.1 Deﬁnition of Primitive Obsession

Primitive Obsession is the excessive use of primitive

data types. The programmer does not create small ob-

jects for small tasks, instead s/he is obsessed with the

use of primitive data types. The taxonomy of M

antyl

et al. classiﬁes Primitive Obession as a type of bloa-

ter smell (M

antyl

a et al., 2003), yet it is not really a

bloat, but a symptom for the existence of overgrown,

chaotic code parts.

Figure 1 shows several examples of Primitive Ob-

session. The class constants ENGINEER and SALESMAN

at Lines 3 and 4 can be considered as type codes. Type

codes are a set of integer or string variables that usu-

ally have an understandable name, and they are em-

ployed to simulate types, e.g. different types of em-

ployees. Although they are widely used in projects,

they are a kind of Primitive Obsession as they violate

the object oriented paradigm and can cause hidden de-

pendencies (Yu and Rajlich, 2001). Type codes can

be removed by forming a class or, for example, with

a State or Strategy pattern (Gamma et al., 1995).

At Line 6, the parameter list of the work function

is described. Three of its parameters are integers,

whilst the fourth is a string. Parameter lists like this

are Primitive Obsession especially if they appear

several times in the code. (Strictly speaking, strings

are not primitive types, but logically it is practical to

include them in the deﬁnition.) They can be refacto-

red by introducing a parameter object. Lines 8 and 9

also conﬁrm the need for refactoring, because value

checks like this should usually be encapsulated. More

examples are available in Steven A. Lowe’s GitHub

ICSOFT 2018 - 13th International Conference on Software Technologies

390

1 class E mplo ye e

2 {

3 static const int E NG IN EE R = 1 ;

4 static const int S AL ES MA N = 2 ;

6 public void w ork ( int from , int to

, int nu m b e rO fB re ak s , Str in g

tas k )

7 {

8 if ( task == null

9 | | t a sk . l en gt h ( ) == 0 ) {

10 / ∗ . . . ∗ /

11 }

12 }

13 }

Figure 1: Sample code containing three Primitive Obsessi-

ons.

project

that shows step-by-step how to clean up a he-

avily Primitive Obsession infected code.

3.2 Challenges in Deﬁnition

As the previous section highlights it, it is challenging

to give Primitive Obsession an exact, quantiﬁable de-

ﬁnition. It has not only many various aspects, but

every program is unique with its own traits and crite-

ria. Developers also abstract and implement the com-

ponents differently. Therefore, it is impossible to ﬁnd

an absolute threshold for how many times the primi-

tive types can be used and to apply it to every project.

Since deﬁning Primitive Obsession is hardly pos-

sible with a single formula, the deconstruction of the

bad smell is a logical approach. One such decon-

struction is the Primitive Enthusiasm metric presented

in the next subsection.

3.3 Primitive Enthusiasm

Primitive Enthusiasm is a method level metric that

captures and reports one important aspect of the Pri-

mitive Obsession bad smell (G

al and Peng

o, 2018). It

is based on Formulas 1 and 2. The deﬁnitions of the

parameters are the following:

• PrimitiveTypes is the set of types that are handled

as primitive ones.

• N represents the number of methods in the current

class.

• M

denotes the ith method of the current class.

• M

denotes the current method under investiga-

tion in the current class.

• P

denotes the list of types used for parameters

in the the M

method.

https://github.com/stevenalowe/kata-2-tinytypes

• P

, j

deﬁnes the type of the jth parameter in the

method.

Primitives(M

) := hP

, j

|1 ≤ j ≤ |P

∧ P

, j

∈ PrimitiveTypesi

(1)

Formula 1 describes how the primitive-typed pa-

rameters are collected for a given M

method. That is,

select all the parameters from the M

method that can

be found in the previously introduced PrimitiveTypes

set and return them in a list.

The calculation of Primitive Enthusiasm is de-

picted in Formula 2.

LPE(M

) :=

∑

i=1

|Primitives(M

∑

i=1

| P

|Primitives(M

| P

(2)

The left-hand side of the inequality in Formula 2

denotes the percentage of how many of the parameters

of the current class are primitive types. Sum the num-

ber of primitive types in the parameter list for each

method in the currently processed class and divide

this value with the total number of parameters in the

class methods. The right-hand side of the inequality

in Formula 2 calculates the percentage of the primi-

tive types used in the currently investigated method.

The number of primitive types in the current method

is divided by the total number of parameters. Both si-

des of the inequality will calculate a number between

0.0 and 1.0 as the number of all parameters is always

greater than or equal to the number of parameters that

are primitive types. It is important to note, that only

methods with at least one parameter can be used as the

subject for the Formula. Methods without parameters

do not use any primitive types as input, thus they are

not the target of Primitive Obsession code smell.

The formula is calculated method-by-method in a

given class context, therefore it is considered as a lo-

cal value. Thus, in the upcoming parts of the paper

this formula will be referred as Local Primitive Ent-

husiasm (LPE). The value of LPE for a given M

met-

hod (LPE(M

)) is either true or false depending on

the satisﬁability of the inequality in Formula 2.

4 PROPOSED METRICS

As LPE captures only a small part of the Primitive

Obsession bad smell, it is a good idea to reﬁne the for-

mula through various changes. In this section, diffe-

rent variants of LPE for methods are constructed and

also new metrics that capture other aspects of Primi-

tive Obsession are presented. These formula variants

and their combinations can be used to pinpoint smelly

code parts in the program.

Grasping Primitive Enthusiasm - Approaching Primitive Obsession in Steps

391

4.1 Local Primitive Enthusiasm Variant

The original implementation of LPE was for Java,

therefore the PrimitiveTypes set contained the follo-

wing types: boolean, byte, short, int, long, char,

float, double, and String. In Java however there

are wrapper classes for the primitives deﬁned by the

language standard, namely: Boolean, Byte, Short,

Integer, Long, Character, Float, Double. Alt-

hough these types are classes, they can be conside-

red as primitives so the construction of the Local Pri-

mitive Enthusiasm with Wrapper classes (LPE

W+

) is

proposed by extending the PrimitiveTypes set of LPE

with the previously listed boxing types.

4.2 Global Primitive Enthusiasm

Global Primitive Enthusiasm (GPE) is shown in For-

mula 3, where G is a list which contains all the met-

hods in the analysed application. The right-hand side

of the inequality is the same as in Formula 2, the dif-

ference can be seen on the left-hand side. Unlike in

LPE, the global primitiveness ratio is calculated ba-

sed on every method in the project and the examined

method is compared to it.

GPE(M

) :=

|G|

∑

i=1

|Primitives(G

|G|

∑

i=1

| P

|Primitives(M

| P

(3)

The idea behind GPE is that it can be proﬁtable

to compare classes with each other to see which ones

are outstanding in regard to the primitive type usage

in the parameter lists of their methods.

Similarly to LPE

W+

, a new variant can be con-

structed from the GPE by including the boxing types

of Java in the PrimitiveTypes set. This new variant

will be referred to in the upcoming sections as Global

Primitive Enthusiasm with Wrapper classes (GPE

W+

4.3 Hot Primitive Enthusiasm

Both LPE and GPE report a set of methods that might

be affected by Primitive Obsession. To focus the at-

tention of the developer on the more suspicious code

parts, the combination of LPE and GPE is propo-

sed. The combined formula, Hot Primitive Enthusi-

asm (HPE) is presented in Formula 4. HPE reports

only the methods that are reported by both LPE and

GPE.

HPE(M

) := LPE(M

) ∧ GPE(M

) (4)

The Hot Primitive Enthusiasm with Wrapper clas-

ses (HPE

W+

) can be seen in Formula 5. HPE

W+

based on LPE

W+

and GPE

W+

where the Java wrapper

classes are included in the PrimitiveTypes set.

HPE

) := LPE

) ∧ GPE

) (5)

4.4 Result Aggregation

When evaluating a Primitive Enthusiasm variant on a

project, a set of methods is returned for which the for-

mulated inequality was true. However, for large pro-

jects the list of reported methods can be long, making

the review a demanding task. Therefore, a class level

aggregation of the results is proposed. This way, the

classes can be ordered by the number of their reported

methods.

4.5 Method Parameter Clones

After examining the nature of the Primitive Obses-

sion, it is reasonable to assume that if a class suffers

from Primitive Obsession, certain method parameters

will appear multiple times in the parameter lists of its

methods. They will have the same type and – usu-

ally – the same name because logically they corre-

spond to the same data. These are the parameters that

could be extracted to a value object instead of using

them separately. To grasp this property the Method

Parameter Clone (MPC) metric is presented, which

performs the following steps for each class in a pro-

ject:

1. Initially the MPC value for a class is set to zero.

2. For each method parameter in the class, create a

(type, name) pair.

3. Select only the pairs where the type is in the

PrimitiveTypes set.

4. Increment MPC value by one for every

(type, name) pair that appears at least three

times.

The reason that only three or more repetitions are

counted is The Rule of Three (Fowler, 1999).

4.6 Static Final Primitives

Another aspect of the Primitive Obsession bad smell

is the usage of class constant values as type codes. To

check if a variable can be a candidate for further in-

vestigation the Static Final Primitive function is used

which is described in Formula 6.

ICSOFT 2018 - 13th International Conference on Software Technologies

392

SFP(V ) := isClassLevel(V )

∧ isStatic(V )

∧ isFinal(V )

∧ isU pperCase(V )

∧typeO f (V ) ∈ PrimitiveTypes

(6)

The SFP function will return true for a varia-

ble (V ), if it has all the following properties, thus it

might serve as a type code:

• V is a class level variable,

• V is static (e.g. has a static modiﬁer in Java)

• V can be assigned only once (e.g. has a final mo-

diﬁer in Java),

• the name of V contains only upper case characters,

numbers, and underscores,

• and the type of V is included in the previously de-

ﬁned PrimitiveTypes set (i.e. primitive).

Otherwise SFP returns false. With this function it is

possible to ﬁlter out static ﬁnal primitive variable usa-

ges in methods.

The Static Final Variable Usage (SFPU) function

is deﬁned in Formula 7. It has three parameters: M

and V denote the function and variable under inves-

tigation, respectively, while F is a ﬁlter function. In

the formula, U

denotes one usage of variable V . The

∈ M

relation means, that the U

variable usage

(access or modiﬁcation) is preformed in the M

met-

hod. By applying the F ﬁlter function it is possible to

select a subset of the U

variable usages. The SFPU

function collects the access and modiﬁcation state-

ments for variable V in the M

method for which both

the SFP function and the supplied F ﬁlter function

returns true.

SFPU(M

,V, F) :={U



∈ M

∧ SFP(V ) ∧ F(U

)}

(7)

A concrete application of the SFPU function is

the calculation of the number of static ﬁnal primitive

variables which are used as case labels in switch sta-

tements. This can be achieved by deﬁning an F ﬁl-

ter function for the SFPU that determines for a gi-

ven U

variable usage if it is a case label. By using

the SFPU and the given F ﬁlter function a class le-

vel metric is constructed, which is named Static Final

Primitive - Switch Case Usage (SFP-SCU). The cal-

culation is done for each class to see how many times

its SFP variables appear as case labels globally in the

project. This heuristical approach is based on the idea

that type code variables most probably will appear in

branching structures, especially in switch-case sta-

tements.

5 EVALUATION

To implement and evaluate the proposed formu-

las and their variants, the OpenStaticAnalyzer

was

used, which is an open-source, multi-language, sta-

tic code analyser framework developed at the Depart-

ment of Software Engineering, University of Szeged.

The prototype implementation processes Java source

code, however with a minor modiﬁcation the metrics

could be applied to other object oriented languages as

well.

The Primitive Enthusiasm variants, Method Para-

meter Clones, and the SFP-SCU metric was evaula-

ted on three open-source Java projects. As there is no

benchmark for Primitive Obsession detection manual

validation was performed.

5.1 Eliminated Methods

The formulas introduced in Section 4 for Primitive

Enthusiasm calculation do not take into account that

some methods have only one parameter or none at all.

Also there are certain types of methods that should be

eliminated form the calculation of the metrics. During

the implementation this was taken into account.

The original implementation of LPE skipped the

investigation of constructors, the methods with empty

parameter list, and methods that could be considered

a class member setter method. Upon further work the

restriction was enhanced to skip the processing of all

the methods that had less than two parameters. A

comparison on the two elimination approaches was

performed.

5.2 Results

As the result validation was done manually, ﬁrst the

study of the analysed projects was done: joda-time-

2.9.9

, log4j

and commons-math-3.6.1

. Table 1

summarizes the major properties of the investigated

systems to get an overall image about them.

5.2.1 Exclusion Strategy

As it was stated in Section 5.1, two strategies was eva-

luated for eliminating methods: to skip only setter

methods (Skip Setter Methods - SSM) or skip every

https://github.com/sed-inf-u-szeged/

OpenStaticAnalyzer

https://github.com/JodaOrg/joda-time

https://github.com/apache/log4j

https://github.com/apache/commons-math

Grasping Primitive Enthusiasm - Approaching Primitive Obsession in Steps

393

Table 1: Properties of the examined projects: thousand li-

nes of code (KLOC), number of classes (NC), number of

methods (NM), longest parameter list (LPL)

Project KLOC NC NM LPL

log4j 16 189 1561 9

joda-time 28 249 4265 10

commons-math 100 1033 8808 14

method with just one parameter (Skip Ones - SO). Ta-

ble 2 sums up the details of the two strategies for the

examined three systems.

Table 2: Comparison of the two elimination stategies: num-

ber of not eliminated methods (NNM), average parameter

list length of not eliminated methods (AVG)

SSM SO

Project NNM AVG NNM AVG

log4j 1371 1.33 429 3.01

joda-time 3787 0.98 893 2.55

commons-math 7229 1.12 1953 2.93

The numbers show that with the SO strategy only

a subset of the methods was processed for the calcu-

lation. During the manual validation it was observed

that the SSM strategy causes noise in the results. It is

not surprising as it is hard to interpret Primitive Ob-

session on methods with only one parameter.

5.2.2 Wrapper Classes

In the paper different variants of the Primitive Enthu-

siasm metric are deﬁned, based on the content of the

PrimitiveTypes set. LPE

W+

, GPE

W+

and HPE

W+

take

into account the wrapper classes of Java during the

Primitive Enthusiasm calculation, whilst LPE, GPE,

and HPE do not. To compare the effect of including

boxing types into the PrimitiveTypes set, the num-

ber of methods with at least one (AL1) and at least

three (AL3) privitive typed parameters were counted.

During this calculation only the constructor methods

were eliminated, the previously introduced skip stra-

tegies were not applied. With this it can be obser-

ved how the inclusion, or exclusion of wrapper clas-

ses changes the number of investigated methods.

Based on the results the contrast is much less than

expected. These results are summarized in Table 3.

It shows that the extension of the PrimitiveTypes set

with boxing types has a very little consequence on the

set of methods that use primitive types in their para-

meter lists. The difference is only one or two methods

or none at all. Concluding these results, the SFPU,

SPU-SCU, and MPC calculations was done by using

the extended PrimitiveTypes set.

Table 3: Investigating the impact of wrapper classes by

the number of methods: at least one primitive parameter in

the parameter list (AL1), at least three primitive parameters

in the parameter list (AL3), exclude wrapper classes from

the PrimitiveTypes set (W-), include wrapper classes in the

PrimitiveTypes set (W+)

AL1 AL3

Project W- W+ W- W+

log4j 577 577 35 35

joda-time 1580 1583 95 96

commons-math 2758 2759 556 556

5.2.3 Primitive Enthusiasm Metrics

The Primitive Enthusiasm metrics suggest such met-

hods for refactoring that use unusually lot primitive

parameters. A result aggregation on the warnings is

also performed according to Section 4.4.

Table 4 shows the number of reported methods of

the three studied Java systems on the left side, while

on the right side, the number of classes which have

at least one reported method can be seen. The results

of Table 4 were produced with the Skip Ones (SO)

strategy.

To validate the results of the various Primitive Ent-

husiasm metrics, the given warnings were processed

manually. After randomly sampling the reported met-

hods they were checked in the source code. Addi-

tionally the class level aggregations were processed

with great attention to the classes with the most and

least reported methods. As both the evaluation, and

the judgement of Primitive Obsession itself are sub-

jective, deciding if a warning is true positive or not is

hard to tell, therefore the the signiﬁcance of the war-

ning was investigated.

It is clear from the results of Table 4 that the Pri-

mitive Enthusiasm metrics report many methods and

classes. However, the number of reported methods

are less than 8% of the total number of methods in

average. The other important aspect of Table 4 is that

there is almost zero difference between the metrics

which include and which do not include the wrapper

classes. Considering the results of Section 5.2.2 it is

not surprising, nevertheless, it is recommended to in-

clude these types in the PrimitiveTypes set as their

usage might depend on the nature of the project or the

habits of the programmer.

GPE and GPE

W+

express how different the com-

position of the parameter list of a method is from the

global average, whilst LPE and LPE

W+

express only

a class level distinction. The combined metrics HPE

and HPE

W+

perform well as they are able to further

ﬁne tune the results given by the LPE and GPE va-

riants. In most cases the reduction in the number of

ICSOFT 2018 - 13th International Conference on Software Technologies

394

Table 4: Comparison of Primitive Enthusiasm methods using the SO exclusion strategy.

Number of reported methods Number of reported classes

LPE LPE

W+

GPE GPE

W+

HPE HPE

W+

LPE LPE

W+

GPE GPE

W+

HPE HPE

W+

log4j 165 165 217 217 153 153 29 29 74 74 29 29

joda-time 301 301 429 431 230 231 92 92 104 105 65 66

commons-

math

698 698 1192 1192 553 553 213 213 390 390 145 145

reported methods and classes was more than 25% per-

cent. Based on this information it is recommended

that ﬁrst the HPE or the HPE

W+

reports should be in-

vestigated by the developer as they report both class-

localized and application-global suspicions.

Reviewing hundreds of methods can be tedious

work, however, by integrating the warnings into an

IDE this burden can be dramatically reduced.

5.2.4 MPC Metric

The main interest in the MPC metric was to study

how well the reported classes align with the classes

reported by the aggregated Primitive Enthusiasm me-

trics. For this evaluation the SO exclusion strategy

was used and the wrapper classes were included in

the PrimitiveTypes set.

MPC reported 6, 50, and 90 classes on log4j, joda-

time and commons-math, respectively. The highest

MPC count was 11 for log4j, meaning that in the

logMF and logSF classes there are 11 parameter type

- parameter name pairs that appeared at least three ti-

mes in different parameter lists. Both of these classes

were the top two results of the aggregated Primitive

Enthusiasm metrics. They contain numerous methods

that have a similar signature with multiple primitive

typed parameters, so the metrics report a repetitive-

ness in the code that sometimes indicates a design

ﬂaw in the program. The logXF class, the base for

logMF and logSF is also reported with an MPC count

of 2 and has a high rank in the aggregated Primitive

Enthusiasm results. The other three classes were also

reported by at least one of the Primitive Enthusiasm

variants.

The ﬁndings are similar for the other two pro-

jects too. The top ten classes in the aggregated

HPE

W+

results could be found in the MPC result set

as well. Classes that have many methods with above

the average primitive typed parameters usually have

lots of method parameter clones too. Therefore the

MPC metric can be a candidate for weighting the re-

sults of the aggregated Primitive Enthusiasm metrics

and highlight more repetitive parts in the code.

The intersection of the aggregated HPE

W+

and

MPC result sets for log4j, joda-time and commons-

math has the following size: 5, 31, and 56. The num-

bers show that by intersecting the result sets, a signiﬁ-

cant number of warnings were pruned from both me-

trics. Although we may lose some useful warnings,

this way we eliminate many noisy results.

5.2.5 SFP-SCU Metric

The metric was designed to detect type codes which

were introduced in Section 3. It follows from the na-

ture of type codes that they appear in conditional sta-

tements. The heuristical approach was to spot them

through their usage in switch-case statements. Ta-

ble 5 shows the results of SFP-SCU. It is important

to note that during the evaluation no exclusion stra-

tegy was used, thus all methods were considered. Ho-

wever, the effects of the SO exclusion strategy com-

bined with excluding constructors were also investi-

gated and the results were the same for the studied

projects. The wrapper classes were included in the

PrimitiveTypes set.

The number of classes reported by SFP-SCU is in

the second column of Table 5. These classes have

primitive-typed static ﬁnal class members that are

suspected to be type codes. The size of intersection

between the results of the aggregated HPE

W+

and

SFP-SCU is presented in the third column, whilst the

size of the intersection with the MPC metric in the

fourth column. As this metric grasps a different as-

pect of Primitive Obsession than the Primitive Enthu-

siasm metrics no signiﬁcant overlap was expected.

Table 5: Results of SFP-SCU. From left to right: the num-

ber of classes(NOC) found in the result of the SFP-SCU

metric, number of classes in the intersection of the aggrega-

ted HPE

W+

and SFP-SCU results, number of classes in the

intersection of the MPC and SFP-SCU results

Project

NOC

∩ HPE

W+

NOC

∩ MPC

log4j 8 5 1

joda-time 13 4 2

commons-math 1 0 0

The constant variables, that can be found in the re-

ported class of the commons-math project are used to

distinguish between random number generation stra-

tegies. They have only one switch-case occurrence

Grasping Primitive Enthusiasm - Approaching Primitive Obsession in Steps

395

and could be replaced, for example, with an enum.

The joda-time relies more on static ﬁnal variables than

the other two projects. These variables are members

in multiple classes with the same name, making it har-

der to understand the code. A generalized solution

could be considered instead of the scattered constant

usage. In log4j a typical example for type codes can

be found in the PatternParser class, which also ap-

pears in both intersections.

Though no hidden dependency check was done

to study the seriousness of the possible type codes it

might be rewarding to refactor them for a more object

oriented and readable solution.

6 CONCLUSION

In this paper several variants for the basic Primitive

Enthusiasm metric were introduced and other three

metrics were deﬁned to grasp more aspects of the Pri-

mitive Obsession bad smell. The metrics were imple-

mented in a Java static analyser, evaluated on three

large systems and the results were analysed.

The Primitive Enthusiasm variants can ﬁnd met-

hods that use more primitive types in their parameter

lists as the average. It is not just a readability issue but

can be a sign for other bloater type smells as well. The

SFP-SCU metric is useful for typed code detection. In

the future the authors would like to consider if a static

ﬁnal variable can be seen outside its class or not by gi-

ving the usages outside its class or package a different

weight than the inner usages. Additionally involving

other conditional statements in the calculation besi-

des switch-cases can be another improvement. The

MPC metric reports classes that have repetitive, the-

refore possibly smelly method signatures. The metric

could be reﬁned with ordinal information among the

parameter clones.

The ﬁndings showed that the new metrics can

highlight many smelly and hardly readable code seg-

ments. In the future we would like to continue the

study of these metrics and their combinations. The

inclusion of enum constants in the PrimitiveTypes set

could be an interesting experiment. Creating a Primi-

tive Obsession benchmark is also a goal to provide a

more objective comparison of the metrics.

ACKNOWLEDGEMENTS

This research was supported by the EU-funded Hun-

garian national grant GINOP-2.3.2-15-2016-00037

titled “Internet of Living Things” and by the pro-

ject ”Integrated program for training new generation

of scientists in the ﬁelds of computer science”, no

EFOP-3.6.3-VEKOP-16-2017-0002. The project has

been supported by the European Union and co-funded

by the European Social Fund.

REFERENCES

Fontana, F. A., Mariani, E., Mornioli, A., Sormani, R., and

Tonello, A. (2011). An experience report on using

code smells detection tools. In 2011 IEEE Fourth In-

ternational Conference on Software Testing, Veriﬁca-

tion and Validation Workshops, pages 450–457.

Fowler, M. (1999). Refactoring: Improving the Design of

Existing Code. Addison-Wesley, Boston, MA, USA.

al, P. and Peng

o, E. (2018). Primitive enthusiasm: A road

to primitive obsession. In The 11th Conference of PhD

Students in Computer Science.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns: Elements of Reusable

Object-oriented Software. Addison-Wesley Longman

Publishing Co., Inc., Boston, MA, USA.

Gupta, A., Suri, B., and Misra, S. (2017). A systematic lite-

rature review: Code bad smells in java source code. In

Computational Science and Its Applications – ICCSA

2017, pages 665–682, Cham. Springer International

Publishing.

antyl

a, M. V., Vanhanen, J., and Lassenius, C. (2003). A

taxonomy and an initial empirical study of bad smells

in code. In Proceedings of the International Con-

ference on Software Maintenance, ICSM ’03, pages

381–, Washington, DC, USA. IEEE Computer So-

ciety.

antyl

a, M. V., Vanhanen, J., and Lassenius, C. (2004).

Bad smells - humans as code critics. In Proceedings

of the 20th IEEE International Conference on Soft-

ware Maintenance, ICSM ’04, pages 399–408, Wa-

shington, DC, USA. IEEE Computer Society.

Moonen, L. and Yamashita, A. (2012). Do code smells re-

ﬂect important maintainability aspects? In Procee-

dings of the 2012 IEEE International Conference on

Software Maintenance (ICSM), ICSM ’12, pages 306–

315, Washington, DC, USA. IEEE Computer Society.

Roperia, N. (2009). Jsmell: A bad smell detection tool for

java systems. Master’s thesis, Maharishi Dayanand

University.

Yamashita, A. and Moonen, L. (2013). To what extent can

maintenance problems be predicted by code smell de-

tection? an empirical study. Information and Soft-

ware Technology, 55(12):2223 – 2242.

Yu, Z. and Rajlich, V. (2001). Hidden dependencies in

program comprehension and change propagation. In

Proceedings 9th International Workshop on Program

Comprehension. IWPC 2001, pages 293–299.

Zhang, M., Hall, T., and Baddoo, N. (2011). Code bad

smells: A review of current knowledge. Journal of

Software Maintenance and Evolution, 23(3):179–202.

ICSOFT 2018 - 13th International Conference on Software Technologies

396