Pangea: A Workbench for Statically Analyzing Multi-language Software Corpora

Caracciolo, Andrea; Chiș, Andrei; Spasojevic, Boris; Lungu, Mircea

doi:10.1109/scam.2014.39

Cited by 8 publications

(5 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Caracciolo et al (2014) have created a workbench for running analyses on multi-language software systems; Sobernig and Zdun (2010) have addressed the topic of how to evaluate execution speed of cross-language method invocations in Java. Both are thus enablers for future efforts which may go into the directions of tool support or better linking mechanisms we have indicated.…”

Section: Cross-language Linkingmentioning

confidence: 99%

On multi-language software development, cross-language links and accompanying tools: a survey of professional software developers

Mayer

Kirsch

2017

J Softw Eng Res Dev

View full text Add to dashboard Cite

Context: Non-trivial software systems are written using multiple (programming) languages, which are connected by cross-language links. The existence of such links may lead to various problems during software development. There is little empirical evidence on the incidence of these problems and the experiences of professional developers in this field. Aim: We want to provide empirical evidence on multi-language software development, cross-language linking, and tool support in industry, including the views of professional developers on benefits and problems in these areas. Methods: We conducted a survey study to gather responses from 139 professional software developers. Results: Respondents reported an average of 7 languages and 3 linked language pairs per project. Respondents saw benefits of multi-language development for the motivation of developers and the translation of requirements, but problems in understandability and changeability. Over 90% of respondents reported problems related to cross-language linking. Developers universally agree on the usefulness of tool support. Conclusions: Multi-language programming and cross-language linking seem common but lead to several problems. We suggest that future practical as well as research efforts focus on these issues by creating appropriate tool support and by developing better techniques for cross-language linking for improved changeability and understandability.

show abstract

Section: Cross-language Linkingmentioning

confidence: 99%

On multi-language software development, cross-language links and accompanying tools: a survey of professional software developers

Mayer

Kirsch

2017

J Softw Eng Res Dev

View full text Add to dashboard Cite

show abstract

“…As such, several studies have investigated the link between identifier naming and code readability and comprehension [2], [5], [24], [26], [27] or identifier naming and externally observable aspects of the software development process that are expected to be affected by comprehension such as change-proneness [1], quality [4], [6] and presence of faults [7], [8]. Caprile and Tonella [29] have observed that names of C functions consist of on average of 2.04-3.36 words, often verbs expressing action, while Caracciolo et al observed that most method names in Java and Smalltalk also tend to consist of several words but rarely more than five words [30].…”

Section: Related Workmentioning

confidence: 99%

How do Scratch Programmers Name Variables and Procedures?

Swidan

Serebrenik

Hermans

2017

2017 IEEE 17th International Working Conference on Source Code Analysis and Manipulation (SCAM)

View full text Add to dashboard Cite

Research shows the importance of selecting good names to identifiers in software code: more meaningful names improve readability. In particular, several guidelines encourage long and descriptive variable names. A recent study analyzed the use of variable names in five programming languages, focusing on single-letter variable names, because of the apparent contradiction between their frequent use and the fact that these variables violate the aforementioned guidelines. In this paper, we analyze variables in Scratch, a popular blockbased language aimed at children. We start by replicating the above single-letter study for Scratch. We augment this study by analyzing single-letter procedure names, and by investigating the use of Scratch specific naming patterns: spaces in variable names, numerics as variables and textual labels in procedure names. The results of our analysis show that Scratch programmers often prefer longer identifier names than developers in other languages, while Scratch procedure names have even longer names than Scratch variables. For the single-letter variables, the most frequent names are x, y, and i. Single-letter procedures are less popular, but show more tendency to be in upper case. When compared to the other programming languages, the usage of single uppercase letters in Scratch variables seems to be similar to the pattern found in Perl, while for the lowercase letters-to the pattern found in Java. Concerning Scratch specific features, 44% of the unique variable names and 34% of the projects in the dataset include at least one space. The usage of textual labels between parameters in procedure names appears as not common, however textual patterns used imply an influence from textual languages, for example by using brackets. Previous research indicate the identifier names as one significant issue in transitioning from visual block-based to textual programming languages. The naming patterns we found support this claim for Scratch programmers who may incur difficulties when transitioning to the use of mainstream textual programming languages. Those languages restrict the use of spaces in identifiers and more often divert into short and single-letter namestendencies opposite to the naming preferences in Scratch.

show abstract

“…This corpus contains 810 Java projects, 371,745 Java source files, and 34,894,844 lines of code. We are making the corpus available for download through the Pangea infrastructure 3 [12].…”

Section: A Experimental Corpusmentioning

confidence: 99%

Tracking Null Checks in Open-Source Java Systems

Osman

Leuenberger

Lungu

et al. 2016

2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER)

Self Cite

View full text Add to dashboard Cite

It is widely acknowledged that null values should be avoided if possible or carefully used when necessary in Java code. The careless use of null has negative effects on maintainability, code readability, and software performance. However, a study on understanding null usage is still missing.In this paper we analyze null checks in 810 open-source Java systems and manually inspect 100 code samples to understand when and why developers use null. We find that 35% of all conditional statements contain null checks. A deeper investigation reveals many questionable practices with respect to using null. Uninitialized member variables, returning null in methods, and passing null as a method parameter are among the most recurrent reasons for introducing null checks. Developers often return null in methods to signal errors instead of throwing a proper exception. As a result, 71% of the values checked for null are returned from method calls.Our study provides a novel evidence of an overuse of null checks and of the null value itself in Java, and at the same time, reveals actionable recommendations to reduce this null usage.

show abstract

Pangea: A Workbench for Statically Analyzing Multi-language Software Corpora

Cited by 8 publications

References 4 publications

On multi-language software development, cross-language links and accompanying tools: a survey of professional software developers

On multi-language software development, cross-language links and accompanying tools: a survey of professional software developers

How do Scratch Programmers Name Variables and Procedures?

Tracking Null Checks in Open-Source Java Systems

Contact Info

Product

Resources

About