\subsection{Quality and quality metrics}
IEEE Standards define software quality as the array of features of
a software product that represent its capability to satisfy 
specific needs \citep{Youness2013ComparativeSO}.
Software quality  is the extent to which  a  process,  
component,  or  system fulfills customers' needs  or expectations 
through product or service features, thus providing customer 
satisfaction \citep{Iacob_Constantinescu}. 

Functional and  structural qualities are the key  aspects  of  software 
quality  \citep{Liu2006AnIE}.  \citet{Farhan} describe 
functional  quality  as  the capability  of  the  software 
to  properly  perform  its  tasks according  to  user  needs  and  
intended  objectives.  Structural quality refers to 
the resilient structure of the code itself and is difficult to test
compared to functional quality. The main difficulty is that this 
notion is quite subjective.

In general, structural code quality is a multi-faceted concept, which covers
different  attributes of software engineering, for example, maintainability  and
readability \citep{Mohammadi2013AnAO}. To evaluate them, various metrics of
software structure were proposed. For instance,  McCabe’s software complexity
metrics \citep{McCabe1976ACM} and cognitive  complexity metric
\citep{Cognitive}, which are intended to measure readability  aspects of the
code. Also, for object-oriented systems, a popular  set of metrics is the CK
suite \citep{Chidamber1994AMS}. Many approaches apply such metrics suite to
distinguish parts of the source code with good  or bad quality
\citet{Fil2015ACO}, \citet{Shatnawi2010FindingSM}  or to identify code smells
(problematic properties and anti-patterns  of code)
\citet{Ouni2011MaintainabilityDD}. However, in general, the software engineering
community has not yet reached a consensus as to what exactly structural quality
or maintainability is \citep{Broy2006DemystifyingM}.
% (\todo: this is quite an old reference...).


\subsection{Software patterns and code smells}

We understand the term \textit{software patterns} in the most general and
abstract way, namely, as any observed code subtructures and software solutions.
Patterns can be of different scale (from variable and method-level to project
level). The term \textit{designed patterns} refers to patterns that are
recommended solutions to commonly occurring programming goals and problems
\citep{gamma1995design}. Despite their popularity, there is much controversy about the
usefulness and universality of such recommended ways of implementation
\citep{mcconnell2004code}. The software engineering community
also identifies patterns that are detrimental to the resulting code. Such
patterns are often called \textit{code smells}. These are parts of the
source code that contain violations of  fundamental design principles
and negatively impacts maintainability in terms of the
ability of the product to evolve, quality  of end-product, and developer
productivity \citet{Reeshti2019MeasuringCS}. \citet{Din2012AntipatternsDA}
identified 22 types of  code smells in object-oriented
design. \citet{Kessentini2019UnderstandingTC} found strong correlation  between
several code smells and software bugs.

For the latter reason, a lot of tools and methods have been designed to avoid
code smells. \citet{Kreimer2005AdaptiveDO}  proposes a decision tree based
approach to identify code smells, e.g, long method  and large class.
\citet{Vaucher2009TrackingDS} apply Bayesian  networks to detect God class.
\citet{Palomba2015MiningVH} propose  to consider changes of repository history
as an input to the code smell detector  for computing the list of code
components affected by the smell. \citet{Liu2019DeepLB} propose a deep learning
based approach  to detect code smells.

Code smell detection has been integrated into code inspection tools. 
\citet{MurphyHill2010AnIA} integrate software metrics  visualization with a
source code view.  SonarQube\footnote{https://www.sonarqube.org/} controls and
manages  the code quality in several ways, such as continuous  inspection and
issue detection. The platform shows issues  like code smells, bugs, using
lightweight  visualizations. 
%It also helps developers to collaborate with a
%shared vision of code quality.
Checkstyle\footnote{https://checkstyle.sourceforge.io/} and
PMD\footnote{https://pmd.github.io/}  work similarly to SonarQube.  

%iPlasma
%evaluate the quality of  %object-oriented programs. It can be used %to calculate
%different metrics and to identify the most %critical points that can be improved
%through code smell %detection.

All in all, there is no uniform agreement about which patterns are good and
which are bad. We made it our ideology while developing Aibolit: we do not
decide what is good or useful \textit{a priori} but let it be inferred from
data. By customizing the dataset, quality metric and pattern set, the end user
of Aibolit is able infer which patterns are good for his own end goals.
