No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Effects of Variable Names on Comprehension: An Empirical Study
... They were originally designed to be pieces of code used to represent values in memory (Tofte and Talpin, 1997) and now they have become the primary source of information in software development (Lawrie et al., 2006;Ratiu and Deissenboeck, 2006): programmers rely on existing names in their code comprehension journey (Takang et al., 1996). Indeed, high-quality names have a significant influence on the comprehension of source code (Avidan and Feitelson, 2017). Arnaoudova et al. (2016) have acknowledged the critical role that the source code lexicon plays in the psychological complexity of software systems and coined the contradictory expression "Linguistic Antipatterns" (LAs) to denote poor practices in the naming, documentation, and choice of identifiers that might hinder program understanding. ...
... There have been many studies that examine how names affect comprehension and programmer's efficiency. Avidan and Feitelson (2017) conducted an experiment involving ten programmers in hopes of understanding the impact of identifier names in program comprehension. They observed that, when changing identifiers names from fully spelled words to single-letter ones, the fully spelled version was perceived as more understandable. ...
... Moreover, whether the Type name changes, then the identifier names will be misleading as in cases such as string and type. According to Avidan and Feitelson (2017), the evil face of names is misleading names. ...
Currently, research indicates that comprehending code takes up far more developer time than writing code. Given that most modern programming languages place little to no limitations on identifier names, and so developers are allowed to choose identifier names at their own discretion, one key aspect of code comprehension is the naming of identifiers. Research in naming identifiers shows that informative names are crucial to improving the readability and maintainability of programs: essentially, intention-revealing names make code easier to understand and act as a basic form of documentation. Poorly named identifiers tend to hurt the comprehensibility and maintainability of software systems. However, most computer science curricula emphasize programming concepts and language syntax over naming guidelines and conventions. Consequently, programmers lack knowledge about naming practices. This article is an extension of our previous study on naming practices. Previously, we set out to explore naming practices of Java programmers. To this end, we analyzed 1,421,607 identifier names (i.e., attributes, parameters, and variables names) from 40 open-source Java projects and categorized these names into eight naming practices. As a follow-up study to further investigate naming practices, we examined 40 open-source C++ projects and categorized 1,181,774 identifier names according to the previously mentioned eight naming practices. We examined the occurrence and prevalence of these categories across C++ and Java projects and our results also highlight in which contexts identifiers following each naming practice tend to appear more regularly. Finally, we also conducted an online survey questionnaire with 52 software developers to gain insight from the industry. All in all, we believe the results based on the analysis of 2,603,381 identifier names can be helpful to enhance programmers’ awareness and contribute to improving educational materials and code review methods.
... A possible solution is to use code from utility libraries (e.g. performing array or string operations) (Avidan and Feitelson 2017), or to otherwise ensure that domain knowledge is not required. ...
... A striking example of the effect of misleading names was given by Avidan and Feitelson (2017). In a study about variable naming they used 6 real functions from utility libraries. ...
... For example, one could use num1 and num2 instead of base and exponent in a function that calculates a power ). -Perhaps the simplest and most straightforward approach is to just use consecutive letters of the alphabet in order of appearance (Avidan and Feitelson 2017;Hofmeister et al. 2019). Note that this is different from using the first letter of the "good" name, as that may still convey information (Beniamini et al. 2017). ...
Understanding program code is a complicated endeavor. As a result, studying code comprehension is also hard. The prevailing approach for such studies is to use controlled experiments, where the difference between treatments sheds light on factors which affect comprehension. But it is hard to conduct controlled experiments with human developers, and we also need to find a way to operationalize what “comprehension” actually means. In addition, myriad different factors can influence the outcome, and seemingly small nuances may be detrimental to the study’s validity. In order to promote the development and use of sound experimental methodology, we discuss both considerations which need to be applied and potential problems that might occur, with regard to the experimental subjects, the code they work on, the tasks they are asked to perform, and the metrics for their performance. A common thread is that decisions that were taken in an effort to avoid one threat to validity may pose a larger threat than the one they removed.
... On the other hand, some studies required the subjects to act on the code. In ten studies subjects were asked to find [7], [8], [12], [13], [16], [21], [43]- [45], [47]- [55] answer questions about code characteristics 27 studies: [1], [2], [5], [6], [9], [10], [19], [20], [41]- [43], [46], [47], [50], [51], [54]- [65] remember (part of) the code 7 studies: [8], [9], [43], [44], [48], [52], [53] act on the code (15 studies) find and fix bugs in the code 10 studies: [11], [13]- [15], [19], [21], [45], [46], [66], [67] modify the code 8 studies: [10], [13], [45], [46], [56], [62], [66], [67] write code 3 studies: [61], [62], [68] provide personal opinion (30 studies) opinion about the code (readability or legibility) 23 studies: [3]- [5], [10], [12], [13], [22], [45], [49], [55], [59], [61], [62], [64], [65], [67]- [74] answer if understood the code 4 studies: [42], [55], [59], [60] rate confidence in her answer 3 studies: [8], [20], [53] rate the task difficulty 7 studies: [5], [10], [20], [21], [45], [49], [51] and fix bugs in the code. Scanniello et al. [11] asked subjects to do so in two programs with different identifier styles. ...
... On the other hand, some studies required the subjects to act on the code. In ten studies subjects were asked to find [7], [8], [12], [13], [16], [21], [43]- [45], [47]- [55] answer questions about code characteristics 27 studies: [1], [2], [5], [6], [9], [10], [19], [20], [41]- [43], [46], [47], [50], [51], [54]- [65] remember (part of) the code 7 studies: [8], [9], [43], [44], [48], [52], [53] act on the code (15 studies) find and fix bugs in the code 10 studies: [11], [13]- [15], [19], [21], [45], [46], [66], [67] modify the code 8 studies: [10], [13], [45], [46], [56], [62], [66], [67] write code 3 studies: [61], [62], [68] provide personal opinion (30 studies) opinion about the code (readability or legibility) 23 studies: [3]- [5], [10], [12], [13], [22], [45], [49], [55], [59], [61], [62], [64], [65], [67]- [74] answer if understood the code 4 studies: [42], [55], [59], [60] rate confidence in her answer 3 studies: [8], [20], [53] rate the task difficulty 7 studies: [5], [10], [20], [21], [45], [49], [51] and fix bugs in the code. Scanniello et al. [11] asked subjects to do so in two programs with different identifier styles. ...
... Santos and Gerosa [73] presented pairs of functionally equivalent snippets to the subjects and asked them to choose which one they think is more readable or legible. Stefik and Gellenbeck [72] requested that subjects rate lists of words/symbols associated to programming constructs (e.g., conditionals and loops) based on how intuitive [10], [20], [21], [45], [49], [51] Time (27 studies) Time to complete task 20 studies: [2], [5], [7], [10], [11], [13]- [16], [41], [43], [45], [46], [49], [55], [57], [64]- [67] Time reading code 5 studies: [12], [21], [42], [43], [ [20] they think they are. Lawrie et al. [8] asked the subjects to rate their confidence in their understanding of the code. ...
Reading code is an essential activity in software maintenance and evolution. Several studies with human subjects have investigated how different factors, such as the employed programming constructs and naming conventions, can impact code readability, i.e., what makes a program easier or harder to read and apprehend by developers, and code legibility, i.e., what influences the ease of identifying elements of a program. These studies evaluate readability and legibility by means of different comprehension tasks and response variables. In this paper, we examine these tasks and variables in studies that compare programming constructs, coding idioms, naming conventions, and formatting guidelines, e.g., recursive vs. iterative code. To that end, we have conducted a systematic literature review where we found 54 relevant papers. Most of these studies evaluate code readability and legibility by measuring the correctness of the subjects' results (83.3%) or simply asking their opinions (55.6%). Some studies (16.7%) rely exclusively on the latter variable.There are still few studies that monitor subjects' physical signs, such as brain activation regions (5%). Moreover, our study shows that some variables are multi-faceted. For instance, correctness can be measured as the ability to predict the output of a program, answer questions about its behavior, or recall parts of it. These results make it clear that different evaluation approaches require different competencies from subjects, e.g., tracing the program vs. summarizing its goal vs. memorizing its text. To assist researchers in the design of new studies and improve our comprehension of existing ones, we model program comprehension as a learning activity by adapting a preexisting learning taxonomy. This adaptation indicates that some competencies are often exercised in these evaluations whereas others are rarely targeted.
... The main consideration in favor of a limited scope is in cases where such a scope corresponds to the focus of the study. For example, when investigating the effect of the names of parameters on the understanding of a function, it is natural to use complete functions [3]. If investigating control structures, focused snippets containing a single program element reduce confounding effects. ...
... If experimental subjects in code comprehension experiments lack this knowledge, they will be unable to understand the code. A possible solution is to use code from utility libraries [3], or to otherwise ensure that domain knowledge is not required. ...
... A striking example of the effect of misleading names was given by Avidan and Feitelson [3]. In a study about variable naming they used 6 real functions from utility libraries. ...
Understanding program code is a complicated endeavor. As such, myriad different factors can influence the outcome. Investigations of program comprehension, and in particular those using controlled experiments, have to take these factors into account. In order to promote the development and use of sound experimental methodology, we discuss potential problems with regard to the experimental subjects, the code they work on, the tasks they are asked to perform, and the metrics for their performance.
... Problematic situations include mismatch of type, number, or behavior (e.g. a 'set' method that returns a value). Avidan and Feitelson have shown that misleading identifier names are worse than meaningless names like consecutive letters of the alphabet, as they may lead to errors in program comprehension [4]. These results emphasize the importance of identifier naming, and indicate that guidance on naming identifiers may be beneficial. ...
... The first ambiguous question concerned a library function add (a,b), and asked what would be the result of calling add( [1,2,3], [4,5,6]). The most common response by far was to understand the add operation applied to vectors as an elementwise addition, leading to a result of [5,7,9] (some making an arithmetic error). ...
... The most common response by far was to understand the add operation applied to vectors as an elementwise addition, leading to a result of [5,7,9] (some making an arithmetic error). Others understood the add operation as a concatenation, and said the result would be [1,2,3,4,5,6]. Only four noted the ambiguity and gave both options. ...
The names of variables and functions serve as implicit documentation and are instrumental for program comprehension. But choosing good meaningful names is hard. We perform a sequence of experiments in which a total of 334 subjects are required to choose names in given programming scenarios. The first experiment shows that the probability that two developers would select the same name is low: in the 47 instances in our experiments the median probability was only 6.9%. At the same time, given that a specific name is chosen, it is usually understood by the majority of developers. Analysis of the names given in the experiment suggests a model where naming is a (not necessarily cognizant or serial) three-step process: (1) selecting the concepts to include in the name, (2) choosing the words to represent each concept, and (3) constructing a name using these words. A followup experiment, using the same experimental setup, then checked whether using this model explicitly can improve the quality of names. The results were that names selected by subjects using the model were judged by two independent judges to be superior to names chosen in the original experiment by a ratio of two-to-one. Using the model appears to encourage the use of more concepts and longer names.
... Programmers tend to heavily rely on meaningful identifier names to understand source code [5], and they generally prefer a long descriptive name than single-letter variables [6]. It is also reported that poor naming can lead to misunderstanding or confusion among programmers, which eventually result in poor code quality [7]. In many software projects, inconsistent naming is often considered as a bad smell. ...
... We assume that the lack of these properties do not cause a significant loss of accuracy for our purposes in this paper. 7 Note that we do not intend to identify the functional equivalence. Two mathematically equivalent expressions (e.g. ...
Consistency is one of the keys to maintainable source code and hence a successful software project. We propose a novel method of extracting the intent of programmers from source code of a large project (~300kLOC) and checking the semantic consistency of its variable names. Our system learns a project-specific naming convention for variables based on its role solely from source code, and suggest alternatives when it violates its internal consistency. The system can also show the reasoning why a certain variable should be named in a specific way. The system does not rely on any external knowledge. We applied our method to 12 open-source projects and evaluated its results with human reviewers. Our system proposed alternative variable names for 416 out of 1080 (39%) instances that are considered better than ones originally used by the developers. Based on the results, we created patches to correct the inconsistent names and sent them to its developers. Three open-source projects adopted it.
... We should note that the snippets used in this work were small in size, and even so, the comments positively impacted source code comprehension, which contradicts Tenny (Tenny 1988), since the author states comments might be less effective at improving readability in cases of short and simple modules. Similarly, the results we could achieve in this work concerning identifier length match the majority of works in the Background section (Jørgensen 1980;DeYoung and Kampen 1979;Lawrie et al. 2006;Lawrie et al. 2007;Tashtoush et al. 2013;Avidan and Feitelson 2017;Hofmeister et al. 2017;Hofmeister et al. 2019). However, it is not possible to say why our results differ from works that see the presence of comments and the identifier length as negatively impacting source code reading and comprehension. ...
Context
Reading and understanding the source code are fundamental to supporting software programmers’ daily activities. Still, there is no agreement regarding the program attributes needed to achieve the readability and comprehensibility of source code.
Objective
To analyze the influence of comments presence, indentation spacing, identifiers length, and code size on the readability and comprehensibility of source code from the perspective of novice and experienced programmers.
Method
We performed three primary studies and collected quantitative (Likert) and qualitative data representing the programmers’ judgment regarding the readability and comprehensibility of code snippets. For each study, the influence of the four attributes on the readability and comprehensibility of source code was analyzed. The results were aggregated using the odds-ratio approach and analyzed concerning participants’ programming experience.
Results
The quality characteristics were not significantly affected (alpha = 5%) by either the indentation spacing or the code size, whereas the presence of comments and identifier length affect source code quality positively under such characteristics, according to both novices and experienced programmers.
Conclusions
Although the results presented findings with statistical significance, the controlled factors and participants’ stratification between novices and experienced were insufficient to explain the contradictory findings in the technical literature concerning the impact of the attributes under evaluation on the readability and comprehensibility of source code.
... With the success of machine learning models in the domains of natural language processing [4] and programming language analysis [5], researchers are proposing machine learning models to recover missing semantic information in binaries. These models leverage the insight that semantic information present in source code is context-dependent: variables that appear and are used in similar contexts tend to be assigned similar names and types [6]. One such approach is the DIRTY (DecompIled variable ReTYper) model proposed by Chen et al. [7], [8], which adapts the Transformer architecture to predict variable names and types in decompiler outputs. ...
Compiled binary executables are often the only available artifact in reverse engineering, malware analysis, and software systems maintenance. Unfortunately, the lack of semantic information like variable types makes comprehending binaries difficult. In efforts to improve the comprehensibility of binaries, researchers have recently used machine learning techniques to predict semantic information contained in the original source code. Chen et al. implemented DIRTY, a Transformer-based Encoder-Decoder architecture capable of augmenting decompiled code with variable names and types by leveraging decompiler output tokens and variable size information. Chen et al. were able to demonstrate a substantial increase in name and type extraction accuracy on Hex-Rays decompiler outputs compared to existing static analysis and AI-based techniques. We extend the original DIRTY results by re-training the DIRTY model on a dataset produced by the open-source Ghidra decompiler. Although Chen et al. concluded that Ghidra was not a suitable decompiler candidate due to its difficulty in parsing and incorporating DWARF symbols during analysis, we demonstrate that straightforward parsing of variable data generated by Ghidra results in similar retyping performance. We hope this work inspires further interest and adoption of the Ghidra decompiler for use in research projects.
... Names bear witness to what the developer thought about the role of each part of code in the whole program [26]. There has therefore been substantial research on names and their meanings [3,4,9,10,11,13,16,18,21,23,27]. ...
Program code contains functions, variables, and data structures that are represented by names. To promote human understanding, these names should describe the role and use of the code elements they represent. But the names given by developers show high variability, reflecting the tastes of each developer, with different words used for the same meaning or the same words used for different meanings. This makes comparing names hard. A precise comparison should be based on matching identical words, but also take into account possible variations on the words (including spelling and typing errors), reordering of the words, matching between synonyms, and so on. To facilitate this we developed a library of comparison functions specifically targeted to comparing names in code. The different functions calculate the similarity between names in different ways, so a researcher can choose the one appropriate for his specific needs. All of them share an attempt to reflect human perceptions of similarity, at the possible expense of lexical matching.
... Bad variable names are also a clear example of code technical debt. A variable whose name poorly describes its purpose will make the code less readable, which means that any time a piece of code needs to be understood, e.g., during refactoring, the process will be conceptually harder [42], [43], and hence, slower. This extra time (and associated development costs) constitute the interest payment that characterizes TD. ...
Context: The term technical debt (TD) describes the aggregation of sub-optimal solutions that serve to impede the evolution and maintenance of a system. Some claim that the broken windows theory (BWT), a concept borrowed from criminology, also applies to software development projects. The theory states that the presence of indications of previous crime (such as a broken window) will increase the likelihood of further criminal activity; TD could be considered the broken windows of software systems. Objective: To empirically investigate the causal relationship between the TD density of a system and the propensity of developers to introduce new TD during the extension of that system. Method: The study used a mixed-methods research strategy consisting of a controlled experiment with an accompanying survey and follow-up interviews. The experiment had a total of 29 developers of varying experience levels completing a system extension tasks in an already existing systems with high or low TD density. The solutions were scanned for TD. Six subjects participated in follow-up interviews, where the results were analyzed using thematic analysis. Result: The analysis revealed significant effects of TD level on the subjects' tendency to re-implement (rather than reuse) functionality, choose non-descriptive variable names, and introduce other code smells, all with at least 95% credible intervals. Additionally, the developers appeared to be, at least partially, aware of when they had introduced TD. Conclusion: Three separate significant results along with a validating qualitative result combine to form substantial evidence of the BWT's applicability to software engineering contexts. Existing TD has a major impact on developers propensity to introduce new TD of various types during development. While mimicry seems to be part of the explanation it can not alone describe the observed effects.
... Several studies also assess what affects code readability, understandability, and maintainability (e.g., [5,7,10,14,18,19,20,29]) and complexity (e.g., [1]). Börstler et al. [8] also carried out an exploratory study focusing on understanding code quality. ...
Context: Writing Clean Code understandable by other collaborators has become crucial to enhancing collaboration and productivity. However, very little is known regarding whether developers agree with Clean Code Principles and how they apply them in practice.\\ Objectives: In this work, we investigated how developers perceive Clean Code principles, whether they believe that helps reading, understanding, reusing, and modifying Clean Code, and how they deal with Clean Code in practice. Methods: We conducted a Systematic Literature Review in which we considered 771 research papers to collect Clean Code principles and a survey among 39 practitioners, some of them with more than 20 years of development experience.\\ Results: So far, the results show a shared agreement with Clean Code principles and its potential benefits. They also show that developers tend to write messy code to be refactored later.
... Programmers generally prefer a long descriptive name than single-letter variables [10]. Poor naming can lead to misunderstanding or confusion among programmers, which eventually result in poor code quality [11]. In some software projects, inconsistent naming is actually considered as bugs (naming bugs [12]). ...
We investigated how programmers express high-level concepts such as path names and coordinates using primitive data types. While relying too much on primitive data types is sometimes criticized as a bad smell, it is still a common practice among programmers. We propose a novel way to accurately identify expressions for certain predefined concepts by examining API calls. We defined twelve conceptual types used in the Java Standard API. We then obtained expressions for each conceptual type from 26 open source projects. Based on the expressions obtained, we trained a decision tree-based classifier. It achieved 83% F-score for correctly predicting the conceptual type for a given expression. Our result indicates that it is possible to infer a conceptual type from a source code reasonably well once enough examples are given. The obtained classifier can be used for potential bug detection, test case generation and documentation.
... Ajami et al. (2019) measured the time it took experimental subjects to answer questions related to code snippets, and showed, among other results, that loops are harder to understand than conditional statements. Other studies performed controlled experiments to measure the impact that trace visualization (Cornelissen et al. 2011), reactive programming (Salvaneschi et al. 2017), the naming of variables (Beniamini et al. 2017;Avidan and Feitelson 2017), or UML object diagrams (Torchiano et al. 2017) have on program comprehension. ...
Program comprehension accounts for a large portion of software development costs and effort. The academic literature contains mainly research on program comprehension of short code snippets, but comprehension at the system level is no less important. We claim that comprehending a software system is a distinct activity that differs from code comprehension. We interviewed experienced developers, architects, and managers in the software industry and open-source community, to uncover the meaning of program comprehension at the system level; later we conducted a survey to verify the findings. The interviews demonstrate, among other things, that system comprehension is largely detached from code and programming language, and includes scope that is not captured in the code. It focuses on one hand on the structure of the system, and on the other hand on the flows in the system, but less on the code itself. System comprehension is a continuous, unending, iterative process, which utilizes white-box and black-box approaches at different layers of the system depending on needs, and combines both bottom-up and top-down comprehension strategies. In summary, comprehending a system is not just comprehending the code at a larger scale, and it is not possible to comprehend large systems at the same level as comprehending code.
... Arnaoudova et al. investigated renaming of variables, and showed that renamings most often modify the meaning of the names [2]. A possible explanation for this is provided by Avidan and Feitelson, who show that names may be misleading to the point of being worse that meaningless names like consecutive letters of the alphabet [3]. All these works testify to the difficulty of finding good names that will convey the desired meaning without any ambiguity. ...
Intermediate variables can be used to break complex expressions into more manageable smaller expressions, which may be easier to understand. But it is unclear when and whether this actually helps. We conducted an experiment in which subjects read 6 mathematical functions and were supposed to give them meaningful names. 113 subjects participated, of which 58% had 3 or more years of programming work experience. Each function had 3 versions: using a compound expression, using intermediate variables with meaningless names, or using intermediate variables with meaningful names. The results were that in only one case there was a significant difference between the two extreme versions, in favor of the one with intermediate variables with meaningful names. This case was the function that was the hardest to understand to begin with. In two additional cases using intermediate variables with meaningless names appears to have caused a slight decrease in understanding. In all other cases the code structure did not make much of a difference. As it is hard to anticipate what others will find difficult to understand, the conclusion is that using intermediate variables is generally desirable. However, this recommendation hinges on giving them good names.
... Attention has also been given to the quality of names, and to how naming relates to the cognitive processes involved in program comprehension [29], [25]. Several studies have dealt with bad names and their ill-effects on comprehension [3], [5], [26], including due to cognitive load [17]. Bad names have also been linked with low code quality in general [13], [2]. ...
Variable and function names are extremely important for program comprehension. It is therefore also important to study how developers select names. But controlled experiments on naming are hindered by the need to describe to experimental subjects what it is they need to name. Words appearing in these descriptions may then find their way into the names, leading to a bias in the results. We suggest that this problem can be alleviated by using emojis or other small graphics in lieu of key words in the descriptions. A replication of previous work on naming, this time including such emojis and graphics, indeed led to a more diverse and less biased choice of words in the names than when using English descriptions.
... Writing source code in such a way that developers effectively understand it is fundamental for the sustainable development, maintenance, and evolution of software systems [14,26,27]. In contrast to natural languages, programming languages have an unambiguous meaning for a valid syntactical piece of code [5]. However, developers may not always draw the correct conclusions on the behaviour of a piece of code; they can mistake the meaning of code and misjudge the program's behaviour, leading to errors [14]. ...
Although writing code seems trivial at times, problems arise when humans misinterpret what the code actually does. One of the potential causes are "atoms of confusion", the smallest possible patterns of misinterpretable source code. Previous research has investigated the impact of atoms of confusion in C code. Results show that developers make significantly more mistakes in code where atoms are present. In this paper, we replicate the work of Gopstein et al. to the Java language. After deriving a set of atoms of confusion for Java, we perform a two-phase experiment with 132 computer science students (i.e., novice developers). Our results show that (i) participants are 2.7 up to 56 times more likely to make mistakes in code snippets affected by 7 out of the 14 studied atoms of confusion, and (2) when faced with both versions of the code snippets, participants perceived the version affected by the atom of confusion to be more confusing and/or less readable in 10 out of the 14 studied atoms of confusion.
... Research on program comprehension revealed that identifiers capture developers' understanding of their system and its application domain at the most primitive level. Such information can be crucial for developers during maintenance sessions [4,6,7,13,21,24,25,37]. Comments were also found to play a paramount role in arriving at a correct understanding of the program, especially for newcomers who do not have an adequate experience in the internals of the system [1,19]. ...
Open Source Software (OSS) projects start with an initial vocabulary , often determined by the first generation of developers. This vocabulary, embedded in code identifier names and internal code comments, goes through multiple rounds of change, influenced by the interrelated patterns of human (e.g., developers joining and departing) and system (e.g., maintenance activities) interactions. Capturing the dynamics of this change is crucial for understanding and synthesizing code changes over time. However, existing code evolution analysis tools, available in modern version control systems such as GitHub and SourceForge, often overlook the linguistic aspects of code evolution. To bridge this gap, in this paper, we propose to study code evolution in OSS projects through the lens of developers' language, also known as code lexicon. Our analysis is conducted using 32 OSS projects sampled from a broad range of application domains. Our results show that different maintenance activities impact code lexicon differently. These insights lay out a preliminary foundation for modeling the linguistic history of OSS projects. In the long run, this foundation will be utilized to provide support for basic program comprehension tasks and help researchers gain new insights into the complex interplay between linguistic change and various system and human aspects of OSS development. CCS CONCEPTS • Software and its engineering → Maintaining software.
... Several interesting empirical studies have been performed regarding the usage of names in source code. According to these studies, the usage of full word identifiers improves source code readability [4,13]. Typically, short identifiers take longer to understand [10]. ...
In this paper, we investigate the usage of naming conventions
in SQL programming. To this end, we define a reference style, consisting
of naming conventions that have been proposed in the literature. Then,
we perform an empirical study that involves the database schemas of
21 open source projects. In our study, we evaluate the adherence of the
names that are used in the schemas to the reference style. Moreover,
we study how the adherence of the names to the reference style evolves,
during the lifetime of the schemas. Our study reveals that many conventions are followed in all schemas. The adherence to these conventions is typically stable, during the lifetime of the schemas. However, there are also conventions that are partially followed, or even not followed. Over time, the adherence of the schemas to these conventions may improve,
decay or remain stable.
... Programming language source code with deficient coding conventions, such as misleading function and variable names and irregular spacing, is difficult for developers to effectively understand, review, and modify [8,52,66]. Code with haphazard adherence to conventions may also be more bug-prone [17]. The problem is exacerbated in large projects with many developers, where different source code files and components may have inconsistent and clashing conventions. ...
Coding conventions for naming, spacing, and other essentially stylistic properties are necessary for developers to effectively understand, review, and modify source code in large software projects. Consistent conventions in verification projects based on proof assistants, such as Coq, increase in importance as projects grow in size and scope. While conventions can be documented and enforced manually at high cost, emerging approaches automatically learn and suggest idiomatic names in Java-like languages by applying statistical language models on large code corpora. However, due to its powerful language extension facilities and fusion of type checking and computation, Coq is a challenging target for automated learning techniques. We present novel generation models for learning and suggesting lemma names for Coq projects. Our models, based on multi-input neural networks, are the first to leverage syntactic and semantic information from Coq's lexer (tokens in lemma statements), parser (syntax trees), and kernel (elaborated terms) for naming; the key insight is that learning from elaborated terms can substantially boost model performance. We implemented our models in a toolchain, dubbed Roosterize, and applied it on a large corpus of code derived from the Mathematical Components family of projects, known for its stringent coding conventions. Our results show that Roosterize substantially outperforms baselines for suggesting lemma names, highlighting the importance of using multi-input models and elaborated terms.
... According Wohlin et al. [15], controlled study is an empirical strategy that manipulates one factor of the studied setting where different treatments are applied to one or more variables, while other variables are kept constant. Avidan et al. [19] conducted a controlled experiment where nine developers tried to understand six methods from utility classes, either with the original variable names or with names replaced by meaningless single letters. This study shows that parameter names are more significant for comprehension than local variables. ...
GraphQL is a novel query language for implementing service-based software architectures. The language is gaining momentum and it is now used by major software companies, such as Facebook and GitHub. However, we still lack empirical evidence on the real gains achieved by GraphQL, particularly in terms of the effort required to implement queries in this language. Therefore, in this paper we describe a controlled experiment with 22 students (10 undergraduate and 12 graduate), who were asked to implement eight queries for accessing a web service, using GraphQL and REST. Our results show that GraphQL requires less effort to implement remote service queries, when compared to REST (9 vs 6 minutes, median times). These gains increase when REST queries include more complex endpoints, with several parameters. Interestingly, GraphQL outperforms REST even among more experienced participants (as is the case of graduate students) and among participants with previous experience in REST, but no previous experience in GraphQL.
... Neal [3] observes that programmers with several levels of experience build code by studying, reusing, or revising software (or parts of software) written by others. To benefit from an example, programmers must understand it and also understand the concepts embodied by it [6]. However, examples are often reused without a full understanding of what they do or mean [7]. ...
Software development practices rely extensively on reusing source code written by other programmers. One of the recurring questions about such practice is how much programmers, acting as users of somebody else’s code, really understand the source code that they inject it in their programs. The question is even more important for novices, who are trying to learn what programming is and how it should be practiced on a larger scale. In this paper we present the results of an ongoing research using a semiotic approach to investigate how novice programmers reuse source code, and how, through messages inscribed in the source code of the programs they write or reuse, they communicate, implicitly or explicitly, what such source code "means" to them and others. We carried out three studies with novice programmers, and results suggest that source code reuse may impact what programmers take their source code to mean.
The relevance of code comprehension in a developer’s daily work was recognized more than 40 years ago. Consequently, many experiments were conducted to find out how developers could be supported during code comprehension and which code characteristics contribute to better comprehension. Today, such studies are more common than ever. While this is great for advancing the field, the number of publications makes it difficult to keep an overview. Additionally, designing rigorous code comprehension experiments with human participants is a challenging task, and the multitude of design options can make it difficult for researchers, especially newcomers to the field, to select a suitable design.
We therefore conducted a systematic mapping study of 95 source code comprehension experiments published between 1979 and 2019. By structuring the design characteristics of code comprehension studies, we provide a basis for subsequent discussion of the huge diversity of design options in the face of a lack of basic research on their consequences and comparability. We describe what topics have been studied, as well as how these studies have been designed, conducted, and reported. Frequently chosen design options and deficiencies are pointed out to support researchers of all levels of domain expertise in designing their own studies.
There are many aspects of code quality, some of which are difficult to capture or to measure. Despite the importance of software quality, there is a lack of commonly accepted measures or indicators for code quality that can be linked to quality attributes. We investigate software developers’ perceptions of source code quality and the practices they recommend to achieve these qualities. We analyze data from semi-structured interviews with 34 professional software developers, programming teachers and students from Europe and the U.S. For the interviews, participants were asked to bring code examples to exemplify what they consider good and bad code, respectively. Readability and structure were used most commonly as defining properties for quality code. Together with documentation, they were also suggested as the most common target properties for quality improvement. When discussing actual code, developers focused on structure, comprehensibility and readability as quality properties. When analyzing relationships between properties, the most commonly talked about target property was comprehensibility. Documentation, structure and readability were named most frequently as source properties to achieve good comprehensibility. Some of the most important source code properties contributing to code quality as perceived by developers lack clear definitions and are difficult to capture. More research is therefore necessary to measure the structure, comprehensibility and readability of code in ways that matter for developers and to relate these measures of code structure, comprehensibility and readability to common software quality attributes.
Understanding code depends not only on the code but also on the brain.
Within social networks, audio is a vehicle for violent, bullying or generally unwanted content. This research intends to propose an automatic tool for extracting text from an audio stream. Microsoft azure cognitive cloud services, and in particular, Speech SDK and bot SDK are used for extraction and recognition tasks. The extracted text can then be analyzed using techniques and algorithm known for analyzing critical situations such as violence or bullying but is applicable in any context.KeywordsAdagioAudio extractionSpeech recognitionMicrosoft AzureSpeech SDKBot SDK
Context: Writing code that is understandable by other collaborators has become crucial to enhancing collaboration and productivity. Clean Code has become one of the most relevant software craftsmanship practices and has been widely embraced as a synonym for code quality by software developers and software development organizations all over the world. However, very little is known regarding whether developers agree with Clean Code principles and how they apply them in practice.Objectives: In this work, we investigated how developers perceive Clean Code principles, whether they believe that helps reading, understanding, reusing, and modifying Clean Code, and how they keep their code clean.Methods: We conducted a Systematic Literature Review in which we screened 771 research papers to collect Clean Code principles and a survey among 39 practitioners, some of them with more than 20 years of development experience.Results: So far, the results show a shared agreement with Clean Code principles and their potential benefits. They also show that developers tend to write “messy” code to be refactored later.KeywordsClean codeSurveyCode quality
This research proposal targets public sector ICT practices. The goal is to explore in-depth the causes of issues in public ICT. Furthermore, the goal is to fill research gaps in public agency and supplier interrelationships, EA practices, and intended public sector technological solutions. The proposed research binds these areas to establish a coherent framework for how ICT should be built and led in public agencies.KeywordsPublic procurementEnterprise architectureSustainable softwareInteroperability
With the growing interest in programming skills in society, programming will inevitably become part of national curricula. The research presented on this poster aims to address programming for everyone and hopes to contribute to the accessibility of programming lessons for both students and teachers with various backgrounds. In order to do so, we approach the learning and teaching of a programming language from a natural language perspective, and in particular, we focus on reading code, including one of the most important programming concepts: variables.
During the last decades, the number of research projects on reading code has increased. For example, research on reading and explaining code has shown that code reading skills correlate to code writing skills [4, 5, 11, 12, 15]. Neuroscientific results indicate that language-related brain networks are possibly more important when programming than brain networks related to problem-solving or mathematics [7, 8, 13]. In addition, classroom experiments demonstrate how training on technical reading abilities can improve programming skills [6], and how reading code aloud, a strategy derived from natural language learning, helps with remembering syntax, which is an element of coding that beginners often struggle with [9, 14].
Research has also shown the importance of variables in reading and understanding code. It is commonly accepted that meaningful identifier names (or ‘mnemonic’ names) help readers understand code more easily than when abbreviations or (random) letters are used [2, 10], although it has also been found that such names can be misleading if they wrongly represent their contents or purpose [1, 3]. The question still remains what is “good” variable naming for learning to program.
Existing research on variable naming usually focuses on understanding code or assessing the readability of code. To the best of our knowledge, no prior research has looked at how (if) variable names are considered in the classroom and if there are any strategies used for practicing naming. This poster presents some initial findings of 12 semi-structured interviews (60 minutes) with teachers from secondary education, university-level education, and adult education on the practice of teaching variables. Our focus is on naming, but we also cover more general teaching strategies and practice, common student difficulties (related to variables) as experienced by the teachers, as well as teachers’ perceptions of the importance of variable naming.
Our preliminary results show two main approaches to teaching variable naming: a small group clearly highlights the importance of good and consistent naming throughout their courses, although there is no consensus on ”good naming practices”. Another group of teachers finds naming important, but does not (yet) translate this in their teaching. This group may even completely ignore naming or give inconsistent naming examples. Overall, naming is not included in grading. Teachers reflect that good naming practices may help students understand programming concepts quicker and mention that better students also show better naming practices in their own code. With our research, we hope to encourage discussion on the teaching of variables and work towards practical clues for (beginning) teachers to support them with accessible programming lessons.
The relevance of code comprehension in a developer's daily work was recognized more than 40 years ago. Over the years, several studies have gathered evidence that developers do indeed invest a considerable amount of their daily work in code comprehension. Consequently, many studies were conducted to find out how developers could be supported during code comprehension and which code characteristics contribute to better comprehension. Today, such experiments are more common than ever. While this is great for advancing the field, the number of publications makes it difficult to keep an overview. Additionally, designing rigorous experiments with human participants is a challenging task, and the multitude of design decisions and options can make it difficult for researchers to select a suitable design. We therefore conducted a systematic mapping study of 95 source code comprehension experiments published between 1979 and 2019. By systematically structuring the design characteristics of code comprehension studies, we provide a basis for subsequent discussion of the huge diversity of design options in the face of a lack of basic research on their consequences and comparability. We describe what topics have been studied, as well as how these studies have been designed, conducted, and reported. Frequently chosen design options and deficiencies are pointed out. We conclude with five concrete action items that we as a research community should address moving forward to improve publications of code comprehension experiments.
Coding conventions for naming, spacing, and other essentially stylistic properties are necessary for developers to effectively understand, review, and modify source code in large software projects. Consistent conventions in verification projects based on proof assistants, such as Coq, increase in importance as projects grow in size and scope. While conventions can be documented and enforced manually at high cost, emerging approaches automatically learn and suggest idiomatic names in Java-like languages by applying statistical language models on large code corpora. However, due to its powerful language extension facilities and fusion of type checking and computation, Coq is a challenging target for automated learning techniques. We present novel generation models for learning and suggesting lemma names for Coq projects. Our models, based on multi-input neural networks, are the first to leverage syntactic and semantic information from Coq ’s lexer (tokens in lemma statements), parser (syntax tree s), and kernel (elaborated terms) for naming; the key insight is that learning from elaborated terms can substantially boost model performance. We implemented our models in a toolchain, dubbed Roosterize, and applied it on a large corpus of code derived from the Mathematical Components family of projects, known for its stringent coding conventions. Our results show that Roosterize substantially outperforms baselines for suggesting lemma names, highlighting the importance of using multi-input models and elaborated terms.
Machine learning-based Vulnerability detection is an active research topic in software security. Different traditional machine learning-based and deep learning-based vulnerability detection methods have been proposed. To our best knowledge, we are the first to identify four impact factors and conduct a comparative study to investigate the performance influence of these factors. In particular, the quality of datasets, classification models and vectorization methods can directly affect the detection performance, in contrast function/variable name replacement can affect the features of vulnerability detection and indirectly affect the performance. We collect three different vulnerability code datasets from two various sources (i.e., NVD and SARD). These datasets can correspond to different types of vulnerabilities. Moreover, we extract and analyze the features of vulnerability code datasets to explain some experimental results. Our findings based on the experimental results can be summarized as follows: (1) Deep learning models can achieve better performance than traditional machine learning models. Of all the models, BLSTM can achieve the best performance. (2) CountVectorizer can significantly improve the performance of traditional machine learning models. (3) Features generated by the random forest algorithm include system-related functions, syntax keywords, and user-defined names. Different vulnerability types and code sources will generate different features. (4) Datasets with user-defined variable and function name replacement will decrease the performance of vulnerability detection. (5) As the proportion of code from SARD increases, the performance of vulnerability detection will increase.
The names of variables and functions serve as implicit documentation and are instrumental for program comprehension. But choosing good meaningful names is hard. We perform a sequence of experiments in which a total of 334 subjects are required to choose names in given programming scenarios. The first experiment shows that the probability that two developers would select the same name is low: in the 47 instances in our experiments the median probability was only 6.9%. At the same time, given that a specific name is chosen, it is usually understood by the majority of developers. Analysis of the names given in the experiment suggests a model where naming is a (not necessarily cognizant or serial) three-step process: (1) selecting the concepts to include in the name, (2) choosing the words to represent each concept, and (3) constructing a name using these words. A followup experiment, using the same experimental setup, then checked whether using this model explicitly can improve the quality of names. The results were that names selected by subjects using the model were judged by two independent judges to be superior to names chosen in the original experiment by a ratio of two-to-one. Using the model appears to encourage the use of more concepts and longer names.
Descriptive names are a vital part of readable, and hence maintainable, code. Recent progress on automatically suggesting names for local variables tantalizes with the prospect of replicating that success with method and class names. However, suggesting names for methods and classes is much more difficult. This is because good method and class names need to be functionally descriptive, but suggesting such names requires that the model goes beyond local context. We introduce a neural probabilistic language model for source code that is specifically designed for the method naming problem. Our model learns which names are semantically similar by assigning them to locations, called embeddings, in a high-dimensional continuous space, in such a way that names with similar embeddings tend to be used in similar contexts. These embeddings seem to contain semantic information about tokens, even though they are learned only from statistical co-occurrences of tokens. Furthermore, we introduce a variant of our model that is, to our knowledge, the first that can propose neologisms, names that have not appeared in the training corpus. We obtain state of the art results on the method, class, and even the simpler variable naming tasks. More broadly, the continuous embeddings that are learned by our model have the potential for wide application within software engineering.
Antipatterns are known as poor solutions to recurring problems. For example, Brown et al. and Fowler define practices concerning poor design or implementation solutions. However, we know that the source code lexicon is part of the factors that affect the psychological complexity of a program, i.e., factors that make a program difficult to understand and maintain by humans. The aim of this work is to identify recurring poor practices related to inconsistencies among the naming, documentation, and implementation of an entity—called Linguistic Antipatterns (LAs)—that may impair program understanding. To this end, we first mine examples of such inconsistencies in real open-source projects and abstract them into a catalog of 17 recurring LAs related to methods and attributes. Then, to understand the relevancy of LAs, we perform two empirical studies with developers—30 external (i.e., not familiar with the code) and 14 internal (i.e., people developing or maintaining the code). Results indicate that the majority of the participants perceive LAs as poor practices and therefore must be avoided—69 % and 51 % of the external and internal developers, respectively. As further evidence of LAs’ validity, open source developers that were made aware of LAs reacted to the issue by making code changes in 10 % of the cases. Finally, in order to facilitate the use of LAs in practice, we identified a subset of LAs which were universally agreed upon as being problematic; those which had a clear dissonance between code behavior and lexicon.
There are a number of empirical studies that assess the benefit deriving from the use of documentation and models in the execution of maintenance tasks. The greater part of these studies are quantitative and fail to analyze the values, beliefs, and assumptions that inform and shape source code comprehensibility and maintainability. We designed and conducted a qualitative study to understand the role of source code comments and identifiers in source code comprehensibility and maintainability. In particular, we sought to understand how novice and young professional developers perceive comments and identifier names after they have inspected the system behavior visible in its user interfaces. Novice developers were 18 third-year Bachelor students in Computer Science. The young professional developers were 12 and had work experience in between 3 months and 2 and half years. The used qualitative methodological approach is ethnographic. We asked the participants to inspect the behavior of a Java application visible in its user interfaces and then to comprehend and modify the source code of that application. We immersed ourselves and participated to the study, while collecting data by means of contemporaneous field notes, audio recordings, and copies of various artifacts. From the collected data, we have identified insights into comprehension and maintenance practices. The main insights can be summarized as follows: (i) with respect to novice developers, professional developers prefer to deal with identifier names rather than comments, (ii) all the participants indicate as essential the use of naming convention techniques for identifiers, and (iii) for all the participants the names of identifiers are important and should be properly chosen. Summarizing, independently from the kind of developer, it is advisable to use naming convention techniques and to properly choose identifiers.
Source code lexicon plays a paramount role in software quality: poor lexicon can lead to poor comprehensibility and even increase software fault-proneness. For this reason, renaming a program entity, i.e., altering the entity identifier, is an important activity during software evolution. Developers rename when they feel that the name of an entity is not (anymore) consistent with its functionality, or when such a name may be misleading. A survey that we performed with 71 developers suggests that 39 percent perform renaming from a few times per week to almost every day and that 92 percent of the participants consider that renaming is not straightforward. However, despite the cost that is associated with renaming, renamings are seldom if ever documented—for example, less than 1 percent of the renamings in the five programs that we studied. This explains why participants largely agree on the usefulness of automatically documenting renamings. In this paper we propose REanaming Program ENTities (REPENT), an approach to automatically document—detect and classify—identifier renamings in source code. REPENT detects renamings based on a combination of source code differencing and data flow analyses. Using a set of natural language tools, REPENT classifies renamings into the different dimensions of a taxonomy that we defined. Using the documented renamings, developers will be able to, for example, look up methods that are part of the public API (as they impact client applications), or look for inconsistencies between the name and the implementation of an entity that underwent a high risk renaming (e.g., towards the opposite meaning). We evaluate the accuracy and completeness of REPENT on the evolution history of five open-source Java programs. The study indicates a precision of 88 percent and a recall of 92 percent. In addition, we report an exploratory study investigating and discussing how identifiers are renamed in the five programs, according to o- r taxonomy.
Many have sought a software design process that allows a program to be derived systematically from a precise statement of requirements. It is proposed that, although designing a real product in that way will not be successful, it is possible to produce documentation that makes it appear that the software was designed by such a process. The ideal process and the documentation that it requires are described. The authors explain why one should attempt to design according to the ideal process and why one should produce the documentation that would have been produced by that process. The contents of each of the required documents are outlined.
Every programmer has a characteristic style, ranging from preferences about
identifier naming to preferences about object relationships and design
patterns. Local, syntactic style, such as naming and formatting, can foster
readability and hence maintainability. Indeed, when programmers collaborate,
they attempt to maintain consistent local style, but this is difficult because
style is context dependent, and often programmers are unaware of their own
tendencies. These factors frustrate current rule-based code formatters, to the
extent that programmers often avoid such tools. We present Naturalize, a
framework that learns the style of an existing codebase, discovers emerging
consensus on style, and suggests revisions to improve stylistic consistency. To
our knowledge, this is the first approach that treats style as a problem of
mores rather than of laws. Naturalize builds on recent work in applying
statistical natural language processing to source code. We apply Naturalize to
suggest natural identifier names and formatting conventions. We present three
new tools focused on ensuring natural code during development and release
management, including tools to support code review. Naturalize achieves 94%
accuracy in its top suggestions for identifier names and can even transfer
knowledge about conventions across projects, leveraging a corpus of 10,968 open
source projects.
Class diagrams play an important role in software development. However, in some cases, these diagrams contain a lot of information. This makes it hard for software maintainers to use them to understand a system. In this paper, we aim to discover how to simplify class diagrams in a such way that they make systems easier to understand. To this end, we performed a survey to analyze what type of information software developers find important to include or exclude in order to simplify a class diagram. This survey involved 32 software developers with 75% of the participants having more than 5 years of experience with class diagrams. As the result, we found that the important elements in a class diagram are class relationship, meaningful class names and class properties. We also found that information that should be excluded in a simplified class diagram is GUI related information, private and protected operations, helper classes and library classes. In this survey we also tried to discover what types of features are needed for class diagram simplification tools.
Recent software development tools have exploited the mining of natural language information found within software and its supporting documentation. To make the most of this information, researchers have drawn upon the work of the natural language processing community for tools and techniques. One such tool provides part-of-speech information, which finds application in improving the searching of software repositories and extracting domain information found in identifiers. Unfortunately, the natural language found is software differs from that found in standard prose. This difference potentially limits the effectiveness of off-the-shelf tools. An empirical investigation finds that with minimal guidance an existing tagger was correct 88% of the time when tagging the words found in source code identifiers. The investigation then uses the improved part-of-speech information to tag a large corpus of over 145,000 structure-field names. From patterns in the tags several rules emerge that seek to understand past usage and to improve future naming.
This paper formally distinguishes between two variants of top-down
comprehension (as originally described by Brooks (1983) and Soloway
(1984)). The first is inference-based comprehension, where the
programmer derives meaning from cliched implementations in the code. The
second is expectation-based comprehension, where the programmer has
pre-generated expectations of the code's meaning. The paper describes
the distinguishing features of the two variants, and uses these
characteristics as the basis for an empirical study. This study
establishes their existence, and identifies their relationship with
programmers' domain and coding standards familiarity
One of the main challenges faced by today's developers is keeping up with the staggering amount of source code that needs to be read and understood. In order to help developers with this problem and reduce the costs associated with it, one solution is to use simple textual descriptions of source code entities that developers can grasp easily, while capturing the code semantics precisely. We propose an approach to automatically determine such descriptions, based on automated text summarization technology.
It is often difficult, particularly when conducting research in psychology, to have access to large normally distributed samples. Fortunately, there are statistical tests to compare two independent groups that do not require large normally distributed samples. The Mann-Whitney U is one of these tests. In the following work, a summary of this test is presented. The explanation of the logic underlying this test and its application are presented. Moreover, the forces and weaknesses of the Mann-Whitney U are mentioned. One major limit of the Mann-Whitney U is that the type I error or alpha (?) is amplified in a situation of heteroscedasticity.
We characterize Openness/Intellect as motivated cognitive flexibility, or cognitive exploration, and develop a neuropsychological model relating it to dopaminergic function and to the functions of the prefrontal cortex (PFC). Evidence is reviewed for sources of Openness/Intellect shared with Extraversion and sources unique to Openness/Intellect. The hypothesis that the cognitive functions of the dorsolateral PFC are among the latter was tested using standard measures of cognitive ability and a battery of tasks associated with dorsolateral PFC function (N=175). Dorsolateral PFC function, as well as both fluid and crystallized cognitive ability, was positively related to Openness/Intellect but no other personality trait. Additionally, facet level analysis supported the characterization of Openness/Intellect as a primarily cognitive trait.
Achieving and maintaining high software quality is most dependent on how easily the software engineer least familiar with the system can understand the system's code. Understanding attributes of cognitive processes can lead to new software metrics that allow the prediction of human performance in software development and for assessing and improving the understandability of text and code. In this research we present novel metrics based on current understanding of short-term memory performance to predict the location of high frequencies of errors and to evaluate the quality of a software system. We further enhance these metrics by applying static and dynamic program slicing to provide programmers with additional guidance during software inspection and maintenance efforts.
Code cognition models examine how programmers understand program
code. The authors survey the current knowledge in this area by comparing
six program comprehension models: the Letovsky (1986) model; the
Shneiderman and Mayer (1979) model; the Brooks (1983) model; Soloway,
Adelson and Ehrlich's (1988) top-down model; Pennington's (1987)
bottom-up model; and the integrated metamodel of von Mayrhauser and Vans
(1994). While these general models can foster a complete understanding
of a piece of code, they may not always apply to specialized tasks that
more efficiently employ strategies geared toward partial understanding.
We identify open questions, particularly considering the maintenance and
evolution of large-scale code. These questions relate to the scalability
of existing experimental results with small programs, the validity and
credibility of results based on experimental procedures, and the
challenges of data availability
Natural languages like English are rich, complex, and powerful. The highly creative and graceful use of languages like English and Tamil, by masters like Shakespeare and Avvaiyar, can certainly delight and inspire. But in practice, given cognitive constraints and the exigencies of daily life, most human utterances are far simpler and much more repetitive and predictable. In fact, these utterances can be very usefully modeled using modern statistical methods. This fact has led to the phenomenal success of statistical approaches to speech recognition, natural language translation, question-answering, and text mining and comprehension.
We begin with the conjecture that most software is also natural, in the sense that it is created by humans at work, with all the attendant constraints and limitations---and thus, like natural language, it is also likely to be repetitive and predictable. We then proceed to ask whether (a) code can be usefully modeled by statistical language models and (b) such models can be leveraged to support software engineers. Using the widely adopted n-gram model, we provide empirical evidence supportive of a positive answer to both these questions. We show that code is also very regular, and, in fact, even more so than natural languages. As an example use of the model, we have developed a simple code completion engine for Java that, despite its simplicity, already improves Eclipse's completion capability. We conclude the paper by laying out a vision for future research in this area.
Being able to repeat experiments is considered a hallmark of the scientific method, used to confirm or refute hypotheses and previously obtained results. But this can take many forms, from precise repetition using the original experimental artifacts, to conceptual reproduction of the main experimental idea using new artifacts. Furthermore, the conclusions from previous work can also be corroborated using a different experimental methodology altogether. In order to promote a better understanding and use of such methodologies we propose precise definitions for different terms, and suggest when and why each should be used.
Even bad code can function. But if code isnt clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesnt have to be that way.Noted software expert Robert C. Martin, presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin, who has helped bring agile principles from a practitioners point of view to tens of thousands of programmers, has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code on the fly into a book that will instill within you the values of software craftsman, and make you a better programmerbut only if you work at it.What kind of work will you be doing? Youll be reading codelots of code. And you will be challenged to think about whats right about that code, and whats wrong with it. More importantly you will be challenged to reassess your professional values and your commitment to your craft. Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up codeof transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and smells gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.Readers will come away from this book understandingHow to tell the difference between good and bad codeHow to write good code and how to transform bad code into good codeHow to create good names, good functions, good objects, and good classesHow to format code for maximum readability How to implement complete error handling without obscuring code logicHow to unit test and practice test-driven developmentWhat smells and heuristics can help you identify bad codeThis book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
In almost all computer applications, users must enter correct words for the desired objects or actions. For success without extensive training, or in first-tries for new targets, the system must recognize terms that will be chosen spontaneously. We studied spontaneous word choice for objects in five application-related domains, and found the variability to be surprisingly large. In every case two people favored the same term with probability less than 0. 20. Simulations show how this fundamental property of language limits the success of various design methodologies for vocabulary-driven interaction. For example, the popular approach in which access is via one designer's favorite single word will result in 80-90 percent failure rates in many common situations. An optimal strategy, unlimited aliasing, is derived and shown to be capable of several-fold improvements. (Author abstracat)
Abstract Approximately 70% of the source code of a software sys- tem consists of identifiers. Hence, the names chosen as identifiers are of paramount,importance,for the readabil- ity of computer,programs,and therewith their comprehen- sibility. However, virtually every programming language allows programmers,to use almost arbitrary sequences of characters as identifiers which far too often results in more or less meaningless,or even misleading naming. Coding style guides address this problem but are usually limited to general and hard to enforce rules like “identifiers should be self-describing”. This paper renders adequate identifier naming far more precisely. A formal model, based on bi- jective mappings between concepts and names, provides a solid foundation for the definition of precise rules for con- cise and consistent naming. The enforcement of these rules is supported by a tool that incrementally builds and main- tains a complete identifier dictionary while the system is being developed. The identifier dictionary explains the lan- guage used in the software system, aids in consistent nam- ing, and improves productivity of programmers by propos- ing suitable names depending on the current context. 1. Naming and Comprehension
In both commercial and academic environments, software development frameworks are an important tool in the construction of industrial strength software solutions. Despite the role they play in present day software development, little research has gone into understanding which aspects of their design, influence the way software developers use frameworks at the source code level. This paper investigates how the comprehensibility of an application's source code is affected by two factors: the naming styles for framework interfaces, and the availability of interface documentation. Results show that using a descriptive interface naming style is an effective way to aid a developer's comprehension. Documentation also plays an important role, but it increases the amount of time a developer will spend studying the source code.
Cognitive skill acquisition is acquiring the ability to solve problems in intellectual tasks, where success is determined more by subjects' knowledge than by their physical prowess. This review considers research conducted in the past ten years on cognitive skill acquisition. It covers the initial stages of acquiring a single principle or rule, the initial stages of acquiring a collection of interacting pieces of knowledge, and the final stages of acquiring a skill, wherein practice causes increases in speed and accuracy.
Approximately 70% of the source code of a software system consists of identifiers. Hence, the names chosen as identifiers are of paramount importance for the readability of computer programs and therewith their comprehensibility. However, virtually every programming language allows programmers to use almost arbitrary sequences of characters as identifiers which far too often results in more or less meaningless or even misleading naming. Coding style guides address this problem but are usually limited to general and hard to enforce rules like "identifiers should be self-describing". This paper renders adequate identifier naming far more precisely. A formal model, based on bijective mappings between concepts and names, provides a solid foundation for the definition of precise rules for concise and consistent naming. The enforcement of these rules is supported by a tool that incrementally builds and maintains a complete identifier dictionary while the system is being developed. The identifier dictionary explains the language used in the software system, aids in consistent naming, and improves productivity of programmers by proposing suitable names depending on the current context.
The paper presents an overview of the role of concepts in program comprehension. It discusses concept location, in which the implementation of a specific concept is located in the code. This process is very common and precedes a large proportion of code changes. The paper also discusses the process of learning about the domain from the code, which is a prerequisite of code reengineering. The paper notes the similarities and overlaps between program comprehension and human learning.
The identifiers chosen by programmers as entity names contain valuable information. They are often the starting point for the program understanding activities, especially when high level views, like the call graph, are available. An approach for the restructuring of program identifier names is proposed, aimed at improving their meaningfulness. It considers two forms of standardization, associated respectively to the lexicon of the composing terms and to the syntax of their arrangement. Automatic and semiautomatic techniques are described which can help the restructuring intervention. Their application to a real world case study is also presented
Type-safe PHP: Java code conventions
- R Stoll
What's in a name? a study of identifiers
- D Lawrie
- C Morrell
- H Field
- D Binkley
REPENT: Analyzing the nature of identifier renamings
- V Arnaoudova
- L M Eshkevari
- M Di
- R Oliveto
- G Antoniol
- Y.-G Guéhéneuc