To var or not to var: how do C# developers use and misuse implicit and explicit typing?

Abstract

When implicit typing with the “var” keyword was introduced into C#, it prompted contradictory opinions among developers. This paper starts by explaining the difference between implicit and explicit typing and then provides an overview of developers’ opinions and guidelines that are available online. This paper then reports on the results of a study that investigated how C# developers use and misuse implicit and explicit typing. This study involved analyzing the source code of 10 different open-source software projects including more than 16,500,000 lines of code and more than 930,000 variables. This study investigated to what extent developers use a form of typing that affects the readability of a variable’s type and the length of its declaration. It also investigated whether or not there is an adoption of a consistent set of guidelines in general and across each software project. A tool called “Code Analysis and Refactoring Engine for C#” (Care#) was developed and used to conduct the code analysis for this study.

Full text

Software Quality Journal
To var or not to var: How do C# Developers Use and
Misuse Implicit and Explicit Typing?
Pierre A. Akiki
1
Abstract When implicit typing with the “var” keyword was introduced into C#, it prompted
contradictory opinions among developers. This paper starts by explaining the difference
between implicit and explicit typing and then provides an overview of developers’ opinions
and guidelines that are available online. This paper then reports on the results of a study that
investigated how C# developers use and misuse implicit and explicit typing. This study
involved analyzing the source code of 10 different open-source software projects including
more than 16,500,000 lines of code and more than 930,000 variables. This study investigated
to what extent developers use a form of typing that affects the readability of a variable’s type
and the length of its declaration. It also investigated whether or not there is an adoption of a
consistent set of guidelines in general and across each software project. A tool called Code
Analysis and Refactoring Engine for C# (Care#) was developed and used to conduct the
code analysis for this study.
Keywords C#, Code Analysis, Implicit and Explicit Typing, Readability, Consistency
1 Introduction
C# variable declarations used to be only explicit, until C# version 3.0 when implicit typing
was introduced. Implicitly typed variables are declared using the “var” keyword and thereby
the responsibility of inferring the type is delegated to the compiler. Here, a question arises:
When should developers use implicit typing in place of its explicit counterpart?
Anders Hejlsberg, the lead architect of C# at Microsoft, says that it is harder to decide
what to keep out of a programming language than it is to decide what to include (Anders
Hejlsberg, 2008). He talks about the importance of having guideline principles that allow
developers to understand how to use certain parts of a language. Adding implicit typing to
C# certainly has its benefits. Nonetheless, it is a controversial feature that prompted some
contradictory opinions within the C# community as observed in several online discussions
(Eric Lippert, 2011). Microsoft offered a set of guidelines on how to use this feature, but
1
Pierre A. Akiki
pakiki@ndu.edu.lb
Notre Dame University – Louaize, Lebanon
This is a post-peer-review, pre-copyedit version of an article published in Software Quality Journal. The final
authenticated version is available online at: https://doi.org/10.1007/s11219-018-9426-6

2 Software Quality Journal
these are not considered to be strict conventions (Microsoft, 2015a). Since C# is one of the
top programming languages in use today (TIOBE, 2017), it is useful to investigate how
“var” is actually used in practice.
1.1 Research Questions
This paper investigates the use and misuse of implicit and explicit typing in C#. The
overarching research question that this paper attempts to answer is reflected in its title as
follows: How do C# Developers Use and Misuse Implicit and Explicit Typing? This
question is divided into three sub-questions (RQ1, RQ2, and RQ3), which inquire about the
use and misuse of typing in terms of the readability and consistency of source code.
Readability denotes a reader’s ability to quickly and easily understand source code (Hashim,
1996). Consistency can be defined in terms of having uniform notation, terminology, and
symbology (Peercy, 1981). Both readability and consistency are considered to be factors that
affect maintainability (Ghosh and Rana, 2011). The overarching goal of this paper is to
determine the manner in which C# developers use implicit and explicit typing from the
standpoint of readability and consistency. Each of questions RQ1 and RQ2 is in turn divided
into sub-questions that are answered by a different part of the study presented in this paper.
This paper also introduces a tool called Code Analysis and Refactoring Engine for C#
(Care#). This tool could help software developers to avoid possible negative effects on
readability and consistently due to misuses of typing. Care# has an analysis component that
can detect implicit and explicit variables declarations and classify them under groups with
respect to their impact on type readability and declaration length. This component is used by
Care# to analyze source code before deciding if refactoring is needed, and it was used in this
paper to extract variable declarations from the open-source software projects that were
analyzed to answer the following research questions:
RQ1: Do C# developers misuse implicit and explicit typing in a way that affects the source-
code’s readability?
Regarding RQ1, this paper investigates whether or not software developers use implicit
and explicit typing in ways that affect readability with respect to a variable’s type and
declaration length (number of characters).
− RQ1.1: What are the possible groups that classify variable declarations with respect to
the impact of implicit typing on type readability?
− RQ1.2: Do developers use implicit typing when the type’s readability is not affected and
explicit typing otherwise, and to what extent is this applied?
Identifying the variable declaration readability groups that RQ1.1 asks about enables the
classification of typing choices according to these groups and subsequently answering
question RQ1.2. Answering the latter shows whether or not and to what extent developers
make typing choices that affect type readability. When declaring variables, software
developers might ignore type readability in all, some, or none of the readability groups.
− RQ1.3: Do developers use implicit typing to reduce the lengths of variable declarations
and improve line-of-code readability, even if this affects type readability, and do they
use explicit typing even when implicit typing can shorten the variable declaration length
without affecting type readability?

Software Quality Journal 3
It is possible that software developers are using implicit typing when the length of a
declaration is longer than a certain number of characters. Decreasing the number of
characters in a line of code (e.g., variable declaration) could improve the line’s
readability by reducing the need for scrolling left and right or shrinking the font size.
This reduction can be done by using implicit typing to eliminate type redundancy. Yet,
this choice might, in some cases, affect the readability of a variable’s type. It is also
possible that developers are choosing explicit typing even in the cases where implicit
typing could eliminate redundancy and shorten the length of a variable declaration
without affecting its type’s readability.
RQ2: Do C# developers follow some form of consistency (e.g., internal guidelines), at least
partially, for using implicit and explicit typing?
Regarding RQ2, since there are no strict conventions on typing, this paper investigates
whether or not developers follow an overall consistent set of guidelines or rather use the two
forms of typing arbitrarily. This consistency might be partial. For example, there could be
parts (e.g., modules) of a software project that are consistent while others are arbitrary.
− RQ2.1: Do developers exclusively use the same form of typing throughout an entire
software project regardless of readability?
Software developers might be exclusively using implicit or explicit typing throughout
the entire project. This is a form of consistency that disregards other factors such as
readability.
− RQ2.2: Do developers consistently use the same form of typing for identical variable
declarations?
One indication of inconsistency would be having software developers who use different
forms of typing with identical variable declarations that are assigned the same value.
− RQ2.3: Are implicit or explicit variable declarations consistently distributed within a
software project with respect to the sizes of its sub-projects?
This question asks about whether consistency is maintained within each software project
or there are discrepancies among different parts of the same project. It could be that most
implicit variable declarations are located within one or more sub-projects (Visual Studio
projects) that represent a small percentage of the overall software size. The size of a sub-
project is measured here in terms of the number of variable declarations it contains.
RQ3: Are there changes in the typing choices between one version of a software project and
another, which reflect a different attitude towards readability and consistency?
This question inquiries about the existence of a clear shift (not necessarily complete) in
practice, whereby software developers might be starting to move towards using typing
differently with respect to readability and consistency. This question is answered by
comparing two different versions of each of the analyzed software projects.
1.2 Research Motivation
In his book on clean code, Robert Martin mentions the opinions of several experts as an
overview of various schools of thought on what clean code is supposed to be like (Martin,

4 Software Quality Journal
2009). The following sentences summarize these opinions very briefly. Bjarne Stroustrup
says that clean code should be elegant. Grady Booch says that clean code should be simple
and direct. Dave Thomas says that clean code should be readable by developers other than
the original author. Michael Feathers says that clean code looks like it was written by
someone who cares. Ron Jeffries says that clean code contains no duplication. If we think of
these opinions in the context of implicit and explicit typing in C#, we are reminded of the
impact that the two forms of typing have on the human readers. For example, declaring a
variable with “var” when the type is not directly readable could affect the readability of the
source code. On the other hand, an explicit type creates duplication and may cause scrolling
or having to decrease the font size when the type’s name is long. These effects are part of
what causes contradicting developer opinions regarding the use of the two forms of typing. It
is interesting to investigate whether the developers of professional C# projects apply typing
in a way that considers readability and consistency, or just use whatever form of typing each
one thinks is appropriate. Hence, this paper investigates how developers think about typing
by analyzing the source code of existing open-source software projects.
Software systems evolve over time due to modifications and the addition of new
requirements. It is necessary to devote a significant amount of time to perform software
maintenance (Coleman et al., 1994; Lientz and Swanson, 1980). Martin Fowler defines
refactoring as: “the process of changing a software system in such a way that it does not
alter the external behavior of the code yet improves its internal structure” (Fowler, 1999).
Refactoring minimizes the possibility of introducing bugs. It can improve the readability or
performance of a design or the code that implements a design. Care# can refactor variable
declarations to improve readability by making a variable’s type obvious or making the length
of a declaration shorter. It could also help software developers to apply a consistent typing
guideline across the code-base of a software project.
It is important to note that the purpose of this paper is not to strictly favor and promote
one form of typing (implicit or explicit) over the other. This paper’s primary purpose is to
understand how software developers are using implicit and explicit typing, by answering the
research questions presented in Section 1.1.
1.3 Structure of the Article
The rest of this paper is organized as follows. Section 2 explains the difference between
implicit and explicit typing in C#, and the cases where each of the two forms of typing is
mandatory. Microsoft’s guidelines on the use of implicit and explicit typing in C# are briefly
presented in Section 3. A sample of developer opinions on the use of the two forms of typing
is presented in Section 4. These opinions were extracted from online discussions and
comments. An overview of the related work is presented in Section 5. The design and the
results of the study, which was carried out to analyze how software developers use and
misuse implicit and explicit typing in C#, are presented and discussed in Sections 6 and 7.
The threats to validity of this study are presented in Section 8. Finally, the conclusions and
future work are given in Section 9.

Software Quality Journal 5
2 Using Implicit and Explicit Typing in C#
Support for implicit typing in C# began with version 3.0, which was released in November
2007. Local variables, declared within the scope of a method, can be implicitly typed by
using the “var” keyword on the left-hand side of the declaration (Microsoft, 2015b). The
following example variable declarations are implicitly and explicitly typed:
var car = new Car(); //implicit typing
Car car = new Car(); //explicit typing
2.1 Implicit versus Explicit Typing
When implicit typing is used, the compiler infers the type by checking the right-hand side of
the declaration. In the abovementioned examples, the complier knows that the variable “car”
is of type “Car”, because of the assignment to a new instance of the respective type. The use
of implicit typing with the “var” keyword must not be confused with dynamic typing.
Implicit typing is a type of static typing; hence, the compiler checks the types at compile
time and issues errors where needed. Therefore, implicit typing has no additional impact on
performance. C# is a statically typed language, but it provides the ability to use dynamic
typing by declaring variables using the “dynamic” keyword that was introduced to C# 4.0 in
April 2010. The latter is not to be confused with “var”. The type is determined by the
compiler when “var” is used and by the runtime when “dynamic” is used (Joseph Albahari
and Ben Albahari, 2016, p. 180).
Here, a comparison can be made between “var” in C# and “var” in JavaScript. Unlike
C#, which is statically typed and supports dynamic typing, JavaScript is fully dynamically
typed. The types of JavaScript variables are determined at runtime. The “var” keyword in
JavaScript is somewhat similar to the “dynamic” keyword in C#. Hence, it is important for
developers who are moving from JavaScript to C# to understand that although the “var”
keyword exists in both languages the typing mechanism is different. It is also important to
understand that the “dynamic” keyword in C# is not meant to be used as frequently as the
“var” keyword in JavaScript due to its implication on performance.
Implicit typing is useful for shortening the length of a variable declaration. For example,
the following dictionary variable declaration becomes significantly shorter when implicit
typing is used.
Dictionary<int, string> items = new Dictionary<int, string>();
var items = new Dictionary<int, string>();
The following example shows how, in certain cases, explicit typing can become more
tedious due to the complexity of the type.
IEnumerable<IGrouping<string, Car>> carQuery = from car in cars
group car by car.Description;
var carQuery = from car in cars group car by car.Description;
Nonetheless, it is essential for programmers to remember the importance of maintaining
a type’s readability. It is better if programmers can directly read the type of the variable
being declared without a significant additional effort, especially when knowing the precise
type is important.

6 Software Quality Journal
2.2 Mandatory Use of Implicit Typing
When implicit typing is used, the inferred type may belong to several categories. These
categories include: built-in types, anonymous types, user-defined types, and types defined in
one of the .NET Framework’s class libraries.
The use of implicit typing is considered to be convenient in several situations. However,
when declaring a variable with an anonymous type, the use of implicit typing becomes
mandatory (Microsoft, 2015c). This allows the compiler to determine the variable’s most
appropriate type and thereby allows the programmer to access the variable’s properties. For
example, the following variable is declared with implicit typing and initialized to an
anonymous type. This declaration allows the programmer to access the “Description” and
“Quantity” properties of the variable “item”.
var item = new { Description = "pencil", Quantity = 10 };
The same situation applies to Language-Integrated-Query (LINQ) expressions that return
a collection of anonymously-typed objects. The following query converts each car object
Table 1 Restrictions on using implicit typing
Implicit typing cannot be used when
Examples
Declaring constants
const var x = 100;
Initializing a variable to null
var x = null;
A variable is declared but not initialized in
the same statement
var x;
A variable is initialized to a method group
private void button_Click(object sender,
EventArgs e) { }
var x = button_Click;
A variable is an anonymous function or a
lambda expression
var foo1 = delegate (string value) {
return value != "xyz";
}; /*or*/
var foo2 = value => value != "xyz";
var foo3 = () => value = "xyz";
A variable is declared at the class scope
public class Car
{
var Description = "";
}
A function’s parameters are declared
public void Foo(var a, var b = 10) { }
A variable represents an exception parameter
in a catch block
try { }
catch (var e) { }
An initialization expression is used
var x = (x = 10);
Multiple variables are initialized in the same
statement
var x = 10, y = 20;
A type named “var” is in the scope
public class var { }
var x = new Car(); /*x must be an instance of
the class “var” as shown below.*/
var x = new var();
An array is assigned to hard coded array
values without using the “new” keyword
var data = { 0, 1, 2, 3, 4, 5 };

Software Quality Journal 7
into an anonymously-typed object that only has the car’s “Description” and “ModelYear”
properties.
var carQuery = from car in cars
select new { car.Description, car.ModelYear };
2.3 Mandatory Use of Explicit Typing
There are several cases where implicit typing cannot be used, thereby making explicit typing
mandatory. These cases are presented with examples in Table 1.
Using the “var” keyword when implicit typing is not supported results in a compile error.
Hence, the examples presented in Table 1 result in such errors and are thereby underlined
with a squiggly line. The alternative in such cases would be to substitute “var” with the
appropriate explicit type as shown in the following example:
const var x = 100; /*results in a compile error*/
const int x = 100; /*fixed*/
3 Microsoft’s Guidelines Regarding the Use of
Implicit and Explicit Typing in C#
Microsoft provides some guidelines on when to use implicit typing in C# programs
(Microsoft, 2015a). As stated by the authors of these guidelines, their intentions are to offer
best practices that improve and facilitate consistency, understandability, and maintainability.
Following common guidelines, at least within the same company, is generally preferable to
having inconsistent practices. This is applicable to a variety of cases such as naming and
indentation. For example, Python goes as far as enforcing indentation consistency as part of
the compilation process. It might be hard to agree on common guidelines at first, especially
if the adopted programming language provides multiple ways of performing one thing. Yet,
having such guidelines could facilitate the implementation of software projects.
According to Microsoft’s guidelines, the use of implicit typing is recommended when a
variable’s type is obvious on the right side of the assignment, or when the precise type is not
important. It is possible to infer the type of an implicitly typed variable using Visual Studio.
However, from a human-computer interaction perspective, this could pose a burden. The
developer has to move the mouse over the implicitly typed variable to view the inferred type
in a tooltip. Repeating this process frequently could slow down a developer’s work in
comparison to reading a variable’s type as part of its declaration. Microsoft’s guidelines are
followed by its C# team when preparing code examples. However, the application of these
guidelines can differ from one software company to another (Paul Deitel and Harvey Deitel,
2018, p. 351).
Implicit typing is recommended when the type of a variable is clear from the context as
shown below:
var x = "some string";
var y = 10;
var z = Convert.ToInt32(a);

8 Software Quality Journal
It is not recommended to use implicit typing when the type of a variable is not clear from
the context (i.e., not apparent on the right side of the assignment). Hence, in such cases, an
explicit type is preferable as shown in the following example:
int x = obj.Foo();
It is recommended to use implicit typing in “for” and “foreach” loops as shown in the
following examples:
for (var i = 0; i < 10; i++) { }
foreach (var x in collection) { }
It is recommended to use implicit typing when instantiating new objects, since the type is
explicitly stated on the right side.
var x = new SomeClass();
It is recommended to use implicit typing when declaring query variables and range
variables. The following is an example of an implicitly-typed query:
var redCarBrandsQuery = from car in cars
where car.Color == "red"
select car.Brand;
Nonetheless, even an article from Microsoft, the company that created C#, spurred debates
among developers regarding the use of implicit and explicit typing. The following is an
example excerpt of this debate (references D4 to D13 represent software developers):
D4: “Implicitly Typed Local Variables - Please do not teach this. Please teach to define
strongly typed variables. …” (July 7, 2017)
D6 (Reply to D4): “The convention of using “var” instead of explicit type is valid in C#. ...
It’s a core value of the C# language. …” (July 15, 2017)
The following is an example excerpt of a debate from a Unity forum (Various, 2014):
D10: “... I’d rather pull the feature out entirely, code will build a couple ms faster, everyone
will be forced to be consistent.” (Mar 7, 2014)
Fig. 1 Sample of developers’ opinions on the use of implicit typing in C#

Software Quality Journal 9
D13: “I think var in C# is great and I’m using it everywhere recently. It feels like the
compiler is taking care of half of my job. ...” (Mar 8, 2014)
The following section presents more example excerpts from debates among developers
who expressed their opinions on the use of implicit and explicit typing in C#.
4 Online Discussions Regarding the Use of Implicit
and Explicit Typing in C#
There are many blog-post and forum discussions regarding the use of implicit and explicit
typing in C#. As these discussions show, there are often conflicting opinions among
developers regarding what style of coding to use in different situations.
Consider the following example discussion on Channel 9; a website that hosts videos for
developers using Microsoft technologies (Channel9, 2010).
D1: “While watching the video of Anders Hejlsberg, I happened to notice how he apparently
uses “var” almost for everything, while I use it extremely sparingly, if at all. ...what’s your
take on “var”?” (October 29, 2010)
D2: “I only use var for the occasional anonymous type, or when I’m doing complex LINQ
(like grouping) and find that I can’t guess the output type. I prefer explicit types: this is C#,
not PHP!” (October 29, 2010)
D3: “I use it all the time. It makes the code neater when you have a long list of different
types of variables.” (October 29, 2010)
D4: “I use var a lot in foreach statements but have also started to use it more often when my
class names are large and it becomes easier to write.” (October 30, 2010)
The following is another example excerpt of a debate on implicit and explicit typing.
This debate was done in the form of comments on a blog post that discusses the uses and
misuses of implicit typing in C# (Eric Lippert, 2011).
D5: “I’ll deal with it if the team I’m on dictates it, but as for my personal preference, you’ll
have to pry explicitness from my cold dead hands. ... While I am rationally aware that the
static typing is the same as always, it just reminds my irrational brain too much of weak
typing in scripting languages ...” (April 20, 2011)
D6: “Despite being very used to explicitly typed locals prior to the introduction of var,
implicitly typed locals are now the default for me. …” (April 20, 2011)
Online discussions such as the ones shown above are quite common. These discussions
usually reflect some of the advantages and disadvantages of both implicit and explicit typing
in different situations. However, in many cases, these discussions also show that there is no
consensus among software developers regarding the use and misuse of implicit typing in C#.
Here, it is important to note that the abovementioned discussions occurred in 2010 and 2014,
i.e., more than three years after implicit typing was introduced into C#. Hence, software
developers had enough time to contemplate about this feature.
A sample of opinions was taken from comments posted by 32 developers on the
abovementioned article on the uses and misuses of implicit typing (Eric Lippert, 2011) and
on Microsoft’s guidelines on using implicit typing (Microsoft, 2015a). These comments

10 Software Quality Journal
were made in the years 2011 and 2017. The data, presented in Fig. 1, confirm the lack of a
consensus on the use of implicit typing. Some developers took a strong stance in support of
using implicit typing as rarely as possible. On the other hand, some developers said that they
favor using implicit typing frequently, because it makes their work easier. A third group of
developers expressed more moderate opinions and said that they use implicit typing where
they think it had an advantage over explicit typing. Hence, this group uses a mixture of both
forms of typing more than other developers. Finally, some developers did not express a clear
opinion on the matter, but did not seem to mind using implicit typing.
This section presented an overview of the implicit versus explicit typing debate. The
study presented in this paper investigates whether or not this debate remains in professional
projects at the expense of following common guidelines that promote source code quality
attributes such as readability and consistency.
5 Related Work
To the best of my knowledge, there are no extensive studies that address the topic covered in
this paper. However, source code analysis has many applications (Binkley, 2007). Many
researchers have analyzed source code in order to identify problems that can be fixed to
improve software quality. Some papers specifically target C#, while others target different
programming languages. This section provides a very brief overview of some of the work
related to source code analysis, software quality, and refactoring targeting both C# and other
programming languages.
5.1 Implicit and Explicit Typing in C#
A paper proposed the investigation of feature adoption in C# (Capek et al., 2015). However,
it does not analyze how developers use the different forms of typing. A study was conducted
to observe how open-source projects are using C# generics (Kim et al., 2013). The question
related to implicit typing asked by Kim et al. (2013) was: “Do C# developers choose implicit
generic type declarations more often than explicit ones?” However, the analysis was limited
to the variable declarations that have a constructor call on the right side. Analyzing a small
subset of only one type of variable declarations does not provide sufficient insights on the
developers’ typing choices. The study presented in this paper aims to provide more insight
on where developers use implicit and explicit typing, by analyzing 20 categories of variables
declarations rather than just one. Kim et al. (2013) report on a percentage of variables being
declared using “var”. In comparison, this paper reports on percentages and checks if the
consistency of the typing choices is only affected by a few modules, in order to see if certain
groups of developers are deviating from their company’s guidelines (if any). Kim et al.
(2013) show the numbers of explicit and implicit types over time. On the other hand, this
paper compares two versions of each of the analyzed software projects to check for changes
in the trending typing choices. This involves comparing the same variable declarations
across the two versions to identify the cases (if any) where developers are changing their
opinions on the most suitable form of typing.

Software Quality Journal 11
5.2 Source Code Analysis
Many existing papers target the analysis of software identifier names. Although the analysis
of variable names has gained significant attention, the form of typing used to declare
variables was not given the same attention. A tool was presented for supporting concise and
consistent naming based on rules, in order to reduce the effort required to comply with
naming conventions (Deissenboeck and Pizka, 2006). The quality of identifier names was
explored in an empirical study that involved four hypotheses related to older and modern
programs, evolution, development model, and programming language (Lawrie et al., 2007).
Butler et al. explored the influence of identifier names on code quality (Butler et al., 2010),
and investigated the adherence to naming conventions in Java programs (Butler et al., 2015).
Other papers focused on analyzing different elements in software programs including:
asynchronous code, exception handling, code clones, and so on. A toolkit was developed to
analyze how C# programmers use asynchronous programming (Okur et al., 2014). This
toolkit was used in a study that uncovered bad practices in existing open-source software
projects and provided improvement suggestions. A study investigated whether Android
developers neglect error handling (Oliveira et al., 2018). Other studies explored how
developers use exception handling in C# and Java (Cabral and Marques, 2007), and the
evolution of exception handling in programs written in these two languages (Cacho et al.,
2014a). Software source code was analyzed in order to identify clones that include text and
high level concepts (Marcus and Maletic, 2001). The relationship between changes in C#
programs and the latter’s robustness was also explored in a study (Cacho et al., 2014b).
5.3 Source Code Refactoring
The internal quality of software systems can be improved through restructuring (Griswold and
Notkin, 1993), (Griswold, 1991) in order to lower the cost of maintenance. Restructuring can
rearrange parts of a software to improve its quality. When improving the design of object-
oriented code, refactoring is applied through small transformations that change part of the
code (Opdyke, 1992). The floss and root canal refactoring tactics are used to maintain
healthy code and correct unhealthy code respectively (Murphy-Hill and Black, 2008). It is
advisable to maintain healthy source code by treating refactoring as an ongoing activity
(James Shore, 2004). A brief summary of the existing work on source code refactoring is
given below. More details can be found in existing surveys of literature (Al Dallal and
Abdin, 2018; Mens and others, 2004).
SafeRefactor aims to make refactoring safer by analyzing the effects of transformations
and generating tests to check for behavioral changes (Soares et al., 2010). BeneFactor
detects the manual refactoring work performed by developers and offers them reminders of
the possibility of using automated refactoring (Ge et al., 2012). BeneFactor aims to increase
the use of automated refactoring tools. FaultBuster is a refactoring toolset with a framework
that performs automatic analysis, refactoring, and test execution (Szoke et al., 2015). An
approach was proposed for prioritizing code smells before selecting a suitable refactoring
operation for each one (Vidal et al., 2016). This approach helps developers to identify the
most critical code smells that need to be fixed first.
There are several existing refactoring tools for C#. ReSharper is one of the most known
among these tools (JetBrains, 2018a). ReSharper offers a few options for refactoring the
form of typing used in a variable declaration (JetBrains, 2018b). It can enforce “var” for

12 Software Quality Journal
built-in types, when the type is simple, and elsewhere. ReSharper can also be configured to
enforce “var” everywhere, explicit types everywhere, or “var” when the type of the variable
is evident. On the other hand, Care# is capable of classifying variable declarations under
multiple categories that are in turn classified under three type readability groups. So Care#
has three readability groups instead of two, and it can analyze the use of “var” with respect
to 20 variable declaration categories (shown in Fig. 2) instead of just with built-in types,
simple types, and elsewhere.
The topic of implicit and explicit typing in C# is interesting to developers who frequently
express their opinions about it as shown in Section 4. However, since this topic has not
received enough attention in the academic literature, it was interesting to conduct a study
that analyzed the use of the two forms of typing as explained in the coming sections.
6 Study Design
A study was conducted to investigate how C# developers use and misuse implicit and
explicit typing. The source code of ten open-source software projects was analyzed. The
analysis included investigating how the form of typing (implicit and explicit) affected type
readability and the lengths of variable declarations. It also involved observing how the form
of typing changed between two different versions of a software application. This study
helped in answering the research questions that were stated and explained in Section 1.
Fig. 2 Class diagram depicting the Care# domain model

Software Quality Journal 13
6.1 Procedure
First, a sample of ten open-source software projects were selected at random from the C#
projects available on GitHub. The random sample included projects of varying sizes and
types. I had no prior knowledge about the source code of the selected software projects.
Also, the authors of these projects had no knowledge that their code will be used for this
research. Two versions were included for each of the selected software projects. The two
versions of each project were selected to be on average one year apart. This way the projects
are likely to have significant enough changes that allow the observation of whether or not the
developers’ choices of typing are changing over time. For example, developers could be
refactoring implicit to explicit or vice versa in particular cases. On the other hand, the
projects are less likely to have changes that involve complete rewritings of classes and
methods, which could prevent the traceability between the variables in one version and their
counterpart in the other.
Variable declaration categories were identified in order to classify variable declarations
with respect to their impact on type readability. Part of these categories were initially
identified based on my experience with C# and Microsoft’s guidelines. Then, a preliminary
analysis of the selected software projects was conducted, and variable declarations were
extracted and classified under the identified categories. Afterwards, the variable declarations
that remained unclassified (i.e., did not fit any of the categories) were examined in order to
elicit the remaining categories. The unclassified variables were examined by querying the
data (extracted variables), which resulted from the analysis that was performed using Care#.
Table 2 Software projects that were analyzed in the study
Software Project
Description
.Net Core
CoreFX foundational libraries (e.g., collections, XML, etc.) (Microsoft, 2017a)
https://github.com/dotnet/corefx
MixERP
Open-source ERP, HRM, MRP, and MPS (MixERP Inc., 2015)
https://github.com/mixerp/mixerp
MonoDevelop
Cross platform IDE for Mono/.Net developers (MonoDevelop Project, 2017)
https://github.com/mono/monodevelop
NHybernate
Object-relational mapper (ORM) for .NET (NHibernate Community, 2017)
https://github.com/nhibernate/nhibernate-core
NUnit
Unit-testing framework for .NET languages (Poole et al., 2017)
https://github.com/nunit/nunit
OpenRA
Real-time strategy game engine (“OpenRA,” 2017)
https://github.com/OpenRA/OpenRA
Roslyn
.NET (C# and VB) Compiler Platform with code analysis APIs (Microsoft, 2017b)
https://github.com/dotnet/roslyn
Shadowsocks
Socks5 proxy for securing Internet traffic (Shadowsocks Community, 2017)
https://github.com/shadowsocks/shadowsocks-windows/releases
ShareX
Program for taking screenshots or screencasts (ShareX Team, 2017)
https://github.com/ShareX/ShareX
SharpDevelop
IDE for .NET programming languages (IC#Code, 2016)
https://github.com/icsharpcode/SharpDevelop

14 Software Quality Journal
The categories that were identified during this examination were added to Care# and the
analysis was redone. This process was repeated until all the categories were identified. The
variable declaration categories were classified under one of three groups, based on the
impact of implicit typing on the variable’s type readability. Once all the variable declaration
categories were identified and grouped, the source code was reanalyzed. Then, manual and
automated checks were performed to identify possible errors in the classification.
6.2 Analyzing Source Code with Care#
As previously mentioned in Section 1.1, the extraction and classification of the variable
declarations was done using the analysis component from Care#. The latter analyzes source
code with the help of the open-source C# compiler Roslyn (Microsoft, 2017b). A parser
generator tool such as ANTLR (Terence Parr, 2018) could have been used for this purpose.
However, Roslyn is dedicated for C# and can thereby be used to leverage advanced abilities
Table 3 Code characteristics of the software project versions that were analyzed in the study
Analyzed Code
Release
Number
Release Date
Number of
Lines of Code
Number
of Classes
Number of
Methods
Number of
Variables
.Net
Core
2.0
Aug. 14, 2017
3,081,331
9,237
57,834
188,969
1.0
Jun. 27, 2016
2,267,946
6,555
42,538
149,757
Mix
ERP
1.5
Oct. 22, 2015
591,790
2,006
8,399
17,026
1.2
May 27, 2015
140,448
700
2,056
4,694
Mono
Develop
6.3.0.863
April 4, 2017
1,086,981
4,386
17,454
57,845
6.1.2.38
Oct. 19, 2016
1,065,748
4,383
17,468
58,128
Nhiber
nate-core
4.11.GA
Feb. 2, 2017
475,874
1,818
7,406
27,520
4.1.0.GA
Dec. 18, 2016
475,760
1,817
7,404
27,519
NUnit
3.8.1
Aug., 29, 2017
111,392
491
1,971
4,245
3.2
Mar. 5, 2016
121,074
537
2,152
4,684
OpenRA
20171014
Oct. 14, 2017
141,782
1,311
2,815
12,051
20161015
Oct. 15, 2016
131,227
1,213
2,645
11,301
Roslyn
VS15.Preview5
Nov. 17, 2016
1,944,370
4,672
30,853
108,133
VS15.Preview
Apr. 1, 2016
2,073,753
5,037
33,321
117,238
Shadow
socks
4.0.6
Sep. 9, 2017
16,149
80
306
874
3.4.2
Dec. 16, 2016
25,098
124
419
1,649
ShareX
11.9.1
Aug. 14, 2017
176,245
645
2,318
7,159
11.2.1
Aug 19, 2016
167,279
632
2,222
6,792
Sharp
Develop
5.1.0.5216
Apr. 14, 2016
1,249,312
5,907
22,308
61,104
4.4.2.9749
Apr. 14, 2015
1,186,334
6,074
23,572
63,399

Software Quality Journal 15
more easily. Roslyn can be used in several ways to analyze C# code. One way is to load a C#
file into a syntax tree (CSharpSyntaxTree), and then run parsing operations (e.g., variable
extraction). Although this technique is efficient, it does not provide additional semantic
information that may be useful in certain cases. For example, when analyzing variable
declarations information is required about the type used in the declaration. Since the type
might not be in the context of the piece of C# code that was loaded into the syntax tree, it
cannot be accessed by Roslyn’s analysis services. Hence, Roslyn provides another technique
that is based on loading the entire workspace (MSBuildWorkspace) that includes the
solutions, projects, and documents. Having access to the workspace allows Roslyn to
perform a more detailed analysis. The latter technique is used by Care#.
In order to analyze variable declarations, Care# loads the information it needs into
instances of the classes depicted by the class diagram shown in Fig. 2. It parses solutions,
projects, and c-sharp documents. In each document, it parses the classes, methods, and
variables. Care# categorizes each of the extracted variable declarations under one of the
categories depicted by the “VariableValueCategory” enumeration shown in Fig. 2. Some
declarations, e.g., variables in “for” and “foreach” loops, are classified by using features that
are directly available through Roslyn. Other declarations, e.g., hard-coded values, are
classified using an algorithm that is written as part of Care#. This algorithm uses regular
expressions and comparison conditions to analyze the value that is assigned to a variable.
The categorized variable declarations were stored in a SQL Server database. SQL queries
were written and executed against this database in order to get the information needed for
answering the research questions presented in Section 1.1.
6.3 Analyzed Software Projects
Software projects of varying types and sizes were analyzed in this study. As shown in Table 2,
some software projects targeted software development, e.g., compiler, IDE, and so on, while
others were more general, e.g., ERP, screencasting tool, and so on.
Some of the code characteristics of the software projects that were used in the study are
presented in Table 3. These characteristics, which were obtained by using the analysis
component of Care#, include the number of: lines of code, classes, methods, and variables.
Once Care# loads the source code information into instances of the classes shown in Fig. 2,
it is possible to obtain the code characteristics presented in Table 3 through its counters. The
analyzed software project sizes ranged from thousands up to millions of lines of code. As
shown in Table 3, two versions of each of the analyzed software projects were used in the
study. Both versions were used throughout the analysis. Also, for each software project, the
older version was compared with its newer counterpart to observe how the use of explicit
and implicit typing evolved. The analysis conducted in this study involved in total more than
16,500,000 lines of code and more than 930,000 variables. The newer versions of the
software projects contained around 8,875,000 lines of code and around 485,000 variables.
The following are some descriptive statistics based on the data shown in Table 3 about the
software projects that were analyzed in this study:
 Lines of Code: Mean=826,494.65, Median=475,817, SD=897,068.99
 Classes: Mean=2,881.25, Median=1,817.5, SD=2,669.20
 Methods: Mean=14,273.05, Median=7,405, SD=16,260.32
 Variables: Mean=46,504.35, Median=22,272.5, SD=54,791.09

16 Software Quality Journal
7 Study Results
This section reports the results of the study that was described in Section 6 and attempts to
answer the research questions stated in Section 1.
7.1 Categories of Variable Declarations
This section answers research question RQ1.1 (refer to Section 1.1). Variable declaration
categories were identified and divided into four groups. The analysis done in this study was
conducted based on these groups of declarations.
The first group includes the categories of variable declarations where implicit typing
cannot be used; hence explicit typing becomes mandatory (refer to Section 2.3). This group
was identified based on common knowledge of C#, which indicates cases where implicit
typing is not allowed. Identifying this group of categories is important to avoid considering
implicit typing as a possible alternative in the variable declarations where explicit typing is
mandatory.
The other three groups of variable declaration categories are related to the readability of
a variable’s type when implicit typing is used and are based on Microsoft’s Guidelines (refer
to Section 3). Two groups were initially considered for grouping variable declarations based
on whether a variable’s type is directly readable. However, after observing Microsoft’s
Guidelines and exploring examples of variable declarations, it became apparent that a third
group is needed for variable declarations where types are not explicitly stated on the right-
hand side, but can be quickly inferred by observing the assigned value. The categories of
variable declarations under all groups are based on the sample of examined open-source
software projects (930,000 variables) and my experience with C#. It is possible to say that
these categories extensively cover the different types of available variable declarations. The
three readability-related groups of variable declaration categories are explained with
examples in the following paragraphs.
Table 4 Categories of variable declarations where the type is not directly readable when implicit
typing is used
Category of Local Variable Declaration
Examples
Expression
var x = a + b;
var y = obj.a % obj.b;
For each loop
foreach(var x in collection) { }
Inline condition
var x = a ?? b;
var y = a ?? Foo();
var z = isTrue ? a : b;
Method call
var x = Foo();
Property or variable
var x = obj.property;
var y = variable;
Query expression
var q = from e in collection where e.a
select e;
Value from object with indexer (e.g., array, list, etc.)
var x = arr[i];
var y = obj.arr[0];

Software Quality Journal 17
The second group is presented in Table 4, and it includes the categories of declarations
where implicit typing makes the type of the variable not directly readable. These categories
represent variables that are assigned one of the following: the result of a method call, a value
from an object with an indexer, a property or variable, an expression, or the result of an
inline condition. The same applies when using implicit variable declarations with “foreach”
loops and query expressions. Nonetheless, Microsoft recommends using implicit variable
declarations with these two categories (Microsoft, 2015a). This recommendation could be
based on an assumption that knowing the exact variable type with “foreach” loops and query
expressions is not always needed.
The third group of categories is presented in Table 5. This group includes the categories
where a variable’s type can be quickly inferred by observation, even though it is not directly
readable when implicit typing is used. These categories include assigning hard-coded values
to variables of primitive types and using implicit typing in “for” loops. Hard-coded character
values are placed between single quotes. On the other hand, hard-coded string values are
placed within double quotes and can include variations such as: interpolated (preceded by
“$”), formatted with “string.Format”, assigned to an empty string using “string.Empty”, and
so on. When a variable is assigned to a hard-coded number without a prefix, the C# compiler
makes this variable an integer by default. Although this type is not directly visible to the
developers, it is known to be an integer by convention. In case the hard-coded number has a
decimal point, then the type is known to be double by convention.
Table 5 Categories of variable declarations where the type is not directly readable when
implicit typing is used, but it can be quickly inferred by observation
Category of Local Variable Declaration
Examples
For loop
/*considered int by compiler*/
for (var i = 0; i < 10; i++) { }
Hard coded boolean
var x = false;
var y = true;
Hard coded char
var x = '#';
var y = 'F';
Hard coded number with suffix
var x = 0.1234d;
var y = 0L;
Hard coded number without suffix
var x = 5; /*considered int by compiler*/
var y = 10.5; /*considered double by compiler*/
Hard coded string
var x = @"some string";
var y = "some string";
var z = string.Empty;
var a = $"some string{i}";
var b = string.Format("some string{0}", i);
Table 6 Categories of variable declarations where the type is directly readable when implicit
typing is used
Category of Local Variable Declaration
Examples
Cast to another type
var x = a as Builder;
var y = (IDictionary)b;
var z = Convert.ToDecimal(c);
New object
var x = new StringBuilder();
var y = new List<string>();
Using
using (var s = new StreamReader("C:\\file.txt")) { }

18 Software Quality Journal
The fourth group is presented in Table 6, and it includes the categories of declarations
where implicit typing does not affect the type’s readability. Hence, the type is directly
readable on the right-hand side of the declaration. These categories include assigning
variables to new instances of objects (including using statements) and assigning variables to
values that are cast to other types using different casting techniques.
Microsoft also recommends using implicit typing with the categories of variable
declarations that are classified in this paper under groups 3 and 4 and are presented in Table
5 and Table 6 (Microsoft, 2015a).
As mentioned in Section 3, it is possible for developers, who are familiar with Visual
Studio, to use it for inferring a variable’s type for non-obvious cases such as the categories
of the second group (Table 4). However, this incurs additional interaction that might slow
down the developers’ work. It is possible that novice developers who are not familiar with
C# might take some more time to visually infer the types of implicitly typed variables by
reading the right side of the assignment in the third and fourth groups (Table 5 and Table 6).
Nonetheless, Microsoft recommends implicit typing in these cases. We can assume that with
time, as novice developers get more acquainted with C#, their ability to infer types in such
cases could improve. This assumption is based on the recommendations that are given in
Microsoft’s Guidelines (refer to Section 3) on the use of implicit typing in C#.
What follows are some examples that provide an overview of how a variable declaration
is categorized under one of the previously discussed categories. Care# obtains the locally
declared variables using Roslyn. The variables that are declared in the class scope (globally),
where implicit typing is not allowed, were identified in the same manner. Roslyn’s semantic
model provides a property called “IsConst” for identifying whether or not a variable is a
constant. Variables that are declared as part of “for” and “foreach” loops and query
expressions are also extracted by Care# using a built-in Roslyn functionality that can identify
these statements. Checking if a variable is assigned to a null value or is not assigned a value
is done by comparing right-hand side of the declaration to “null” and an empty string (“”)
respectively. Categories such as inline conditions, method calls, cast to another type, and
hard-coded string are identified using regular expressions.
7.2 Implicit and Explicit Variable Declarations per Category
This section answers research question RQ1.2 and RQ2.1 (refer to Section 1.1). The implicit
and explicit variable declarations were classified under categories that indicate where a
declaration is made or what is assigned to a variable. These categories were in turn classified
under groups based on whether or not the type’s readability is affected when implicit typing
is used (refer to Section 7.1). The results presented in Fig. 3 include all the software projects.
Variable declarations falling under the first group of categories were identified in this study.
However, these variable declarations were not analyzed since there is no implicit typing
alternative, and the main purpose of this study is to analyze implicit and explicit typing,
where both forms are possible.
The results show that explicit typing is overall used more than implicit typing. In the
cases where the type is directly readable with implicit typing, 37.29% of the declarations
were implicitly typed and 62.71% were explicitly typed. In the cases where the type is not
directly readable but can be quickly inferred, 31.06% of the variable declarations were
implicitly typed and 68.94% were explicitly typed. In the cases where the type is not directly
readable with implicit typing, 42.77% of the declarations were implicitly typed while

Software Quality Journal 19
57.23% were explicitly typed. These average percentages were calculated per group, while
taking into consideration the number of variable declarations in each group. A surprising
result is that implicit typing is mostly used in the group where it could negatively affect the
readability of a variable’s type. Assume that “query expressions” and “foreach” loops were
omitted from this group, because implicit typing is recommended in these two categories by
Microsoft’s guidelines. The use of implicit typing would still be higher than the other
categories with 37.64% of the variables being implicitly typed.
An important point to discuss is the use of LINQ statements. As pointed out in Fig. 3,
Microsoft’s guidelines recommend using implicit typing in the declaration of query variables
as shown below:
var namesOfAdultsQuery = from person in people
where person.Age > 18
select person.Name;
The LINQ query shown above is written in what is known as “query syntax”. The
examples shown in Microsoft’s guidelines on using “var” only mention this type of syntax.
However, LINQ queries can also be written in another form known as “fluent syntax” as
shown by the query below:
var namesOfAdultsQuery = people.Where(person => person.Age > 18)
.Select(person => person.Name);
Fig. 3 Percentage of implicit and explicit variable declarations per declaration category and
type readability group

20 Software Quality Journal
The “query expressions” reported in Fig. 3 cover queries written using query syntax. As
shown in Fig. 3, implicit typing is highly used with queries written in query syntax. This is
certainly understandable because this practice is recommended by Microsoft’s guidelines.
Also, the types returned by query expressions can be complex to write. Hence, it could be
easier for developers to use “var” instead. Yet, it is also interesting to observe what form of
typing developers use with fluent syntax. LINQ query expressions written using query
syntax can be directly extracted from the code using Roslyn. To analyze fluent syntax
queries, variable declarations with function calls on the right side were parsed. The parsing
checked for the use of LINQ query methods such as: select, where, orderby, sum, average,
Fig. 4 Percentage of implicit and explicit variable declarations per software project and type
readability group

Software Quality Journal 21
min, max, distinct, union, and so on. The results showed that 6.17% out of all method calls
in variable declarations contained LINQ queries written in fluent syntax. Out of the 6.17% of
variable declarations 81.33% used implicit typing. Two main points can be interpreted from
this result. The first is that developers mostly (>80% of the time) use implicit typing with
query expressions that are written using both query (Fig. 3) and fluent syntax. The second is
that most of the declarations that use implicit typing when assigning the variable to the result
of a method call (Fig. 3) do not contain queries and are thereby not following Microsoft’s
guidelines, since they obscure the type’s readability.
The results also show that implicit typing is not always used based on Microsoft
guidelines. Hence, there is a mixture of both implicit and explicit typing in the categories of
declarations where Microsoft recommends implicit typing to be used. This could be due to
the adoption of a different set of guidelines for the declaration of variables. However, the
results provide an indication that developers are not following a consistent way of using
implicit typing with respect to whether type readability is maintained. We can see that both
implicit and explicit typing are used in all categories regardless of the type’s readability.
As shown in Fig. 3, implicit typing is used very frequently with variable declarations that are
assigned to hard-coded strings. Yet, implicit typing is used less frequently with variable
declarations that are assigned to hard-coded numbers, characters, and boolean values. We
can also see that implicit typing is not used frequently in “for” loops. Explicit typing is
overall used more frequently in variable declaration categories where type readability is not
affected by the use of implicit typing.
The variable declarations were also categorized by software project, in order to observe
whether the same guidelines were being applied in each project. These results, presented in
Fig. 4, show that developers are not exclusively using implicit or explicit typing based on
whether the type’s readability is affected. We can also see that none of the projects are
exclusively using one form of typing all the time. Nonetheless, this classification shows that
some software projects exhibit an overall preference of one form of typing over the other.
For example, explicit typing is almost exclusively used in ShareX and MixERP. On the other
hand, implicit typing is overall used more than explicit typing in Roslyn and OpenRA. We
can see that even in the .NET Core and Roslyn, C#’s framework and compiler, there is a
mixture between implicit and explicit typing that in many cases disregards the type’s
readability. The overall use of implicit and explicit typing seems to be similar in each
software project across the type readability categories. Hence, the use of implicit typing is
not significantly different per software project among the groups of declarations depending
on the readability of the type.
7.3 Implicit and Explicit Typing with Respect to the Lengths of
the Variable Declarations
This section answers research question RQ1.3 (refer to Section 1.1). The overall length of a
variable declaration affects the length of a line of code and thereby its readability. Robert
Martin says that programmers overall prefer shorter lines of code that are on average 45
characters long and no more than 120 characters long (Martin, 2009, pp. 85–86). This
declaration length allows programmers to read the code without having to scroll to the right
or shrink the font size. It is also important to have readable identifier names, even if these
names are a little longer than their abbreviated less readable counterparts. In such cases,

22 Software Quality Journal
using “var” could compensate for long variable names by eliminating type repetition and
thereby reducing the length of a variable declaration.
The whisker plots presented in Fig. 5 show the differences in the lengths of the variable
declarations in case the implicit declarations were changed to explicit and vice-versa. These
charts also classify the variable declarations under the three type readability groups. The
assumption of converting one form of typing to another was made to see if the declaration
length is behind the developers’ choice of a certain form of typing, even if this choice
violates the type readability guideline.
Assume that implicitly typed variables were converted to explicitly typed ones. In the
declarations where the type is directly readable, the average increase in the declaration
length was 26.1 characters. The declaration lengths also increased on average by 8.27
characters when the type is not directly readable but can be quickly inferred. In these two
type readability groups, explicit typing increases the declaration length without providing
benefits in terms of the type’s readability. In the declarations where the type is not directly
readable, explicit typing increases the average declaration length by 36.5 characters.
However, in the latter group, explicit typing provides better type readability.
Assume that explicitly typed variable declarations were converted to implicitly typed
ones. In the declarations where the type is directly readable (with implicit typing), the
average reduction in the declaration length was 32.33 characters. In the declarations where
the type is not directly readable but can be quickly inferred, the average reduction in the
declaration length was 14.56 characters. In these two type readability groups, implicit typing
reduces the declaration length without affecting the type’s readability. In the cases where the
types are not directly readable, the average reduction in declaration length was 37.85
characters. In this type readability group, implicit typing significantly reduces the average
declaration length, but at the expense of type readability.
Fig. 5 Differences in the lengths of variable declarations in case implicitly typed variables
were changed to explicitly typed and vice versa (declarations are classified under groups that
indicate whether or not the type is readable in case implicit typing is used)

Software Quality Journal 23
The numbers presented in Fig. 5 show that there are cases where using one form of
typing has clear advantages over the other. However, there are cases where using “var” to
shorten the length of the declaration would affect the type readability. Consider the relation
between the developers’ choice of typing and the length of the variable declaration. When
developers chose implicit typing in the category of declarations where the type is not
readable with this form of typing, the average declaration length was reduced by 36.5
characters. However, developers also chose explicit typing in categories of declarations
where the type is directly readable or can be quickly inferred, and this choice increased the
length on average by 32.33 and 14.46 characters respectively. Due to these contradicting
Fig. 6 Identical initialized values used in both implicit and explicit variable declarations
Fig. 7 Identical variable declarations done with both implicit and explicit typing

24 Software Quality Journal
choices, it is possible to say that the developers’ choice of typing was overall not directly
related to the length of the variable declaration.
7.4 Identical Initialization Values Used with Both Implicit and
Explicit Declarations
This section answers research question RQ2.2 (refer to Section 1.1). Besides the arbitrary
use of implicit typing within the type readability groups, the results showed many cases
where both implicit and explicit typing were used when the variable was assigned to the
exact same value. For example: var x = 0 and int y = 0, or var a = true and bool b =
true. In such examples, it is possible to observe that different forms of typing are not only
used within the same declaration category as shown Fig. 3, but even when the variable is
Fig. 8 Percentages of implicit declarations with respect to visual studio project sizes (% of
related software project size) where type is not directly readable
Fig. 9 Percentages of implicit declarations with respect to visual studio project sizes (% of
related software project size) where type is not directly readable, but can be quickly inferred

Software Quality Journal 25
assigned a value that is exactly the same. This examination provides an additional indication
of whether or not there is an arbitrary use of implicit and explicit typing.
The results presented in Fig. 6 show that some variable declaration categories have
hundreds of assignment values that were given to variables, which were implicitly typed in
some cases and explicitly typed in others. One of the top 10 examples when this
phenomenon occurs is the declaration of a “StringBuilder” variable. The “StringBuilder” is a
class provided by the .NET Framework and very commonly used for string concatenation in
C#. The examined software projects show that “StringBuilder” variables were explicitly
declared 1,236 times (70%) and implicitly declared 513 times (30%). Other similar cases
include: “List<string>” (75% explicit and 25% implicit), “MemoryStream” (53% implicit
and 47% explicit), and “XmlDocument” (70% implicit and 30% explicit).
These cases are a common occurrence across the examined software projects and show
that implicit and explicit typing are mostly used without following consistent guidelines.
After counting all such cases and grouping them under the various declaration categories as
shown in Fig. 7, we can see that these occurrences include thousands of variables.
7.5 Distribution of Implicit Variable Declarations with Respect
to the Visual Studio Project Sizes
This section answers research question RQ2.3 (refer to Section 1.1). This study analyzed
whether or not there is a pattern in the use of a particular form of typing with respect to each
Visual Studio project pertaining to one of the selected software projects. This was done by
examining the correlation between the percentages of implicit variable declarations and the
size of the Visual Studio project in which these variables are declared. The project sizes
were measured in terms of the number of variable declarations.
Solutions (.sln) can be created in Visual Studio to organize software projects. A solution
can contain multiple Visual Studio projects underneath it. This study examined each
solution’s C# projects (.csproj). These Visual Studio projects usually represent part of a
software project’s functionality (e.g., modules, layers, etc.). Each group of developers
Fig. 10 Percentages of implicit declarations with respect to visual studio project sizes (% of
related software project size) where type is directly readable

26 Software Quality Journal
usually works on a number of these Visual Studio projects depending on the allocation of
tasks among the involved development teams. Assume, for example, that 80% of the implicit
declarations in a software project were located in a Visual Studio project that represents 20%
of the entire software project size. This could indicate that the team working on this part of
the system follows a different set of guidelines than the other teams.
The results show that the overall numbers of implicit variable declarations are mostly
proportional to the size of the Visual Studio project in which the declarations were done.
This is valid for the three type readability groups where the type is not directly readable (Fig.
8), type is not directly readable but can be quickly inferred (Fig. 9), and type is directly
readable (Fig. 10). The correlation between the Visual Studio project sizes and the
percentage of implicit variable declarations was calculated. For the variable declarations
analyzed in this study, a larger Visual Studio project size was correlated with a large number
of implicit variable declarations, r = 0.96, which can be considered as a large effect size. The
following descriptive statistics are for the percentage of implicit variable declarations per
Visual Studio project across the type readability groups: Mean=1.21%, Median=0.12%, and
SD=5.81%. The following descriptive statistics are for the Visual Studio project sizes with
respect to the total software project size: Mean=1.19%, Median=0.14%, SD=5.65%. The
correlation shows that the implicit variable declarations are dispersed across the Visual
Studio projects in each of the selected software applications. This indicates that the results
discussed in Section 7.2 are not caused by a limited number of Visual Studio projects, but
are rather common across all projects. Hence, it is unlikely that the arbitrary use of implicit
and explicit typing is due to a limited number of developers working on each of the analyzed
software projects.
Despite the correlation results, there are some exceptional cases below the trend lines as
shown on the graphs. These cases were worth investigating. For example, as shown in Fig. 8,
in one of the software projects 71.7% of the implicit variable declarations that affect the
type’s readability were done in a Visual Studio project that represents 30.59% of the total
size. This particular Visual Studio project is called “Greenshot.ImageEditor” and is part of
the ShareX software project that was analyzed in this study. As was shown in Fig. 4, ShareX
mostly had explicit variable declarations. Here, we can observe that the majority of its
Fig. 11 Percentages of visual studio projects containing both implicit and explicit variable
declarations in each of the analyzed software projects

Software Quality Journal 27
implicit variable declarations come from the Greenshot image editor, which is a separate open-
source project that was incorporated into ShareX. Hence, it is possible to say that the overall
trend in ShareX is to use explicit variable declarations and the deviation from this trend
comes from an open-source project that was developed by a different team. Another example
exceptional case shown in Fig. 8 is a software project where 33.44% of the implicit variable
declarations that affect the type’s readability were done in a Visual Studio project that
represents 2.33% of the total size. This software project is MixERP that was shown in Fig. 4 to
mostly have explicit variable declarations. A large percentage of the implicit variable
declarations in MixERP are from a project called “MixERP.Net.Entities”. In this case, it is
possible to say that the developers working on “MixERP.Net.Entities” are following
different coding guidelines than those who are working on other parts of MixERP.
As shown in Fig. 11, most of the analyzed software projects have a mixture of implicit
and explicit variable declarations in more than 70% of their Visual Studio projects. The only
two exceptions are ShareX and MixERP. Here we should note that a value of 100% in Fig.
11 does not indicate that a software project, e.g., Nhibernate-core, only uses implicit typing,
but it rather indicates the presence of implicit variable declarations in all the Visual Studio
projects. The data used for preparing the chart presented in Fig. 11 was collected using
Care#’s analysis component like the other data used in this study. As shown in Fig. 2, Care#
groups the variables of each analyzed software project per method, class, document, Visual
Studio project, and Visual Studio solution. Hence, as shown in Fig. 11, it was possible to
identify out of all the Visual Studio projects the ones that have a mixture of implicit and
explicit typing and the ones that only use a single form of typing. This was calculated by
running an SQL query on the database that holds the extracted variable information.
Fig. 12 Difference in months between the release dates of the two versions of each of the
analyzed software projects
Table 7 Number of declarations changed to an alternative form of typing between the older
release and the newer one in each of the analyzed software projects
Number of Variable Declarations
Software
Project
Months Between the Release Dates
of the Two Compared Versions
Changed from
Implicit to Explicit
Changed from
Explicit to Implicit
NUnit
17
4
8
.Net Core
14
1650
458
OpenRA
12
2
2
ShareX
12
29
0
Sharp Develop
12
28
153
Shadowsocks
9
0
0
Roslyn
7
80
37
Mono Develop
6
59
68
Mix ERP
5
7
1
Nhibernate-core
2
61
61
*The number of months between the release dates is calculated by subtracting the release date, indicated
on GitHub, of the older version from that of the newer one.

28 Software Quality Journal
7.6 Changes in the Form of Typing Between One Software
Version and Another
This section answers research question RQ3 (refer to Section 1.1). As the code evolves over
time, it is possible that developers change certain practices. In order to see whether there is a
change in the way implicit and explicit typing are used, a comparison was carried out
between the two versions of each of the analyzed software projects. This comparison
involved the extraction of the variable declarations that were changed from implicit to
explicit typing and vice-versa.
The box-plot shown in Fig. 12 presents the difference in months between the two
releases of each of the analyzed software projects. The difference ranges between 2 and 17
months. The numbers of changed variable declarations are presented per software project in
Table 7. The traceability of the variable declarations between the two versions of each of the
analyzed software projects was done based on the following indicators:
 name of the C# project under the Visual Studio solution (.csproj file name)
 name of the C# document where the class is defined (.cs file name)
 name of the class where the method is defined
 method signature (method name and parameter types)
 variable name
 variable declaration category (refer to Section 7.1)
Fig. 13 Declarations that were updated from explicit to implicit between older and newer
versions of selected software

Software Quality Journal 29
The results show that the changes between the two forms of typing range from zero up to
hundreds of variable declarations. The .NET Core project had the most changes. Considering
the changes from implicit to explicit and vice-versa, the mean number of changes is 270.8,
the median is 73, and the standard deviation is 648.83. As shown in Table 7, changes within
a project occurred in both ways whereby the typing of some variables was changed to
explicit and the typing of others was changed to implicit. Hence, the changes do not show an
overall trend of starting to favor one form of typing over the other.
Classifications of the changes in the form of typing based on the type readability groups
are presented for changes from explicit to implicit and vice-versa in Fig. 13 and Fig. 14
respectively. As shown in Fig. 13, the highest number of variable declarations (468) that
were changed to implicit typing, occurred in the category of declarations where the type’s
readability is not affected by implicit typing. Nonetheless, a significant number of variable
declarations (290) that were changed to implicit typing did affect the type’s readability. As
shown in Fig. 14, the highest number of variable declarations (1,503) that were changed to
explicit typing, occurred in the category of declarations where the type’s readability is
affected by implicit typing. Nonetheless, a significant number of variable declarations (388)
were changed to explicit even though implicit typing did not affect their type’s readability.
Overall, most the changes, whether implicit to explicit or vice-versa, were in favor of
type readability. However, since there are also other types of changes, it is not possible to
claim a trend towards favoring one form of typing over the other, even for the sake of
preserving type readability. Furthermore, the majority of the changes came from one project,
Fig. 14 Declarations that were updated from implicit to explicit between older and newer
versions of the selected software projects

30 Software Quality Journal
namely .NET Core, while the rest of the projects had minor changes in the form of typing as
shown in Table 7.
7.7 Discussion
The results of the study are summarized as follows. Software developers were overall not
choosing the form of typing based on the readability of a variable’s type or the length of its
declaration. This choice was also generally not strictly based on Microsoft’s guidelines and
tends to be somewhat arbitrary. There are cases when one form of typing is almost strictly
favored over the other. However, the overall choice of the form of typing in the analyzed
software projects tends to be inconsistent. Furthermore, the results did not show a trend
towards changing one form of typing to another based on clear guidelines. Based these
results, the research questions stated in Section 1 are answered as follows.
RQ1.1: Twenty variable declaration categories were identified before analyzing the
source code of the selected open-source projects. These categories were classified under
three groups that indicate the ease of identifying a variable’s type if implicit typing is used.
RQ1.2: The results showed that implicit typing was used in all the variable declaration
categories regardless of whether or not it affects the type’s readability. Software developers
were also using a mixture of both implicit and explicit typing in the categories of
declarations, where Microsoft recommends implicit typing to be used. RQ1.3: There are
cases where the software developers disregarded readability and chose implicit typing to
reduce the lengths of variable declarations. However, there are other cases where software
developers used explicit typing when “var” could have been used without affecting
readability. Due to these contracting choices, it is possible to say that the developers’ typing
choices were overall not directly related to the lengths of the variable declarations. Based on
these results, RQ1 can be answered by saying that developers misuse implicit and explicit
typing in ways that affect the source-code’s readability with respect to both the variables’
types and the lengths of the variables’ declarations.
RQ2.1: None of the analyzed projects were exclusively using one form of typing all the
time. Nonetheless, some of these software projects exhibited an overall preference of one
form of typing over the other. For example, explicit typing is preferred in ShareX and
MixERP, while implicit typing is preferred in Roslyn and OpenRA. RQ2.2: There were
many cases were both implicit and explicit typing were used for variables with identical
initialization values. These cases indicate that implicit and explicit typing are overall used
without following consistent guidelines. RQ2.3: The results showed that implicit variable
declarations are dispersed across the Visual Studio projects in each of the analyzed software
projects. This indicates that the arbitrary choices of typing are not caused by a limited
number of Visual Studio projects. Hence, it is unlikely that these choices are due to a limited
number of developers working on a few modules of the analyzed software projects. Based on
these results, RQ2 can be answered by saying that the overall choice of typing tends to be
inconsistent. The exceptions are a few projects that overall mostly favor one form of typing
over the other. This is a type of partial consistency. However, this consistency ignores the
source code readability factor.
RQ3: The comparison that was performed between two versions of each of the selected
software projects showed that most of the typing choice changes, whether implicit to explicit
or vice-versa, were in favor of type readability. Yet, it is not possible to claim a different
trend in the typing choices due to the existence of opposite of changes. Furthermore, the

Software Quality Journal 31
majority of the changes in typing choices came from one project, while the rest of the
projects only had minor changes.
As mentioned in Section 1, the purpose of this paper is not to strictly favor and promote
one form of typing over the other, but rather to understand how C# developers work.
Nonetheless, it is possible to say that, based on the results of the study, certain development
practices regarding the use of implicit and explicit typing can be changed in order to improve
the readability and consistency of source code. Care# has a code refactoring feature, which
could help developers to conform to configurable readability and consistency rules for
variable declarations.
8 Threats to Validity
One threat to the validity of the results is the accuracy of the extraction of variables from the
C# code, whether the extraction is purely based on Roslyn or a custom algorithm written for
Care#. To mitigate this threat, the automated analysis was verified by using manual
validation and automated unit tests to make sure that the algorithms are working properly.
Another threat arises from the fact that the data was collected from 10 open-source C#
projects that might not be representative of industrial practice. In order to mitigate this
threat, the selection process was done at random and the selected projects were diversified in
terms of size (number of lines of code), and type (e.g., development tools, business tools,
etc.). Also, the number analyzed lines of code (more than 16,500,000) is comparable to
similar code analysis studies, e.g., 17,600,000 (Okur and Dig, 2012), around 4,445,415
(Callaú et al., 2013), and 420,694 (Ma et al., 2017).
9 Conclusions and Future Work
When implicit typing with the “var” keyword was added to C#, it became a controversial
feature. There is no general consensus among software developers regarding its use. This
paper analyzed how C# developers use and misuse implicit and explicit typing. The
difference between both forms of typing was explained and a sample of opinions that
developers expressed online was presented. Also, existing guidelines from Microsoft on the
use of implicit typing were presented and explained.
A study was conducted as an attempt to understand how C# developers use implicit and
explicit typing in real-life projects. The study checked if developers consistently adhered to a
set of guidelines throughout their projects. It also checked whether or not developers used
either form of typing in a way that affected the source-code in terms of type readability and
redundancy, and the lengths of variable declarations.
The study conducted in this paper analyzed two versions from each of 10 open-source
software projects. The selected software projects were diversified in terms of size and
purpose, and had more than 16,500,000 lines of code and more than 930,000 variables. The
study showed that developers are overall not following consistent guidelines for using
implicit and explicit typing, and that there are misuses of both forms of typing which could
affect the source-code’s readability. Also, when two versions of each of the 10 analyzed
software projects were compared, there was no apparent trend towards moving from one
form of typing to another based on a clear guideline.

32 Software Quality Journal
This paper also presented the Code Analysis and Refactoring Engine for C# (Care#),
which is based on the open-source C# compiler Roslyn. Care# was used to analyze the
source code of projects that were selected for the study presented in this paper. It currently
supports the analysis and refactoring of the form of typing in variable declarations. In the
future, Care# will be extended to support more types of analysis and refactoring. It will also
serve as a starting point for more studies that aim to understand and improve the coding
habits of C# developers. One planned future extension is related to basic coding practices
that include the use of hard-coded values and magic numbers. Another planned future
extension is related to analyzing user interface (UI) representations in order to detect smells
and suggest possible fixes that can be automatically applied through refactoring operations.
References
Al Dallal, J., Abdin, A., 2018. Empirical evaluation of the impact of object-oriented code refactoring on
quality attributes: A systematic literature review. IEEE Transactions on Software Engineering 44, 44–69.
Anders Hejlsberg, 2008. Anders Hejlsberg Talks About The C# Language [WWW Document]. URL
https://www.youtube.com/watch?v=dc-YDS4JVA8 (accessed 11.12.17).
Binkley, D., 2007. Source code analysis: A road map, in: Future of Software Engineering, 2007. FOSE’07.
IEEE, pp. 104–119.
Butler, S., Wermelinger, M., Yu, Y., 2015. Investigating Naming Convention Adherence in Java References, in:
Software Maintenance and Evolution (ICSME), 2015 IEEE International Conference On. IEEE, pp. 41–50.
Butler, S., Wermelinger, M., Yu, Y., Sharp, H., 2010. Exploring the Influence of Identifier Names on Code
Quality: an empirical study, in: Software Maintenance and Reengineering (CSMR), 2010 14th European
Conference On. IEEE, pp. 156–165.
Cabral, B., Marques, P., 2007. Exception Handling: A Field Study in Java and .NET, in: Ernst, E. (Ed.),
ECOOP 2007 – Object-Oriented Programming: 21st European Conference, Berlin, Germany, July 30 -
August 3, 2007. Proceedings. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 151–175.
https://doi.org/10.1007/978-3-540-73589-2_8
Cacho, N., Barbosa, E.A., Araujo, J., Pranto, F., Garcia, A., Cesar, T., Soares, E., Cassio, A., Filipe, T.,
Garcia, I., 2014a. How Does Exception Handling Behavior Evolve? An Exploratory Study in Java and C#
Applications, in: Software Maintenance and Evolution (ICSME), 2014 IEEE International Conference
On. IEEE, pp. 31–40.
Cacho, N., César, T., Filipe, T., Soares, E., Cassio, A., Souza, R., Garcia, I., Barbosa, E.A., Garcia, A., 2014b.
Trading Robustness for Maintainability: An Empirical Study of Evolving C# Programs, in: Proceedings
of the 36th International Conference on Software Engineering, ICSE 2014. ACM, New York, NY, USA,
pp. 584–595. https://doi.org/10.1145/2568225.2568308
Callaú, O., Robbes, R., Tanter, É., Röthlisberger, D., 2013. How (and why) developers use the dynamic
features of programming languages: the case of smalltalk. Empirical Software Engineering 18, 1156–
1194. https://doi.org/10.1007/s10664-012-9203-2
Capek, P., Král, E., Senkerik, R., 2015. Towards an Empirical Analysis of .NET Framework and C# language
Features’ Adoption, in: Computational Science and Computational Intelligence (CSCI), 2015
International Conference On. IEEE, pp. 865–866.
Channel9, 2010. How much do you use “var” in C#? [WWW Document]. URL
https://channel9.msdn.com/Forums/Coffeehouse/How-much-do-you-use-var-in-C (accessed 1.12.17).
Coleman, D., Ash, D., Lowther, B., Oman, P., 1994. Using metrics to evaluate software system
maintainability. IEEE Computer 27, 44–49.
Daniel Grunwald, 2017. AvalonEdit [WWW Document]. URL http://avalonedit.net (accessed 3.1.18).
Deissenboeck, F., Pizka, M., 2006. Concise and consistent naming. Software Quality Journal 14, 261–282.
Eric Lippert, 2011. Uses and misuses of implicit typing [WWW Document]. URL
https://blogs.msdn.microsoft.com/ericlippert/2011/04/20/uses-and-misuses-of-implicit-typing (accessed
4.20.11).
Fowler, M., 1999. Refactoring: Improving the Design of Existing Code. Addison-Wesley.
Ge, X., DuBose, Q.L., Murphy-Hill, E., 2012. Reconciling manual and automatic refactoring, in: Proceedings
of the 34th International Conference on Software Engineering. IEEE Press, pp. 211–221.
Ghosh, S., Rana, A.K., 2011. Comparative study of the factors that affect maintainability. International
Journal on Computer Science and Engineering 3, 3763.

Software Quality Journal 33
Griswold, W.G., 1991. Program restructuring as an aid to software maintenance. University of Washington.
Griswold, W.G., Notkin, D., 1993. Automated Assistance for Program Restructuring. ACM Trans. Softw.
Eng. Methodol. 2, 228–269. https://doi.org/10.1145/152388.152389
Hashim, K., 1996. A software maintainability attributes model. Malaysian Journal of Computer Science 9, 92–97.
IC#Code, 2016. SharpDevelop [WWW Document]. URL
http://www.icsharpcode.net/OpenSource/SD/Default.aspx (accessed 10.23.17).
James Shore, 2004. Design Debt. Software Profitability.
JetBrains, 2018a. ReSharper [WWW Document]. URL https://www.jetbrains.com/resharper (accessed 1.3.08).
JetBrains, 2018b. ReSharper “var” keyword [WWW Document]. URL
https://www.jetbrains.com/help/resharper/Using_var_Keyword_in_Declarations.html#preferences
(accessed 1.3.18).
Joseph Albahari, Ben Albahari, 2016. C# 6.0 in a Nutshell. Oreilly.
Kim, D., Murphy-Hill, E.R., Parnin, C., Bird, C., Garcia, R., 2013. The Reaction of Open-Source Projects to
New Language Features: An Empirical Study of C# Generics. Journal of Object Technology 12, 1–1.
Lawrie, D., Feild, H., Binkley, D., 2007. Quantifying identifier quality: an analysis of trends. Empirical
Software Engineering 12, 359–388.
Lientz, B.P., Swanson, E.B., 1980. Software Maintenance Management: A Study of the Maintenance of
Computer Application Software in 487 Data Processing Organizations. Addison-Wesley.
Ma, L., Zhang, C., Yu, B., Sato, H., 2017. An empirical study on the effects of code visibility on program
testability. Software Quality Journal 25, 951–978. https://doi.org/10.1007/s11219-016-9340-8
Marcus, A., Maletic, J.I., 2001. Identification of high-level concept clones in source code, in: Automated
Software Engineering, 2001.(ASE 2001). Proceedings. 16th Annual International Conference On. IEEE,
pp. 107–114.
Martin, R.C., 2009. Clean code: a handbook of agile software craftsmanship. Pearson Education.
Mens, T., others, 2004. A survey of software refactoring. IEEE Transactions on software engineering 126–139.
Microsoft, 2017a. .Net Core [WWW Document]. URL https://www.microsoft.com/net/core (accessed
10.23.17).
Microsoft, 2017b. Roslyn [WWW Document]. URL https://roslyn.codeplex.com (accessed 10.23.17).
Microsoft, 2015a. C# Coding Conventions (C# Programming Guide) [WWW Document]. URL
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
(accessed 11.30.17).
Microsoft, 2015b. var (C# Reference) [WWW Document]. URL https://docs.microsoft.com/en-
us/dotnet/csharp/language-reference/keywords/var (accessed 11.30.17).
Microsoft, 2015c. Implicitly Typed Local Variables (C# Programming Guide) [WWW Document]. URL
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/implicitly-typed-
local-variables (accessed 11.30.17).
MixERP Inc., 2015. MixERP [WWW Document]. URL https://mixerp.org (accessed 10.23.17).
MonoDevelop Project, 2017. MonoDevelop [WWW Document]. URL www.monodevelop.com (accessed
10.23.17).
Murphy-Hill, E., Black, A.P., 2008. Refactoring tools: Fitness for purpose. IEEE software 25.
NHibernate Community, 2017. NHibernate [WWW Document]. URL http://nhibernate.info (accessed
10.23.17).
Okur, S., Dig, D., 2012. How Do Developers Use Parallel Libraries?, in: Proceedings of the ACM SIGSOFT
20th International Symposium on the Foundations of Software Engineering, FSE ’12. ACM, New York,
NY, USA, pp. 54:1–54:11. https://doi.org/10.1145/2393596.2393660
Okur, S., Hartveld, D.L., Dig, D., Deursen, A. van, 2014. A Study and Toolkit for Asynchronous
Programming in C#, in: Proceedings of the 36th International Conference on Software Engineering.
ACM, pp. 1117–1127.
Oliveira, J., Borges, D., Silva, T., Cacho, N., Castor, F., 2018. Do android developers neglect error handling?
a maintenance-Centric study on the relationship between android abstractions and uncaught exceptions.
Journal of Systems and Software 136, 1–18.
Opdyke, W.F., 1992. Refactoring: A program restructuring aid in designing object-oriented application
frameworks. University of Illinois at Urbana-Champaign.
OpenRA [WWW Document], 2017. URL http://www.openra.net (accessed 10.23.17).
Paul Deitel, Harvey Deitel, 2018. Visual C# How to Program, Sixth Edition. ed. Pearson.
Peercy, D.E., 1981. A software maintainability evaluation methodology. IEEE Transactions on Software
Engineering 343–351.
Poole, C., Prouse, R., Busoli, S., Colvin, N., 2017. NUnit [WWW Document]. URL http://nunit.org (accessed
10.23.17).

34 Software Quality Journal
Shadowsocks Community, 2017. Shadowsocks [WWW Document]. URL https://shadowsocks.org (accessed
10.23.17).
ShareX Team, 2017. ShareX [WWW Document]. URL https://getsharex.com (accessed 10.23.17).
Soares, G., Gheyi, R., Serey, D., Massoni, T., 2010. Making program refactoring safer. IEEE software 27, 52–57.
Szoke, G., Nagy, C., Fülöp, L.J., Ferenc, R., Gyimóthy, T., 2015. FaultBuster: An automatic code smell
refactoring toolset, in: Source Code Analysis and Manipulation (SCAM), 2015 IEEE 15th International
Working Conference On. IEEE, pp. 253–258.
Terence Parr, 2018. ANTLR [WWW Document]. URL http://www.antlr.org (accessed 4.1.18).
TIOBE, 2017. TIOBE Programming Community Index [WWW Document]. URL
https://www.tiobe.com/tiobe-index (accessed 12.26.17).
Various, 2014. Debate on typing: Unity forum [WWW Document]. URL https://forum.unity.com/threads/c-
microsoft-suggests-using-var-instead-of-a-type.232732/ (accessed 11.30.17).
Vidal, S.A., Marcos, C., Díaz-Pace, J.A., 2016. An approach to prioritize code smells for refactoring.
Automated Software Engineering 23, 501–532.

Software Quality Journal 35
Pierre A. Akiki is an assistant professor in the Department of Computer Science at Notre Dame University–
Louaize (NDU), Lebanon. Pierre received a Ph.D. in Computing from The Open University (OU), U.K., and
an MSc. and BSc. in Computer Science from NDU. He also received an MSc. in International Business from
Bordeaux Management School (now KEDGE), France and a M.B.A. from NDU. Pierre previously worked
part-time in academia as a computer science instructor and full-time in industry focusing on engineering
enterprise software systems. He has 15 years of experience in programming with C#. His research interests
include adaptive model-driven UIs and end-user development for IoT. His work was published in several
venues including TSE, CSUR, TOCHI, and ICSE, and it received the best paper award at EICS’13. Pierre is a
visiting researcher in the Department of Computing and Communications at the OU. Contact him at
pakiki@ndu.edu.lb; pierreakiki.com.