Prevalence of Bad Smells in C# Projects

Amanda Lima Sab

oia

, Ant

onio Diogo Forte Martins

, Cristiano Sousa Melo

Jos

e Maria Monteiro

, Cidcley Teixeira de Souza

and Javam de Castro Machado

Department of Computing, Federal Institute of Cear

a, Fortaleza - Cear

a, Brazil

Department of Computing, Federal University of Cear

a, Fortaleza - Cear

a, Brazil

Keywords:

Bad Smell, Prevalence, C#.

Abstract:

Bad smell can be deﬁned as structures in code that suggest the possibility of refactoring. In object-oriented

languages such as C# and Java, Bad Smells are heavily exploited as a way to avoid potential software failures.

The presence of a high number of bad smells in a software project makes the system maintenance and evolution

hard. So, identifying smells in code and refactoring them helps to improve and maintain software quality. Anti-

patterns are considered inadequate programming practices, but not an error, they are bad solutions to recurring

software problems. In this work, we propose an exploratory study on open source projects written in C# and

published in GitHub. We empirically analyzed a total of 25 projects, studying the prevalence of Bad Smells,

in a quantitatively and qualitatively manner, and their relationship in order to identify possible anti-patterns.

Our results showed that implementation smells are the most common. Besides, some smells occur together,

such as Missing Default and Unutilized Abstraction that are perfectly correlated, and ILS and IMN detected

by association rules. Thus, the proposed study aims to assist software developers in avoiding future problems

during the development of C# projects.

1 INTRODUCTION

In object-oriented languages such as C# and Java,

software metrics have been used to provide devel-

opers with additional information about the software

quality (Singh and Kahlon, 2011). According to

(Pressman and Maxim, 2016), a metric lists the in-

dividual measurements found in the software. For ex-

ample, the average number of errors found per unit

test, providing quantitative measures to evaluate the

quality of software projects.

On the other hand, bad smells have been used

as a means to identify problematic classes in object-

oriented systems. In recent decades, bad smells

have received massive attention among software en-

gineering researchers, as they can pinpoint symptoms

that may, in the future, become signiﬁcant problems

(Fowler, 2018). According to (Sharma et al., 2017),

the term bad smell indicates the presence of quality

issues, primarily impacting the maintenance of a soft-

ware system. Bad smell can degrade aspects of code

quality, such as readability and mutability, and may

lead to the introduction of software ﬂaws. However,

even if a bad smell does not directly represent a defect

in the source code, as they are not technically incor-

rect and do not interfere with execution, they should

not be ignored as they may cause future problems and

compromise software quality.

In (Fowler, 2018), the authors have deﬁned differ-

ent types of bad smells that can be refactored. They

deﬁned refactoring as a process of changing the inter-

nal structure of a software system without changing

functionality. Thus, bad smells are used as a means to

identify problematic classes for refactoring in object-

oriented systems (Li and Shatnawi, 2007).

The presence of a high number of bad smells in a

software project makes the system maintenance and

evolution hard. So, identifying smells in code and

refactoring them helps to improve and maintain soft-

ware quality (Sharma, 2017). Some bad smells in-

dicate real code problems (for example, using a long

parameter list makes it difﬁcult to invoke methods),

while other smells are possible symptoms of a prob-

lem. For instance, when a method has feature envy,

it may indicate that the method is misplaced or that

some pattern like Visitor is being applied (Fontana

et al., 2012). Besides, in (Suryanarayana et al., 2014),

the authors had noticed that some smells amplify the

effect of other smells.

In this work, we describe an exploratory study on

424

Sabóia, A., Martins, A., Melo, C., Monteiro, J., Teixeira de Souza, C. and Machado, J.

Prevalence of Bad Smells in C Projects.

DOI: 10.5220/0009580204240431

In Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS 2020) - Volume 2, pages 424-431

ISBN: 978-989-758-423-7

25 open source projects written in C# and published

in GitHub. First, We have investigated the preva-

lence of Bad Smells through a quantitative analysis.

Next, we have studied the correlation between Bad

Smells. Then, we have analyzed the degree of co-

occurrence between these smells. Finally, we tried

to identify possible anti-patterns. We have noted that

some smells occur more often than others and, based

on this observation, some of them have been indi-

cated as strong candidates for possible anti-patterns.

Anti-patterns are bad solutions to recurring software

problems. Importantly, this work is not intended to

identify and catalog anti-patterns, but only to analyze

some frequently occurring smells that are strong can-

didates for anti-patterns. Moreover, in later studies

verify whether they really can be classiﬁed or not as

anti-patterns. The main idea of this paper is to get

useful information, such as correlations, association

rules between C# Bad Smells, in order to assist soft-

ware developers in avoiding future problems during

the development of C# projects.

2 RELATED WORKS

Some authors have already studied the presence of

bad smells in C# projects. In (Sharma et al., 2017),

the authors studied the relationship between the oc-

currence of design smells and implementation smells,

as well as the distribution of these smells in C# codes.

Their studies showed that the density of smells and

lines of code in the analyzed C# projects have no

strong correlation, and the most frequently occurring

smells are unutilized abstraction and magic number, i.

e., it’s an unexplained number used in an expression.

Besides, they observed a high degree of correlation

between the number of detected instances of design

and implementation smells. In (Alenezi and Zarour,

2018), the authors analyzed six open source systems

written in C# and checked whether bad smells are re-

solved while the software is evolving. They focused

on monitoring the evolution of bad smells. They also

noted that in most cases, bad smells persisted over

several successive versions of the software and real-

ized that smells are introduced into maintenance ac-

tivities.

In addition, some authors have studied the pres-

ence of bad smells in databases and mobile appli-

cations. In (de Almeida Filho et al., 2019), they

have studied the occurrence of bad smells in PL/SQL

projects and the degree of co-occurrence between

them. They observed that many smells have high cor-

relation coefﬁcients, above 0.9, and found bad smells

in SQL that occur together. In (Mannan et al., 2016),

the authors analyzed 500 open source applications

developed on Android and 750 desktop applications

written in Java, and later compared the instances of

smells present in the android application code with

the smells present in the java application code. They

noted that in java applications, the code is dominated

by two smells: external duplication and internal du-

plication. Meanwhile, android apps display a more

diverse set of bad smells. In (Habchi et al., 2017),

the authors performed a study related to the presence

of bad smells in the IOS mobile application. They

proposed a catalog of 6 IOS-speciﬁc smells identiﬁed

in the ofﬁcial platform documentation and feedback

from the developers. In addition, the authors also

presented an adaptation of the PAPRIKA tool, a tool

initially designed to detect smells in android applica-

tions, to detect smells in IOS applications.

Other authors have studied the impact of smells

on dimensions such as bug-proneness and change-

proneness. In (Palomba et al., 2016), the authors used

earlier ﬁndings on bug-proneness to create a special-

ized bug prediction model for smelling classes. Re-

sults indicated that the accuracy of a bug prediction

model increases by adding the intensity of bad smells

as a predictor. In (Kaur et al., 2016), the authors ex-

tracted bad smells from a mobile application written

in Java. They used machine learning techniques to

predict software change-proneness using bad smells

as predictor variables. They noted that bad smells are

better predictors of change-proneness problems com-

pared to object-oriented software metrics for balanced

and unbalanced learning methods. In (Liu et al.,

2018), the authors studied six open source projects

written in Java with up to 60 versions and noted

that: in most cases, smell-based metrics outperform

CK baseline metrics in the change-proneness study.

Furthermore, when used together, smell-based met-

rics are most effective at predicting change-proneness

ﬁles.

This paper proposes an empirical analysis of the

prevalence of bad smells in C# projects. Thus, the

main idea of this research is to obtain useful infor-

mation, such as correlations and rules of association

between these smells. Afterward, analyzing which

smells are candidates for possible anti-patterns, de-

serving future works special attention.

3 METHODOLOGY

We performed all experiments using only the back-

end code from the latest releases of some open source

projects written in C# public available on GitHub.

The methodology used in this article consists of

Prevalence of Bad Smells in C Projects

425

Figure 1: Diagram with the Methodology Overview.

ﬁve steps. The ﬁrst step is to select some projects

developed in C# and published in public repositories

on GitHub. Subsequently, we applied a code anal-

ysis tool for C# projects called Designite to the se-

lected projects. Designite generates a CSV ﬁle con-

taining information about the bad smells found for

each project. In the third phase, we developed Python

scripts to process the CSV ﬁles generated by the tool

and, later, we generated the datasets with the smells (a

spreadsheet composed by a summary and aggregated

information about the smells found in the projects).

In the fourth phase, we applied a set of data analysis

techniques to the dataset with the bad smells. In using

these techniques, we use scripts in Python and Jupyter

Notebook. Finally, we studied bad smells in isolation

to analyze possible anti-patterns. Figure 1 contains an

overview of the methodology used.

3.1 Collect C# Projects

First, we researched many projects developed in C#

and published in public repositories on GitHub. These

projects were selected based on the following criteria:

• The number of stars on GitHub, which represents

the sum of developers who appreciate the reposi-

tory;

• The number of forks in the repository, which

shows the number of times the repository has been

copied to private developer repositories;

• The percentage (%) of the project written in the

C# language, which shows the percentage of the

code implemented in C#. In this selection, only

projects whose implementation in C# was greater

than 80% were considered.

We have chosen twenty-ﬁve projects selected on

GitHub. All information about these projects, such

as name, description, the number of stars, the number

of forks. and the percentage (%) of the code written

in C# can be seen in our public repository

https://github.com/amandalsaboia/Bad-Smells-Projects

3.2 Report Generation with Bad Smells

We have used Designite (version 3.2.0.0) to perform

the collection of Bad smells from C# projects, a tool

that analyzes C# code and identiﬁes quality prob-

lems for software. Based on granularity and scope,

bad smells can be classiﬁed into architectural smells

(creation nature), smells from design (structural na-

ture), and smells implementation (behavioral nature)

(Ganesh et al., 2013). Designite detects seven smells

of architecture, eleven of implementation, and twenty

smells of design, totaling thirty-eight bad smells.

Also, this tool detects some object-oriented design

(OO) metrics, such as the number of classes and the

number of namespaces, in addition to detecting code

clones. Some of these metrics were collected by the

tool for the twenty-ﬁve projects analyzed in this arti-

cle.

For each analyzed project, Designite generates

three CSV ﬁles containing the bad smells found in

each class. The ﬁrst ﬁle contains the architectural

smells (at the namespace level), the second contains

the design smells (at the class level), and the last, the

implementation smells (at the method level). Each ﬁle

contains the location where a bad smell was found,

and the cause of smell occurring. Although there is

a difference in granularity between the types of bad

smells, the tool associates the occurrence of smell

with a class.

3.3 Construction of Datasets with Bad

Smells

Each previously generated CSV ﬁle contains a con-

siderable amount of bad smells in C#. For example,

the Newtonsoft.Json project contains a total of 15534

bad smells. Since it is not recommended to extract

smells manually, for the generation of datasets with

the smells found in each project, we developed some

Python scripts. In total, there were four scripts. In

the ﬁrst and second script, the data contained in the

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

426

CSV ﬁles were prepared with the smells of design

and implementation, in which a column called Path

containing the junction of Namespace and the Class

where smell took place. The ﬁles with the architecture

Smells used as path the value displayed in the column

Namespace, and it is not necessary to create a new

one. In the third script, the bad smells were added,

which were only of architecture, then those that were

only of the design and ﬁnally, those that were only of

implementation. Finally, in the last script, we have

constructed the dataset joining all bad smells (archi-

tectural, design, and implementation) found in the

project. Each line of this dataset represents a class

present in the analyzed project, and each column rep-

resents a bad smell. So, the value of a given cell

means the number of occurrences of a given smell in a

given class. We use these datasets in the data analysis

performed by the project.

The creation of a dataset with the smells found in

all projects happened similarly. It is only necessary

to create one more Python script. This script is re-

sponsible for merging all datasets per project created

previously. In this case, each row of the dataset with

all smells represents a C# project, and each column

represents a smell, in which the value of a given cell

contains the number of occurrences of the smell in

a given project. We used this dataset mainly in the

quantitative analysis of the data.

3.4 Analysis of Datasets with C# Bad

Smells

We performed both quantitatively and qualitative data

analysis. In quantitative data, research generally in-

cludes descriptive statistics and correlation analysis,

for example. Descriptive statistics, such as mean val-

ues, standard deviation, histograms, and scatterplots,

are used to help understand the data. Correlation anal-

ysis is used to describe how one smell is related to an-

other. For qualitative data, the main objective of the

analysis is to draw conclusions from the data, main-

taining a clear chain of evidence. Besides, advances

in Machine Learning techniques and data analysis

have provided powerful means for extracting useful

information and data knowledge (de Almeida Filho

et al., 2019). In this study, we used some data anal-

ysis techniques, such as correlation analysis, associa-

tion rule, and descriptive statistics.

In this stage of the work, we apply a set of data

analysis techniques to the dataset formed with the bad

smells. For this, we use scripts in python and the

Jupyter notebook for the execution of scripts. The ob-

jective of this step was to understand the smells in C#

and the relationship between them.

1. Quantitative Analysis: In this analysis, we used

some methods of descriptive statistics, such as bar

graphs, to understand the prevalence of smells in

C#. More speciﬁcally, the most common smells

and the most common types of smells.

2. Correlation between Bad Smells: An effective

correlation coefﬁcient measures the extent to

which two variables tend to change together.

Thus, it describes the strength and direction (pos-

itive or negative) of the relationship between

these two variables. Correlations between vari-

ables can be measured using different coefﬁcients

(de Almeida Filho et al., 2019). The most com-

mon correlation coefﬁcients are Pearson, Spear-

man, and Kendall.

The Pearson correlation coefﬁcient measures the

strength of the linear relationship between contin-

uous variables. It is the value that indicates how

much a line can describe the relationship between

variables. The Spearman correlation coefﬁcient

assesses the monotonic relationship between two

continuous or ordinal variables. In a monotonic

relationship, the variables tend to change together,

but not necessarily at a constant rate. Finally, we

have the correlation coefﬁcient of Kendall, which

is a measure of rank correlation, i.e., it veriﬁes

the similarity between the orders of the data when

classiﬁed by one of the quantities. This correla-

tion takes into account the directional agreement

of the so-called concordant and discordant pairs.

In this work, we use the Spearman correlation co-

efﬁcient, because it is the correlation that does not

need an assumption of normality of the distribu-

tion.

3. Association Rules: The purpose of the associa-

tion rule is to identify associations between data

records (items) that are related. For this, the

main idea is to ﬁnd subsets of items whose pres-

ence is correlated with the presence of some other

item in the same transaction (de Almeida Filho

et al., 2019). Smells usually do not exist in isola-

tion and are often accompanied by others smells

within the same class or in related classes (Wal-

ter et al., 2018). In the association rule, there are

two components, one called antecedent and the

other called consequent. Therefore, we observe

the set of bad smells (antecedent) that implies the

presence of other smells (consequent) in the same

classes. We use the Apriori algorithm, which re-

sults in a set of various items that should be used

to create the association rules that represent trends

found in the dataset. Then we use the associa-

tion rule to identify associations between the bad

smells in C#.

Prevalence of Bad Smells in C Projects

427

3.5 Analysis of Possible Anti-patterns

For the analysis of possible anti-patterns in C#, in the

Results and Discussion section, we analyzed and dis-

cussed three research questions. Through these anal-

yses, it was possible to select some bad smells present

in the twenty-ﬁve projects analyzed and indicate them

as strong candidates for possible anti-patterns.

4 RESULTS AND DISCUSSION

In this section, the results collected through analysis

and observations are shown through the following re-

search questions (RQ):

• RQ1: How often do bad smells appear in C#

projects?

• RQ2: Are there signiﬁcant correlations between

C# bad smells?

• RQ3: Are there smells that occur together in C#

projects?

4.1 Quantitative Analysis

To answer the ﬁrst question (RQ1), we performed

quantitative analysis on the occurrence of bad smells

in the twenty-ﬁve projects collected in C#. For this,

we built a dataset per project containing all bad smells

collected in Designite. Subsequently, we created a

dataset joining the smells of all chosen projects in-

dividually.

Table 1: Architecture Smells.

Acronym Architecture Smell

ACD Cyclic Dependency

AUD Unstable Dependency

AAI Ambiguous Interface

AGC God Component

AFC Feature Concentration

ASF Scattered Function

ADS Dense Structure

Tables 1, 2, and 3 contain the bad smells detected

by Desiginite, together with the acronym for each

smell (Garcia et al., 2009), (de Andrade et al., 2014),

(Suryanarayana et al., 2014). An acronym was as-

signed to each smell, which the smells of design start

with the letter “D”, those for implementation with

the letter “I” and those for architecture with the letter

“A”. These acronyms were created in order to facili-

tate later references in the article.

First, we observed that smell DFE was not found

in the studied projects. We also noted that some

Table 2: Implementation Smells.

Acronym

Implementation

Smells

ICC Complex Conditional

ICM Complex Method

IDC Duplicate Code

IEC Empty Catch Block

ILI Long Identiﬁer

ILM Long Method

ILP Long Parameter List

ILS Long Statement

IMN Magic Number

IMD Missing Default

IVC

Virtual Method Call

from Constructor

Table 3: Design Smells.

Acronym Smell Design

DBH Broken Hierarchy

DBM Broken Modularization

DCD

Cyclically-Dependent

Modularization

DCH Cyclic Hierarchy

DDH Deep Hierarchy

DDE Deﬁcient Encapsulation

DDA Duplicate Abstraction

DHM Hub-like Modularization

DIA Imperative Abstraction

DIM Insufﬁcient Modularization

DMH Missing Hierarchy

DMA Multifaceted Abstraction

DMU Multipath Hierarchy

DRH Rebellious Hierarchy

DUE Unexploited Encapsulation

DUH Unfactored Hierarchy

DUA Unnecessary Abstraction

DUN Unutilized Abstraction

DWH Wide Hierarchy

DFE Feature Envy

smells are rare to happen, such as ACD, AUD, AAI,

ACG, AFC, ASF, and ADS. Besides, the two most

frequent smells are the IMN and the ILS, both of

which are smells of implementation and with a 50.1 %

and 16.74 % occurrence percentage, respectively. In

addiction, the Newtonsoft.Json project is the largest in

the number of lines of code (1594611) and the number

of classes (14195). IMN and ILS are the bad smells

that occur most frequently in this project.

4.2 Correlation between the Bad Smells

We obtained the correlation between the bad smells

of the C# code to assess how closely they are related.

We performed an analysis of the strongly correlated

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

428

characteristics to identify whether they are potentially

related. Initially, we had to perform an analysis of the

smells correlation in each project using the correla-

tion coefﬁcient of Spearman and a lower limit of 0.5.

As shown in Figure 2, we noted that as the number of

classes in a project increased, the values of the corre-

lation coefﬁcients tended to decrease. It occurs since

the number of classes in a project increases. So, the

smells tend to dissolve between them, thus decreasing

the correlation between smells.

Figure 2: Graph with the Relationship between Correlation

Coefﬁcient and Number of Classes of the Project.

However, when analyzing the correlation between

bad smells at the project level, we observed that there

were many weakly correlated smells. So to answer

the research question RQ2, we listed only smells with

a correlation coefﬁcient greater than 0.675.

The DUE and DIM smells have a correlation co-

efﬁcient equal to 1 in the MaterialSkin project. The

smell 1 addresses the fact that it has a series of if-else

within a class by doing an explicit type check. The

smell 2 addresses the fact that a very large class can

be reduced to reduce complexity. So, it makes sense

that the two smells occur together, as there is a large

class where there are several if-else doing type check-

ing. However, this class could be reduced using the

concept of polymorphism. The code snippet in Fig-

ure 3 contains a real example of the joint occurrence

of smells ILS and IMN in the MaterialSkin project.

The smells DUA and DBM are strongly correlated

since the smell 1 occurs when a class exists, but it is

not necessary. The smell 2 occurs when methods that

should be present in a single class are found in sev-

eral classes. Thus, the strong correlation of these 2

smells makes sense because the classes instantiated

unnecessarily may be using methods that should be

exclusive to a single class. The smells ICM and ICC

are also strongly correlated. This is justiﬁed because

smell 1 when it occurs generates very high cyclomatic

complexity, and smell 2 occurs when a very complex

decision structure is used. Thus, if there is a complex

decision structure within a method, the method will

also be complex, increasing its cyclomatic complex-

ity.

The smells ACD and DMA are strongly correlated

since smell 1 occurs when a class A method depends

on a class B method and vice versa. The smell 2 oc-

curs when there is a class with many methods. Thus,

a class with a large number of methods has a good

chance of being called and going into cycles.

4.3 Association Rule

In order to answer the RQ3 research question, we

have developed a script in Python that implements the

Apriori algorithm to ﬁnd the association rules. We

generated a data collection in table format as follows:

if the smell occurs in a given project, the value TRUE

for that cell, and the value FALSE will be associated,

otherwise.

With datasets in the proper format, the next step

in ﬁnding the association rules based on conﬁdence

is to set the conﬁdence parameter to 50 %. With this

lower limit, it is possible to identify the smells that

occur together in some projects. We also identiﬁed

which of the smells occur in most projects. In total,

we found 56 different rules that happened in at least

two projects. However, we have considered only the

rules that happened from three projects onwards in

this study.

Thus, we used three metrics: Support, Conﬁ-

dence, Lift. According to (Cardoso and Figueiredo,

2015), the Support metric calculates the proportion

of transactions that contain the set of items, showing

their importance and signiﬁcance. Conﬁdence is the

probability of seeing the consequent of the rule on the

condition that the transactions contain the antecedent.

Moreover, the Lift metric measures how many times

more than expected the antecedent smell, and the con-

sequent smell occur together if they are statistically

independent.

From the results of the association rule, we ob-

served that:

• IMN is the smell that most occurs together with

others smells.

• The values displayed in the columns that start with

the word min., inform the lowest value of the pa-

rameter found in one of the projects in which the

rule occurred. Furthermore, the opposite is re-

peated for the values shown in the columns that

start with the word max.

The rule that occurs in the most signiﬁcant number

of projects, in which the antecedent is smell ILS, and

the consequent is IMN, also appears in the correlation

Prevalence of Bad Smells in C Projects

429

Figure 3: Source code with the joint occurrence of the ILS and IMN smells.

analysis, as previously studied. The second rule that

happens in the highest number of projects has as its

antecedent the smell ICM and the consequent smell

IMN. The source code snippet in Figure 4 contains an

example from the SharpZipLib project of the occur-

rence of this rule.

Figure 4: Source code with the joint occurrence of ICM and

IMN smells.

4.4 Analysis of Possible Anti-patterns

Bad Smells and anti-patterns are recurring software

problems. There is a minimal difference between the

two terms, in which anti-pattern is considered a in-

adequate programming practice, but not an error. In

(Singh and Kaur, 2017), the author deﬁned bad smell

as a warning for the presence of an anti-pattern.

Bad smells warn the developers of software that

the source code has some problems, while anti-

patterns provide software engineers, architects, de-

signers, and developers a common vocabulary to

recognize possible sources of problems in advance.

However, refactoring is a solution to remove both

anti-patterns and bad smells from the code. Accord-

ing to (Luo et al., 2010), the refactoring methods

for bad smells are more technical and programming-

based, whereas for anti-patterns are ”approaches to

involving the solution in a better one.”

During the quantitative analysis of datasets with

bad smells, we noted that the smells IMN and ILS are

the ones that occur in higher numbers both in the joint

analysis of the 25 projects and in the individual anal-

ysis per project. Moreover, in the qualitative analysis,

we also noted that the IMN and ILS smells have had a

high correlation and occurred together in 14 projects.

The frequency of these two smells can be caused by

some common reasons in development environments,

such as the time when the functionality must be de-

veloped and delivered, and the lack of knowledge and

understanding of good programming practices. Thus,

these two smells are strong candidates to be classiﬁed

as possible anti-patterns.

5 CONCLUSIONS

In this paper, we presented an exploratory study on

the occurrence of bad smells in C# projects. We ana-

lyzed 25 open-source projects, published on GitHub,

in order to study the prevalence of bad smells in C#

code. From this exploratory study, we answered the

three key questions of the article:

• RQ1: How often do bad smells appear in C#

projects? Some smells are more frequent than oth-

ers. Implementation smells are the most common,

with IMN and ILS being the most common.

• RQ2: Are there signiﬁcant correlations between

bad smells C#? The results showed that some

smells have high correlation coefﬁcients, with

some having a coefﬁcient equal to 1, such as the

smells IMD and DUN.

• RQ3: Are there smells that occur together in C#

projects? We used the Apriori algorithm and

found some interesting association rules, in which

we veriﬁed the occurrence of some smells that oc-

curred together. Also, we identiﬁed that the rule

that occurred in most projects was the one that had

the smell ILS as an antecedent and IMN as a con-

sequent.

Finally, we analyzed that the smells IMN and ILS

can be considered possible anti-patterns, this being a

future work. So, this work has the potential to help

professionals in the software development ﬁeld in or-

der to avoid future problems during the development

of C# projects.

ACKNOWLEDGEMENTS

This research was funded by LSBD/UFC.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

430

REFERENCES

Alenezi, M. and Zarour, M. (2018). An empirical study of

bad smells during software evolution using designite

tool. i-Manager’s Journal on Software Engineering,

12(4):12.

Cardoso, B. and Figueiredo, E. (2015). Co-occurrence

of design patterns and bad smells in software sys-

tems: An exploratory study. In Anais do XI Simp

osio

Brasileiro de Sistemas de Informac¸

ao, pages 347–354.

SBC.

de Almeida Filho, F. G., Martins, A. D. F., Vinuto, T. d. S.,

Monteiro, J. M., de Sousa,

I. P., de Castro Machado,

J., and Rocha, L. S. (2019). Prevalence of bad smells

in pl/sql projects. In Proceedings of the 27th Interna-

tional Conference on Program Comprehension, pages

116–121. IEEE Press.

de Andrade, H. S., Almeida, E., and Crnkovic, I. (2014).

Architectural bad smells in software product lines: An

exploratory study. In Proceedings of the WICSA 2014

Companion Volume, page 12. ACM.

Fontana, F. A., Braione, P., and Zanoni, M. (2012). Au-

tomatic detection of bad smells in code: An exper-

imental assessment. Journal of Object Technology,

11(2):5–1.

Fowler, M. (2018). Refactoring: improving the design of

existing code. Addison-Wesley Professional.

Ganesh, S., Sharma, T., and Suryanarayana, G. (2013). To-

wards a principle-based classiﬁcation of structural de-

sign smells. Journal of Object Technology, 12(2):1–1.

Garcia, J., Popescu, D., Edwards, G., and Medvidovi

c, N.

(2009). Toward a Catalogue of Architectural Bad

Smells. In Proceedings of the Fifth International Con-

ference on Quality of Software Architectures: Archi-

tectures for Adaptive Software Systems, volume 5581

of Lecture Notes in Computer Science, pages 146–

162. Springer International Publishing.

Habchi, S., Hecht, G., Rouvoy, R., and Moha, N. (2017).

Code smells in ios apps: How do they compare to an-

droid? In 2017 IEEE/ACM 4th International Con-

ference on Mobile Software Engineering and Systems

(MOBILESoft), pages 110–121. IEEE.

Kaur, A., Kaur, K., and Jain, S. (2016). Predicting software

change-proneness with code smells and class imbal-

ance learning. In 2016 International Conference on

Advances in Computing, Communications and Infor-

matics (ICACCI), pages 746–754. IEEE.

Li, W. and Shatnawi, R. (2007). An empirical study of

the bad smells and class error probability in the post-

release object-oriented system evolution. Journal of

systems and software, 80(7):1120–1128.

Liu, H., Yu, Y., Li, B., Yang, Y., and Jia, R. (2018). Are

smell-based metrics actually useful in effort-aware

structural change-proneness prediction? an empirical

study. In 2018 25th Asia-Paciﬁc Software Engineering

Conference (APSEC), pages 315–324. IEEE.

Luo, Y., Hoss, A., and Carver, D. L. (2010). An on-

tological identiﬁcation of relationships between anti-

patterns and code smells. In 2010 IEEE Aerospace

Conference, pages 1–10. IEEE.

Mannan, U. A., Ahmed, I., Almurshed, R. A. M., Dig, D.,

and Jensen, C. (2016). Understanding code smells

in android applications. In 2016 IEEE/ACM Inter-

national Conference on Mobile Software Engineering

and Systems (MOBILESoft), pages 225–236. IEEE.

Palomba, F., Zanoni, M., Fontana, F. A., De Lucia, A., and

Oliveto, R. (2016). Smells like teen spirit: Improving

bug prediction performance using the intensity of code

smells. In 2016 IEEE International Conference on

Software Maintenance and Evolution (ICSME), pages

244–255. IEEE.

Pressman, R. and Maxim, B. (2016). Engenharia de

Software-8

Edic¸

ao. McGraw Hill Brasil.

Sharma, T. (2017). Designite: A customizable tool for smell

mining in c# repositories. In 10th Seminar on Ad-

vanced Techniques and Tools for Software Evolution,

Madrid, Spain.

Sharma, T., Fragkoulis, M., and Spinellis, D. (2017). House

of cards: code smells in open-source c# repositories.

In Proceedings of the 11th ACM/IEEE International

Symposium on Empirical Software Engineering and

Measurement, pages 424–429. IEEE Press.

Singh, S. and Kahlon, K. (2011). Effectiveness of encapsu-

lation and object-oriented metrics to refactor code and

identify error prone classes using bad smells. ACM

SIGSOFT Software Engineering Notes, 36(5):1–10.

Singh, S. and Kaur, S. (2017). A systematic literature re-

view: Refactoring for disclosing code smells in object

oriented software. Ain Shams Engineering Journal.

Suryanarayana, G., Samarthyam, G., and Sharma, T.

(2014). Refactoring for software design smells: man-

aging technical debt. Morgan Kaufmann.

Walter, B., Fontana, F. A., and Ferme, V. (2018). Code

smells and their collocations: A large-scale experi-

ment on open-source systems. Journal of Systems and

Software, 144:1–21.

Prevalence of Bad Smells in C Projects

431