Code comprehension, a fundamental asset in software development and its maintenance, is influenced by the programming paradigms employed. Comprehending code takes up a major part of the maintenance process. This study forms a basis in discovering the relation between code comprehension and multi-paradigm usage. The diferent paradigms covered here are Object-oriented programming and functional programming. To measure the possible impact an experimental setup is designed that will help capturing quantitative and qualitative data. The decision of using interviews as study experiment allows for the capturing of the qualitative data necessary for an in-depth exploration of comprehension strategies and participants' cognitive reasoning. The interviews will use Kotlin code snippets, this choice harmonises with participants' familiarity with Java, which serves as a foundation, and the design of interview questions, which prioritise the comprehension of code and the unravelling of its underlying purpose. This paper provides the background and experimental setup that allows to investigate the relationship between code comprehension and multi-paradigm usage.
SATToSE’23: Post-proceedings of the 15th Seminar on Advanced Techniques and Tools for Software Evolution, June 2023, Fisciano, Italy $ dan.floor@gmail.com (D. Floor); Rinse.vanHees@InfoSupport.com (R. v. Hees); vadim@grammarware.net (V. Zaytsev) https://grammarware.net/ (V. Zaytsev) 0000-0001-7764-4224 (V. Zaytsev)
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License incorporated functional programming concepts and
conCPWrEooUrckReshdoinpgs IhStpN:/c1e6u1r3-w-0s.o7r3g ACttEribUutRion W4.0oInrtekrnsahtioonpal (PCCroBYce4.0e).dings (CEUR-WS.org) structs. In a multi-paradigm perspective, there are two
diferent kinds of paradigms, the first paradigm is chosen RQ2: How can we study the code
for the problem most frequently targeted by the language. comprehension of functional
Whereas, the second paradigm is chosen to support ab- programming usage in multi-paradigm
straction and modularity which fills the gaps the first
paradigm leaves open [
To provide structure to the research, the following research questions have been established.
define and build a study that makes it possible to analyse this. The study will use practitioners from the field in RQ1: Which multi-paradigm constructs any of the four analysed languages, as well as students can be identified when combining that are familiar with any of those languages. With the object-oriented programming and results gained from the study, we can analyse code comfunctional programming? prehension. In areas where code comprehension scores poorly, we will look at similar constructs that cause this This document covers the diferent concepts and con- issue. Additionally, we will also look at possible positive structs that identify functional programming and object- impacts of constructs on code comprehension, if there oriented programming. These constructs already have are any. plenty of metrics and ways to measure their complexity and thus their impact on maintainability. Four multi- RQ4: How can we define code smells that paradigm languages have been selected for our analysis: reflect the code comprehension of these C#, Java, Scala, and Kotlin. In previous research [9], it has already been concluded what support for functional languages? programming constructs these languages have. We want Lastly, we want to turn the analysis of the previous reto discover the impact of mixing multi-paradigm code search question into something more conspicuous. We on the code comprehension of practitioners. To achieve want to achieve this by defining code smells that are inthis, we must define which multi-paradigm constructs troduced in a multi-paradigm environment. We do this can be identified when OOP and FP code are combined. by going over other sources that defined code smells and With the outcome of this question, we can compare the understand what makes a code smell a code smell. With constructs with the other languages and look for similar- the knowledge gained from this and the analysis of the ities but also diferences in functionality. These answers study we performed, we will be able to define code smells, will help us construct the answers for the next research in case they are present. question.
Programming paradigms, e.g. object-oriented
programming, can be viewed as a categorisation and grouping
of a set of concepts that guide the development of
software. Each paradigm is associated with a distinct set of
principles and techniques that can be realised through a
programming language. Such a language can in its turn
realise more than one paradigm. This creates a hierarchy
with endless possibilities. Van Roy’s visualisation [
Despite the distinct set of concepts of a paradigm, there
are often common grounds between paradigms. A
taxonomy, a way to classify the diferent paradigms, can be
constructed of the programming paradigms that display
the relations between the paradigms [
A programming language is not restricted to realising only one paradigm and can realise two or even more. These kinds of languages are called multi-paradigm languages, think of most object-oriented programming languages that support functional programming constructs(Java, C#, Python). As demand for increasingly complex systems grows, the need for multi-paradigm programming languages has become more prevalent. These languages enable developers to select the best paradigm for a given task, resulting in greater flexibility and expressiveness in code.
Within the taxonomy of Figure 2 two primary
categories of paradigms can be distinguished: declarative
programming and imperative programming. While these
are not the only paradigms, most other paradigms are
based on either one of the two paradigms. Understanding
the strengths and weaknesses of each paradigm, and how
they can be combined, can lead to the development of
powerful languages with a multitude of possibilities [
that focuses on statements that modify the state of a program. Programs in this paradigm are constructed using a sequence of statements executed in a specific order, with each statement altering the state of the program.
These alterations can either change a variable or afect the program’s environment. Two well-known imperative programming paradigms are procedural programming and object-oriented programming.
Imperative programming has been widely used in the development of systems that require precise control of program flow and state. However, this paradigm can often result in code that is dificult to read and maintain, especially as programs grow larger and more complex.
Despite its limitations, imperative programming remains record Descriptive declarative programming
XML,
S−expression Data structures only Turing equivalent
Observable nondeterminism? Yes No + unification (equality)
Deterministic logic programming
+ search Replarotigornaaml m&ilnoggic +sybnyc−hnreoend.
eP+mrsobolleovdge,drSinQgLs prfougnLrcaatmizoymnainlg Constraint (logic) Haskell programming
CLP, Gecode + thread Concurrent constraint programming
LIFE, AKL + by−need synchronization Lazy concurrent constraint programming Oz, Alice, Curry
+ procedure First−order functional programming
+ closure Functional programming
Functional object−oriented programming
Scheme, ML, Scala pCroongtrianmu+amtciionongntinuation prfougnArcaDtmioTmnainlg Scheme, ML Haskell, ML, E + thread + single assign.
Functional dataflow programming Declarative concurrent programming
Pipes, MapReduce + thread + by−need + single assignment synchronization
Lazy functional dataflow programming
Lazy declarative concurrent programming Oz, Alice, Curry + name (unforgeable constant) + cell
ADT imperative programming CLU, OCaml, Oz + port (channel) Multi−agent dataflow programming
Oz, Alice, AKL + nondeterministic choice Nondeterministic dataflow programming Concurrent logic programming
Oz, Alice, Curry, Excel, AKL, FGHC, FCP + synch. on partial termination Functional reactive programming (FRP) Weak synchronous programming
FrTime, SL + logical time instants Strong synchronous
programming Esterel, Lustre, Signal
Nondet. state
Dataflow and message passing + cell (state) v2.01 © 2023 by Peter Van Roy
Imperative programming
Pascal, C Imperative search programming + search SNOBOL, Icon, Prolog +(pchoartnnel) (+stacteel)l + closure pErovgernatm−lmooinpg opbrIjoemcgptr−aeomrartmiievnientegd
E in one vat Stateful pMrouglrtai−ma+mgeitnnhtgread prfougnrcatmioJmnaaivnlag, OCaml Message−passing + thread concurrent Conc. imperative programming object−oriented
Erlang, AKL programming + local cell Schoanrecdu−rrsetnatte Active object programming programming Smalltalk, Java, Object−capability Oz, Alice, Scala programming + log tpuupCblEelS,issPOph,a/zsO,cueAcbc(lsLiaccmireni,,bdea,) SQmLteramSenoomsfratybcwt(eiaSodrTnedaMlin)gs
Message passing Named state
Shared state Less declarative Logic and constraints More declarative
Functional
Unnamed state (seq. or conc.) an important programming paradigm due to its wide us- 2.1.2. Procedural programming age in real-world systems. Understanding the principles and techniques of this paradigm can provide developers Procedural programming is a programming paradigm with valuable insights into designing and implementing that revolves around the concept of procedures, which efective software. are also known as subroutines or functions. Procedure
Procedural programming is one example of an imper- are small sections of a program that performs a specific ative programming paradigm, where programs are con- task. Procedural programming supports features that structed using procedures or subroutines that perform a alter the control flow such as if-statements and loops specific task. The procedure is executed in a step-by-step (for and while). Any kind of procedure may be called by manner, with each statement modifying the state of the another procedure at any time, giving it a wide variety program until the desired output is achieved. of possible applications.
Another well-known imperative programming One of the first languages to adopt the procedural proparadigm is object-oriented programming (OOP), which gramming paradigm was ALGOL, which introduced the emphasises the creation of objects that encapsulate concept of block structure and the use of subroutines data and behaviour. Objects interact with each other by to make programs modular. The C programming lansending messages and invoking methods, which modify guage, developed in the 1970s, also popularised the use the state of the objects. of procedural programming and is widely regarded as one of the most influential programming languages of all time [10]. In the figure procedural programming is not necessarily listed, but instead, it falls under just the imperative programming block. 2.1.3. Object oriented programming Object-oriented programming is a paradigm in software development that revolves around the concept of objects, which are instances of classes. The term was first introduced by Kay in 1967 as “only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things” [11]. Later and somewhat more formally, OOP was described as “a method of implementation in which programs are organised as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships” [12].
It is evident that the view on OOP has shifted through time, but objects will be the centre of the paradigm. OOP facilitates the use of abstraction, which involves defining the essential characteristics of an object while hiding unnecessary implementation details. Additionally, OOP makes heavy use of designing maintainable code using loose coupling and having high modularity. In Figure 2 we can see that OOP is on the right side of the spectrum, meaning that no paradigm expresses the state of the program more than OOP, this is combined with named states and closures. 2.1.4. Declarative programming Where imperative programming focuses on state changes, declarative programming focuses on specifying the problem that has to be solved. This can either be expressed as a set of logical or mathematical rules that describe what the desired outcome is. The result of this is an implementation that has a higher level of abstraction. The benefit of this is that code is much more readable and easier to understand. This improves the time one needs to write a program. The drawback of this is that declarative programming usually is not properly optimised requiring lots of resources. 2.1.5. Functional programming Functional programming (FP) is a paradigm that uses functions to make computations. This approach for programming is based on lambda calculus, which is a mathematical theory about functions developed in the 1930s [13]. A program is defined as a function call, where each function in its turn also calls other functions. One of the most significant characteristics of functional programming is that the functions avoid altering the state of the program and do not contain side efects. This can also be categorised as functional purity. A function is only pure if it does not alter the state of a program.
One of the strengths of FP is the high modularity of the programs [6]. Due to the high modularity, it is easy to define new components (functions in this case), without changing the functionality. This high modularity is possible with the introduction of higher-order functions and lazy evaluation, but more on this in subsection 2.3. The completely diferent approach of functional programming complements object-oriented programming enabling diferent approaches and implementations. More on these diferences in subsection 2.3.
With the various wildly diferent programming
paradigms explained, we can also support more than one
paradigm in one language, and these languages are called
multi-paradigm languages. Within a multi-paradigm
language, the first paradigm is considered to be the
paradigm that is most frequently targeted by the
language to solve a problem. The second paradigm is
chosen to support abstraction and add modularity to the
language [
there exist diferent kinds of programming constructs. Both object-oriented programming and functional programming are based on a set of concepts. We will list the diferent concepts for both object-oriented programming and functional programming. 2.3.1. Object-oriented programming In object-oriented programming, there are a few core concepts that are inherently OOP. These core concepts of object-oriented programming are as follows [12]: • Encapsulation: In OOP classes are used to encapsulate data and methods that function on this data. This is then used to protect private information and only expose the things that should be available publicly. • Inheritance: Classes can inherit, partially, the functionality of other classes. The depth of inheritance is limitless. Inheritance enables code reuse, as the subclass can reuse the code of the superclass, and also provides a way to extend and modify existing classes without having to rewrite them from scratch. With this, a hierarchy of classes can be established where subclasses can extend the functionality of a superclass. This makes code more modular and better maintainable. A simple example of inheritance can be explained as follows. The class Dog extends the class Animal. The class Animal has a method eat() which the class Dog inherits and can also call this function. The function for Dog has the same behavior as with an object of class Animal. Additionally, Dog contains a method that Animal does not have namely bark(). • Polymorphism: This describes the concept that allows objects of a diferent type to be treated as if they are the same. Think of a class Dog and a class Cat that extend a class Animal. Animal contains a method getName() with a standard implementation. Both Dog and Cat class overrides the implementation of Animal. 2.3.2. Functional programming
culus [13]. In this paradigm, programs are constructed by the application and composition of functions. All functional programming examples are written in Haskell to display what pure functional programming looks like. The main concepts of functional programming are deifned as follows[6]: • First class & Higher-order functions: Within functional programming functions serve as a first-class citizen, meaning that they can serve as a variable, be passed on as arguments to other functions, or be the return value of a function. These functions that take functions as arguments are called higher-order functions. An example of a higher-order function is the function map. map takes a function and applies this function to each element in a list. An example usage of a higher order function can be seen in Listing 1.
addOne : : (Num a ) => [ a ] −>
[ a ]
addOne x s = map ( + 1 ) x s
addOne [
[
o n e s : : [ I n t ] o n e s = 1 : o n e s While these are the core concepts for functional programming, there are still other concepts that are used in functional programming. • Anonymous functions: an anonymous func- becomes more blurry once combining multiple contion is a function that does not carry a name. Such structs. This is something that will be researched in the functions can not be referenced by other parts of final project. Still, it is important to know which concepts the code. The functions serve as a way to write are supported by the three languages that we will use for compact code that is only required for parts of our research: C#, Java, and Scala. The current support of the code. functional programming concepts is listed in Table 1. • Currying: Currying is a technique in functional programming that allows the transformation of Language support a function that takes multiple arguments into Recursion Ja1va Sc2ala C1.#0 Ko1t.l0in a sequence of functions that each take a sin- Referential transparency 1 2 1.0 1.0 gle argument. Currying is named after mathe- Higher-order functions 8 2 1.0 1.0 matician Haskell Curry, who used the concept First-class functions 8 2 1.0 1.0 extensively in the 20th century. With the in- Anonymous functions 8 2 3.0 1.0 troduction of currying, another functional pro- LCauzryryeivnagluation 88 22 33..00 11..00 gramming concept becomes available namely Pattern matching 7 2 7.0 1.0 Partial application. Partial application 8 2 7.0 1.0 • Partial application: Partial application Table 1 refers to fixing a number of arguments of a func- Functional programming support OOP languages tion resulting in another function that takes fewer arguments. This becomes possible when combining both currying and higher-order functions, While all of the languages do support referential transwhere functions can also serve as variables. In parency this is heavily dependent on the methods/functhe Listing 4 function add takes two arguments, tions. As we defined it before for something to be refernamely the two numbers that need to be added. entially transparent, you should be able to interchange The function addOne on the other hand returns a a method for the value it returns without altering the function that only takes 1 argument. The function outcome of the program. This is still possible in all three returns the function add where its first argument of the languages but is only partially supported since is already fixed to one. none of the languages is pure. So they do support it, but only in a limited fashion. Therefore, a maintainer must Listing 4: Lazy evaluation example in Haskell be very careful when writing/altering code and check for purity and immutability. All the other constructs are o n e s : : (Num a ) => a −> a −> supported, where things such as currying for C# and Java a need to be very explicit while Scala is much closer to lanadd x y = x + y guages like Haskell, where it is the standard. But this is because Scala difers from C# and Java in how functions addOne => (Num a ) => ( a −> are used. In both Java and C# they have to be explicitly a ) encapsulated by a Function construct, while in Scala they addOne = add 1 are completely regarded as just a variable, without needing such a construct. The following Listings display the diference in how functions work for the languages and how currying looks.
v a l sum : ( I n t , I n t ) => I n t = ( x , y ) => x + y v a l c u r r i e d S u m : I n t => I n t =>
I n t = x => y => x + y v a l c u r r i e d S u m 2 : I n t => I n t =>
I n t = sum . c u r r i e d v a l addOne : I n t => x => x + 1 • Pattern matching: With pattern matching, it is possible to distinguish the behaviour of a function based on which patterns the input matches. This allows comparing values against certain patterns which then influence the outcome of the function call. Listing 2 shows an example of pattern matching. It distinguishes two patterns, namely the empty list or a list with at least one element. Using this structure it is possible to clearly distinguish cases and allow for readable recursive code to be developed. 2.3.3. Multi-paradigm constructs
are clear with singular usage, but the expected behaviour
Listing 6: Functions in Java F u n c t i o n < I n t e g e r , I n t e g e r > Add = ( u , v ) −> u + v ; F u n c t i o n < I n t e g e r , F u n c t i o n <
I n t e g e r , I n t e g e r >> c u r r y A d d = u −> v −> u + v ; F u n c t i o n < I n t e g e r , I n t e g e r > > curryAddOne = c u r r y A d d . a p p l y ( 1 ) ;
Func < i n t , i n t , i n t > add = ( a , b ) => a + b ; Func < i n t , i n t , Func < i n t , i n t >
a d d C u r r = a => b => a + b ; Func < i n t , i n t > ad dC ur rO n e =
a d d C u r r ( 1 ) ;
Lastly, pattern matching for all four of the languages is possible, but not in the way pure functional programming languages use it. In all three instances, it can be achieved through a switch or case statement that describes the diferent kinds of patterns possible. Now combining these functional programming constructs into an object-oriented environment increases the versatility of solutions. While on the surface this does look like a good addition, it is important to ask the question of whether the code remains maintainable. Combing multiple paradigms into one piece of code could reduce the ability to understand the code. Less understandable code leads to higher maintenance costs since it takes up more time.
As mentioned in the introduction we distinguish two diferent cases of multi-paradigm usages namely: parallel usage and mixed usage. The aim of our research is to focus on the mixed usage of multi-paradigm code since we expect the highest change in code comprehension here. Code that separates the usage of OOP and FP is able to be analysed using single paradigm metrics [14, 15]. This gives a better understanding of the quality of the code. When mixing the two paradigms in the code there no longer is a clear separation of paradigms and we expect that it requires additional reasoning of the maintainer to try to comprehend the code, and is therefore something to research.
We have now discussed the diferent kinds of paradigms and the constructs that they use. While the chosen language influences the efectiveness of a solution other factors determine whether the produced software is of a good quality. Assessing the quality of software is therefore an important part of a development cycle. To assess the quality of software there is the process of Software Quality Assurance (SQA) that ensures that software products meet the specified quality standards and requirements. SQA stems from early ideas in the ’50s and has since undergone subsequent extensive exploration and research [16]. During this time it became more apparent that there was a need for quality assurance. In the years thereafter more research on quality assurance was performed. Some areas that were explored were software inspections [17, 18], software testing [19], and many other factors that are more aimed at software processes than just the code itself. Later on, a handbook describing all aspects of SQA came out with extensive descriptions [20]. While many aspects are covered, we are interested in software quality. The ideology regarding software quality is described in a standard [5]. It describes eight characteristics that influence the quality of a software product: functional suitability, performance eficiency, compatibility, usability, reliability, security, maintainability, and portability. When looking specifically at the influence of quality on maintenance tasks, compatibility, maintainability, and portability remain. We will take a closer look into maintainability and what it is influenced by.
Maintainability is defined as the "degree of efectiveness and eficiency with which a product or system can be modified by the intended maintainer"[ 5]. So the focus heavily lies on the degree a maintainer is afected by the quality of code. The standard describes five subcharacteristics that fall under maintainability.
• Modularity: Modularity is the degree to which distinct components impact other components.
Higher modularity means that components are less dependent on the functionality of other components. Higher modularity makes it easier to maintain and replace single components and makes it easier to oversee the project. • Reusability: Reusability is the degree to which can be used in more than one system. By making code as general as possible it becomes possible to reuse code in other systems or other parts of the code. By doing so similar functionality is all in one place making it easier to maintain. • Analysability: Analysability is the degree of effectiveness and eficiency in the assessment of the impact of a system of intended changes, or diagnose deficiencies in a system. This is a very important part for maintainers, when unable to analyse code it becomes impossible to identify errors in the code or even reason about its be- to little research aimed at understanding the impacts of haviour. combining multiple paradigms. • Modifiability: Modifiability is the degree to which a product can be changed without introducing 3.3. Comprehension Strategies defects or decreasing the quality of the existing product. In order to modify a program a main- Comprehending code has one goal and that is to undertainer must be able to reason about the code and stand the purpose of the code. Although it may appear obunderstand its behavior. vious and straightforward, the process of comprehending • auto: Testability is the degree to which test crite- code varies among individuals, as each person employs ria can be established for a system and tests can their own unique comprehension strategy. Multiple comestablish whether the criteria are met. Without prehension strategies exist, each approaching the task of testing, it is harder to assess the correctness of a comprehension in distinct ways. program. Therefore, is an important aspect that influences the ability of a maintainer to perform 3.3.1. Bottom-up its tasks.
3.3.2. Top-down
While each characteristic focuses on diferent aspects posed by Mayer et al [23], encourages a step-by-step apand impacts on the maintainer there is a common ground proach to comprehension. This strategy involves reading for most of them. We identify an underlying and recur- the source code and mentally grouping the low-level softring pattern that is required for a maintainer. A main- ware components into higher-level abstractions. These tainer needs to be able to reason about the code and abstractions serve as "chunks" to construct a compreunderstand its behaviour. This is especially prominent in hensive understanding of the program. The primary the Modularity, Analysability, and Modifiability. Without objective of this strategy is for programmers to develop an understanding of a program, a maintainer is unable an internal representation of the program, focusing on to perform its tasks and is therefore an important and grasping its underlying concepts rather than memorising noteworthy aspect of quality assurance. the syntax of the code. As additional layers of comprehension are added, this internal representation is expanded and refined. • top-down strategy • bottom-up item strategy • knowledge-based strategy • Systematic/As-Needed Strategy • Latent Semantic Analysis Strategy
plement of the bottom-up strategy. The top-down strategy starts with gaining a high-level understanding of the program [24]. Brooks describes the top-down strategy as
In the previous section, the significance of compre- a hypothesis-driven strategy. General hypotheses keep hending code was highlighted as an essential aspect of being refined as more information is extracted from the a maintainer’s responsibilities. This comprehension, re- source code and its documentation. Once the high-level ferred to as program comprehension, entails the process understanding is established, maintainers narrow their through which software engineers gain an understanding attention to specific sections of the code that are relevant of a software system’s behaviour by primarily referenc- to their comprehension goals. They proceed by delving ing the source code [21]. While program comprehen- into lower-level details, such as individual functions or sion encompasses a broader scope, code comprehension code blocks, to understand the implementation specifics specifically concentrates on comprehending smaller com- and how they contribute to the overall behavior. ponents of the software system rather than the system as a whole. Code comprehension can therefore be seen 3.3.3. Knowledge-based as a part of the entire program comprehension process.
Furthermore, program comprehension has been recog- A bottom-up strategy and a top-down strategy are not nised as a substantial component of maintenance costs, mutually exclusive and are generally used both while accounting for a considerable portion ranging from 50% comprehending programs [25]. Letovsky describes a to 90% of these expenses [22] For this reason, it is clear mental model that contains the programmer’s knowlthat code comprehension plays a central role in maintain- edge base which represents the current understanding ing code and thus code quality. While there is a dedicated of the code, this model is then actually built using an conference regarding program comprehension, there is assimilation process. This process shows how the evostill little research focusing on the program comprehen- lution of the mental model uses both bottom-up and sion side of multi-paradigm languages. Part of this is due top-down comprehension strategies. The bottom-up and top-down strategies for program comprehension are not mutually exclusive and are commonly employed together.
According to Letovsky, a knowledge-based comprehension strategy involves the creation of a mental model that represents the programmer’s current understanding of the code. This mental model is constructed through an assimilation process that incorporates elements of both bottom-up and top-down comprehension strategies. As the mental model evolves, both strategies contribute to its development, allowing for a comprehensive understanding of the code.
minor group of indicators of poor code quality. This 3.3.4. Systematic smaller group is called code smells and was first introduced by Beck & Fowler [7]. They describe these poor The systematic comprehension strategy is a methodi- code constructs as pieces of code that start to smell due cal approach to program comprehension described by to a higher likeliness of containing faults. Code smells Littman et al [26], where maintainers follow a predefined describe certain characteristics and smaller patterns in and structured process to understand the software sys- code that could lead to bugs. A few examples of code tem. By tracing the flow of data through the program, smells as defined by Beck & Fowler are: maintainers gain insights into the sequence of steps the program takes and how these steps are interconnected.
This systematic tracing allows maintainers to map the behaviour of the entire program. This is therefore, a more useful strategy for larger projects and much less for projects with a smaller codebase. • God Object: A large class or module that contains too much functionality becomes very complex.
These classes are much harder to maintain due to their high complexity and size. • Spaghetti code: This is the type of code that has its functionality and behaviour tangled into multiple classes without keeping any structure. This is the type of code that is dificult to understand as it is not always clear what its actual functionality is. • Duplicate code: Identical code or almost identical code snippets that appear in multiple places.
These pieces could be extracted to a single method to centralise their functionality. • Long method: These are methods that are large in size. The large size is usually an indication that it carries a lot of functionality and inherently becomes more complex and harder to maintain.
It is suggested to refrain from having methods that contain more than one purpose and separate functionality amongst the methods. • Large parameter list: A method containing a lot of parameters becomes dificult to use and might become inconsistent. Using fewer parameters makes a method more readable and easier to understand. 3.3.5. As-needed
Littman et al [26], presents a dynamic approach to program comprehension, where maintainers purposely concentrate on particular code segments and details while performing maintenance tasks. This strategy is guided by the direct need to understand specific aspects of the code, prioritising relevance and significance. Rather than adhering to a predetermined top-down or bottom-up sequence, maintainers adjust their comprehension eforts according to the code’s context and complexity, addressing specific requirements as they are encountered.
indications on how to solve them, code smells are more subjective and indicators of potential problems. Within 3.4. Code smells and anti-patterns just a single paradigm, a large amount of both antipatterns and code smells are defined and recognised.
All projects strive to deliver high-quality software. This This is not necessarily the case for the combination of high quality is achieved through set design patterns that multiple paradigms. There is some research focusing help structure the code. While the goal is to always on multi-language anti-patterns and code smells, but as write high-quality software, in practice this is not feasible. it highlights this is more focused on bad practices conBad code gets injected decreasing its quality and the centrated on the communication between two language ability for a maintainer to understand it. The decrease components of a system [28]. For a multi-paradigm enoriginates from bad designs and patterns. These poorly vironment within one language, there is still a lot to designed patterns are also called anti-patterns and Brown explore. Therefore, this research aims to identify code defined 40 diferent of these anti-patterns [ 27]. For each smells based on program comprehension. Poor program of the anti-patterns, its consequences and the solution comprehension can be the cause of the presence of one to resolve the patterns are proposed. Two well-known or more code smells/anti-patterns [29]. anti-patterns are:
objective conclusions based on measurable facts. This data is often acquired through means such as surveys, exThe primary objective of our project is to provide valu- periments, observations, and measurements. Examples of able insights into the influence of multi-paradigm usage quantitative data include age, height, weight, test scores, on code comprehension by performing a user study. This sales figures, and occurrence counts. Relating quantitachapter covers the process of designing the human study. tive data to research on code comprehension there are We begin by discussing the established requirements and some measurements that should be taken into account. essential components necessary for the study. Addition- When comparing diferent things and their efect on comally, we explore existing research on the design and cus- prehension, standard things to measure are, correctness tomisation of human studies for code comprehension and time to complete. through a thorough literature review, which serves as Correctness refers to the correctness of an answer the foundation for informed decision-making throughout given by a participant, may it be an open answer or the study design process. Following the literature review, a closed one. Correctness is measured using the two we present the design of the human study, articulating options correct or incorrect, in analyses this is usually the chosen methodology and the rationale behind these described with a 0 for an incorrect answer and a 1 for a design decisions. correct answer.
Time to complete refers to the time a participant re4.1. Study requirements quires to answer a question. This gives an insight into what possible factors are that could influence, positively or negatively, the time to comprehend relevant code pieces in order to answer a question.
Besides these two measurements, relevant demographic information of participants will be captured. This information can, later on, be used to distinguish diferent groups and make more specific conclusions.
The design of the study needs to meet specific conditions to ensure the results hold meaningful insights. This is essential because we want the outcomes of the study to shed light on how using multi-paradigms might afect a programmer’s code comprehension. Achieving this involves gathering data that lets us compare the experiences of diferent participants, and that’s where quantitative data comes into play. However, merely comparing numbers 4.1.2. Qualitative analysis doesn’t provide enough to make meaningful conclusions.
The heart of the matter lies in grasping the cognitive Unlike quantitative data, which is expressed in numbers, processes of participants. While we’re not just concerned qualitative data is descriptive in nature. It deals with about where participants initially focus their attention, qualities, characteristics, attributes, and subjective obserwe’re more intrigued by how they reason and progress vations. This type of data is usually captured in textual or in their thinking. This aligns well with the diverse com- narrative form, which allows researchers to better underprehension techniques discussed in subsection 3.3. But, stand the complexities of human experiences, behaviours, it’s crucial to note that these cognitive dimensions, while and perceptions. intriguing, rely on quantitative data to give weight to our Qualitative data is particularly useful for exploring nuifndings from observations that are made. That’s why ances, contexts, and underlying motivations that quanit’s crucial for the study, in whatever form it takes, to titative data may not fully capture. It helps researchers allow for both quantitative and qualitative analyses. This gain a deeper understanding of human behaviour, attidouble approach doesn’t only enhance the credibility of tudes, and cultural contexts. When contextualising this our findings but also helps us dig deeper into our un- within the scope of our research objectives, investigating derstanding. In the upcoming sections, we’ll delve into behavioural patterns concerning comprehension emerges the areas that warrant measurement within the study. as a compelling area of exploration. Measurements deThis covers both the quantitative and qualitative data scribed in the previous section can give an insight into elements. whether certain hypotheses are correct. Concentrating on the subjective observations gathered 4.1.1. Quantitative analysis during the conducted study facilitates the analysis of participants’ cognitive thinking. Therefore, the design of Quantitative data is a type of information that can be ex- the study should allow for the gathering of qualitative pressed in numerical terms and is something that can be data that entails the cognitive thinking process endured measured may it be on a scale or not. Quantitative data by the participant. It would be interesting to see whether relates to quantities, amounts, and objective measure- these observations can be linked to previously identified ments, making it ideal for mathematical and statistical potential comprehension techniques. analyses. In research and analysis, it is essential to provide empirical evidence, allowing researchers to draw
To conduct a proper and representative study on the efects of multi-paradigm programming on code comprehension, it’s important to understand how previous human studies(studies involving human participants) on program comprehension have been carried out. By examining how other studies approached comprehension, we can make informed decisions when designing our own study. It’s also of the essence to consider the goals and scope of those past studies in our analysis. the last phase, there were only exclusion criteria that were there to ensure the papers were within the scope. • papers that involved human studies spanning an extended observation period • papers that relied on eye tracking for comprehension analysis • papers whose human studies served purposes other than measuring comprehension
3 due to prolonged observation periods, 3 due to eye tracking involvement, 5 due to relevance issues, and 5 4.2.1. Selection procedure that initially seemed to contain a human study but did We collected relevant papers on this topic to review hu- not meet our criteria. Consequently, we were left with 38 man studies on program comprehension. We focused relevant papers that conducted a human study, forming on papers presented at the International Conference on the basis of our analysis.
Program Comprehension, from its 2nd to 30th editions.
Going through this substantial literature required a struc- 4.2.2. Paper Categorisation tured approach to ensure we didn’t miss any relevant papers. Our selection procedure consisted of three phases: 1. Initial Selection: We first considered all papers based on their titles to identify potentially relevant ones. If the abstract’s initial sentences weren’t clear, we read further to decide. 2. Abstract Analysis: In this phase, we carefully read the abstracts to check if the papers indeed involved human studies. If there was uncertainty, we looked for any mention of human studies in the papers themselves. 3. Inclusion Criteria Refinement: The remaining papers were examined more closely to ensure they met our specific inclusion criteria for human studies.
In order to gain useful information from the relevant 38 selected papers, it is important to establish factors we can use in order to analyse usefulness per study type. We have established a few aspects that are written down and summarised per paper. The information that we have extracted from the papers contains the following: • The kind of human study that was performed. • Whether the study was performed online or in a
physical session. • The number of human participants and whether
they were professionals or students (or both) • Amount of diferent participant groups.
• The essence and conclusion of the paper.
Each phase had its own set of inclusion and exclusion the papers with each other from. From the extracted criteria. In the initial phase, we focused on inclusive fac- information, we deduced four diferent categories that tors derived from the papers’ titles, without any specific help put the performed human studies into perspective. exclusion criteria. The inclusion criteria consisted of the Additionally, it has been decided not to put the purpose following points: of the papers into a category as this required too much of a subjective analysis, but the goal of the papers is not • title contains words: empirical/case/explorato- completely disregarded in the process of identifying the ry/human/quantitative/qualitative study most suitable study form to study the impact on code • title indicates an impact on comprehension or comprehension in a multi-paradigm environment. Each understanding category is briefly explained including our view on the • indicating a diference between two or more per- importance of the category.
spectives
166 papers. As mentioned before, the inclusion criteria for the second phase is the inclusion of a human study.
Additionally, there was one exclusion criterion namely: it should not be a paper regarding a tool. Papers regarding their build tool are not regarded to be the relevant types of papers we are looking for, so these types of papers were excluded after this. This left us with 53 papers. In Study size The first characteristic to be considered in designing a meaningful human study for code comprehension is the size of the participant pool. This gives an indication of what acceptable sizes are for program comprehension studies. The sizes of participant pools ranged from, only a couple of participants that were closely monitored by the researchers to wide-scale surveys that amassed more than 250 respondents(are 2 references necessary?). In order to distribute the papers into diferent categories, we established three size categories: small studies (1–20), medium studies(21–50), and large studies(50+). The distribution of this can be found in Table 2.
Small Medium Large of tasks. These observations are typically coupled with a "thinking-aloud" approach to document sessions. While human interaction exists, the emphasis is not on active engagement but rather on passive observation of participants’ behaviours.
The categorization of the papers can be found in Table Study type While the overarching goal of various studies centres around examining diferent aspects of program comprehension, there exists a diversity of requirements that drive distinct execution methodologies. These variances in necessities give rise to various modes of 4.3. Findings study execution. Classifying the diferent forms of human studies is, therefore, an additional dimension to be In investigating the impact of multi-paradigm usage on considered. As we delve into the relevant papers, it be- code comprehension, various study methods come into comes evident that the spectrum of human studies can play, namely surveys, and experiments. Surveys can be boiled down to three primary categories. be conducted online, while other methods are typically
The initial category is the survey/questionnaire study, carried out in a physical setting whereas an online apwhich, as the name implies, gathers data through surveys plication is rare. Surveys ofer the advantage of gathor questionnaires. This kind of study doesn’t require ering both quantitative and qualitative data, although direct interaction between researchers and participants. sometimes yield results that may not align with initial
The second category is the experiment study. This type expectations. Interviews, as an alternative to surveys, of study requires some degree of interaction between share similar objectives but allow for more guided and participants and researchers, ranging from interviews insightful responses. involving in-depth queries to real-time tasks adminis- Survey-based studies tend to lean towards emphasising tered in the participant’s presence. Studies categorised as quantitative data collection, mainly due to the inherent experiments can incorporate surveys, but the presence nature of surveys allowing relatively unguided data gathof human interaction classifies them as an experiment. ering. This focus on quantitative aspects is partly a result
Lastly, the observation study concentrates on observ- of the survey’s structure, which can lead to results that ing participants as they undertake a predetermined set are more easily quantifiable.
For methodological feasibility and simplicity, it’s rec- qualitative insights through succinct questions. Nonetheommended not to introduce unnecessary complexities, less, soliciting qualitative data within a survey is less such as involving multiple programming languages or straightforward than collecting quantitative information. numerous variables. Instead, a practical approach in- The degree of participant guidance is constrained, even volves carefully selecting a limited number of variables when questions are deliberately framed to encourage or factors. This focused strategy aims to minimise out- qualitative responses. The resultant behaviours might side influences, preventing potential confusion caused by not conform to expectations, contributing to the unpreunrelated factors and ensuring the clarity of the study’s dictability of outcomes. outcomes. Survey implementation demands a reasonable time investment, primarily in the survey design and validation. 4.4. Study design Once this foundational step is accomplished, the only thing that remains is finding participants and motivating Several parts complete the design of the human study. them to partake in the study. It’s essential to underscore Each of these is described in the subsequent sections. the care required in survey setup, encompassing a thorAll factors and possibilities are laid out and explained ough examination of questions and choices, weighing in depth. The diferent factors and characteristics of the their respective advantages and disadvantages. Once fistudy setup are the type of study, the participants, and nalised, it no longer is feasible to alter the survey as this the study language. renders previous results useless, hence the careful and
As outlined earlier, two distinct study types align par- thorough approach in the survey design. ticularly well with the requisites of our study: interviews and surveys. Each of these methods carries its own set 4.5. Language of advantages and limitations, some of which have been previously highlighted and are reiterated here for com- Besides the study type, the selection of the programprehensive coverage. ming language significantly influences the study’s trajectory. The language choice is a multifaceted decision 4.4.1. Interviews containing two primary considerations: the number of programming languages under consideration and the Interviews ofer a robust means of guiding conversa- specific language(s) to be employed. tions and creating opportunities for seeking clarifications As previously indicated, the introduction of multiple where necessary. This inherent flexibility aligns adeptly programming languages introduces an increase in conwith our objective of capturing qualitative data of a de- founding factors. These variables demand careful mansired standard. Interviews allow participants to elaborate agement to preclude the potential invalidation of results. more extensively on specific findings, a dimension that Simultaneously, embracing multiple languages afords might be constrained within the boundaries of a survey, the potential for enriched analyses. However, for the which typically demands brevity. sake of maintaining study feasibility, the pursuit of using
Nonetheless, these advantages of the interview multiple languages, as elaborated in the Findings section, methodology are not without trade-ofs. The require- will not be pursued further. ment for individualised interview sessions, as opposed Equally vital is the selection of the programming lanto group formats, renders this approach time-intensive. guage, besides the employed study type. Considerations A statistically significant study, necessitating more than extend to factors such as the level of expertise required a mere handful of interviewees, demands a substantial for efective engagement with the chosen language. The investment of time in conducting, transcribing, and sub- languages considered are Java, Scala, C#, and Kotlin. Nosequently analysing each interview. Furthermore, the tably, Scala and Kotlin emerge as languages expressly gathered interview data requires careful processing, in designed with multi-paradigms in mind, accommodatadherence to GDPR regulations. ing both programming paradigms of functional programming and object-oriented programming. Conversely, 4.4.2. Survey Java and C# encompass functional programming conContrarily, surveys chart an entirely distinct trajectory. structs, albeit being specially used for augmenting objectEmphasising the number of participants over in-depth oriented code, particularly pronounced in Java. engagement, surveys aim to glean insights from a broad Scala, while historically significant, has witnessed a spectrum of respondents while minimising their time decline in its utilisation [10]. This could potentially be commitment. This approach yields many results under- attributed to its steep learning curve. It is pertinent to scored by versatility. Although surveys excel in collecting underscore that within the organisational framework of quantitative data, they possess the capacity to capture Info Support, the research’s host institution, and the University of Twente, Scala’s popularity remains minimal.
Java and C#, on the other hand, are in development lent programming practices becomes unavailable. While practices within Info Support, presenting a substantial familiarity with Kotlin is expected among participants, participant pool. Moreover, Java holds prominence as the proficiency in writing active code in it is not mandaeducational programming language at the University of tory. A basic understanding of Java serves as a suficient Twente, rendering it an avenue for student recruitment. foundation, with the provision for a brief introduction to
Finally, the inclusion of Kotlin deserves discussion. Kotlin’s syntax and features, if necessary. Despite its limited usage at the University of Twente Crucially, the interview questions are formulated in and Info Support, its alignment with Java’s syntax and such a way they can be answered without requiring code concepts renders it accessible. This facilitates the compre- alteration. This allows for an equal task for each partichension of Kotlin by those acquainted with Java. Kotlin ipant and excludes individual coding capabilities. The may serve as an exploratory tool for measuring partic- primary focus of these questions is rooted in compreipants’ cognitive processes in a semi-unfamiliar envi- hending code and unearthing its underlying purpose. ronment. Such exploration enables the observation of Regarding participant demographics, a balance of stuparticipants’ reasoning and thought processes in an en- dents and professional developers is chosen. This mix vironment that remains unprejudiced by established pro- not only ensures diversity but also afords a compregramming norms. This dimension is particularly relevant hensive exploration of code comprehension in a multifor assessing the intersection of functional and object- paradigm landscape. It also ofers the opportunity to oriented programming concepts without the possible bias examine whether programming experience carries releintroduced by active development in a specific program- vance as a contributing factor. Although participants will ming style. predominantly be drawn from Info Support and the University of Twente due to their availability, recruitment is not restricted to these entities.
In light of a thorough evaluation of the advantages and
drawbacks associated with both interview and survey 5. Related Work
methodologies, coupled with the requisites of the study,
the chosen study type is interviews. Despite the time- Landkroon researched the fault prediction of the
multiintensive nature of interviews, we believe they present paradigm language Scala, it was specifically focused
the optimal avenue for capturing relevant insights into lied on the combination of functional programming and
code comprehension within this context. Gathering qual- object-oriented programming [
Given the pivotal significance attributed to capturing Briand et al. [30]. He showed that his new validation
participants’ cognitive behaviour and considering it a method could outperform Briand’s method, especially in
foundational aspect of the research, interviews emerge projects with a longer life cycle.
as the more fitting choice. This alignment aligns with Zuilhof adopted the validation method proposed by
the study’s objectives and interests. Landkroon [
It’s noteworthy that participants may still be requested guage C# that is tailored for functional programmingto complete a brief survey prior to their interview, facili- inspired constructs. This suite was then used to intating the capture of relevant demographic information. vestigate the efectiveness of using the suite to predict
Turning to the characteristic of the language within the error-proneness. The results showed an improvement
study, Scala, owing to its limited practical usage, emerges in projects with active usage of FP-inspired constructs
as less feasible for participant recruitment. The decision, against the baseline model. Konings had a similar
aptherefore, hinges on the selection between Java, C#, and proach as Zuilhof but adapted the metric suite to fit the
Kotlin. Rather than opting for the language most exten- language Scala [
In the dynamic landscape of programming languages, which has seen the continual evolution of both languages themselves and the complexity of problems they address, a notable shift has occurred. Programming languages now incorporate constructs from multiple paradigms, particularly those of object-oriented and functional programming. This blending of paradigms has introduced a challenge to what was once a clear understanding of [5] ISO/IEC 25010, ISO/IEC 25010:2011, Systems and M. Munro, Approaches to program comprehensoftware engineering — Systems and software Qual- sion, Journal of Systems and Software 14 (1991) ity Requirements and Evaluation (SQuaRE) — Sys- 79–84. tem and software quality models, Technical Report, [23] B. Shneiderman, R. Mayer, Syntactic/semantic inISO, 2011. teractions in programmer behavior: A model and [6] J. Hughes, Why functional programming matters, experimental results, International Journal of Com
The computer journal 32 (1989) 98–107. puter & Information Sciences 8 (1979) 219–238. [7] K. Beck, M. Fowler, Bad smells in code, Refactoring: [24] R. Brooks, Towards a theory of the compreImproving the design of existing code 1 (1999) 75– hension of computer programs, International 88. Journal of Man-Machine Studies 18 (1983) [8] T. Sharma, D. Spinellis, A survey on software smells, 543–554. doi:https://doi.org/10.1016/ Journal of Systems and Software 138 (2018) 158– S0020-7373(83)80031-5.
173. [25] S. Letovsky, Cognitive processes in pro[9] M. van der Arend, The LAMP Framework — A gram comprehension, Journal of SysLanguage-Agnostic Code Quality Assurance Frame- tems and Software 7 (1987) 325–339. URL: work for Multi-Paradigm Languages, Master’s the- https://www.sciencedirect.com/science/article/pii/ sis, Universiteit Twente, Enschede, The Nether- 016412128790032X. doi:https://doi.org/10. lands, 2023. URL: http://purl.utwente.nl/essays/ 1016/0164-1212(87)90032-X. 94619. [26] D. C. Littman, J. Pinto, S. Letovsky, E. Soloway, Men[10] Pypl, Pypl, https://pypl.github.io/PYPL.html, 2022. tal models and software maintenance, Journal of [11] B. Stefan L. Ram, Dr.alan kay on the meaning of Systems and Software 7 (1987) 341–355. "object-oriented programming", 2003. URL: https:// [27] W. H. Brown, R. C. Malveau, H. W. S. McCormick, www.purl.org/stefan_ram/pub/doc_kay_oop_en. T. J. Mowbray, AntiPatterns: refactoring software, [12] G. Booch, R. A. Maksimchuk, M. W. Engle, B. J. architectures, and projects in crisis, John Wiley & Young, J. Connallen, K. A. Houston, Object-oriented Sons, Inc., 1998. analysis and design with applications, ACM SIG- [28] M. Abidi, M. Grichi, F. Khomh, Y.-G. Guéhéneuc, SOFT software engineering notes 33 (2008) 29–29. Code smells for multi-language systems, in: Pro[13] A. Church, A Set of Postulates for the Foundation ceedings of the 24th European Conference on Patof Logic, Annals of Mathematics 33 (1932) 346–366. tern Languages of Programs, EuroPLop ’19, Asdoi:10.2307/1968337. sociation for Computing Machinery, New York, [14] S. Chidamber, C. Kemerer, A metrics suite for object NY, USA, 2019, pp. 1–13. URL: https://doi.org/ oriented design, IEEE Transactions on Software 10.1145/3361149.3361161. doi:10.1145/3361149. Engineering 20 (1994) 476–493. doi:10.1109/32. 3361161.
295895. [29] M. Abbes, F. Khomh, Y.-G. Guéhéneuc, G. Antoniol, [15] C. Ryder, Software metrics: measuring haskell., An empirical study of the impact of two antipat
Trends in Functional Programming (2005) 31–46. terns, blob and spaghetti code, on program com[16] F. J. Buckley, R. Poston, Software quality assurance, prehension, in: 2011 15th European Conference on IEEE Transactions on Software Engineering SE-10 Software Maintenance and Reengineering, 2011, pp. (1984) 36–41. doi:10.1109/TSE.1984.5010196. 181–190. doi:10.1109/CSMR.2011.24. [17] T. Gilb, D. Graham, Software inspections, Addison- [30] L. Briand, W. Melo, J. Wust, Assessing the applicabil
Wesley Reading, Masachusetts, 1993. ity of fault-proneness models across object-oriented [18] M. E. Fagan, Advances in software inspections, in: software projects, IEEE Transactions on Software Pioneers and Their Contributions to Software En- Engineering 28 (2002) 706–720. doi:10.1109/TSE. gineering: sd&m Conference on Software Pioneers, 2002.1019484.
Bonn, June 28/29, 2001, Original Historic Contribu- [31] B. Jacobs, C. L. M. Kop, Functional putions, Springer, 2001, pp. 335–360. rity as a code quality metric in multi[19] C. Kaner, J. Falk, H. Q. Nguyen, Testing computer paradigm languages, Master’s thesis, Radsoftware, John Wiley & Sons, 1999. boud University Nijmegen, 2022. URL: [20] G. G. Schulmeyer, Handbook of software quality https://research.infosupport.com/wp-content/ assurance, Artech House, Inc., 2007. uploads/Master_thesis_bjorn_jacobs_1.6.1.pdf. [21] K. H. Bennett, V. T. Rajlich, N. Wilde, Software [32] V. Pankratius, F. Schmidt, G. Garretón, Combining evolution and the staged model of the software functional and imperative programming for multilifecycle, in: Advances in Computers, volume 56, core software: An empirical study evaluating Scala Elsevier, 2002, pp. 1–54. and Java, in: 2012 34th International Conference [22] D. J. Robson, K. H. Bennett, B. J. Cornelius, on Software Engineering (ICSE), 2012, pp. 123–133. doi:10.1109/ICSE.2012.6227200, iSSN: 15581225. [33] F. Khomh, M. Di Penta, Y.-G. Gueheneuc, An exploratory study of the impact of code smells on software change-proneness, in: 2009 16th Working Conference on Reverse Engineering, 2009, pp.
75–84. doi:10.1109/WCRE.2009.28. [34] M. Abidi, M. Openja, F. Khomh, Multi-language design smells: A backstage perspective, in: Proceedings of the 17th International Conference on Mining Software Repositories, MSR ’20, Association for Computing Machinery, New York, NY, USA, 2020, p. 615–618. URL: https://doi.org/10.1145/3379597. 3387508. doi:10.1145/3379597.3387508.