Understanding the shape of Java software

Baxter, G. J.; Frean, Marcus; Noble, James; Rickerby, Mark; Smith, Hayden P.; Visser, Matt; Melton, Hayden; Tempero, Ewan

doi:10.1145/1167473.1167507

Cited by 106 publications

(62 citation statements)

References 20 publications

(22 reference statements)

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Baxter et al [7] looked at the 'shape' of Java Software, finding that certain metrics follow power laws. They later extended their findings in [40] using a large-scale corpus of software, not unlike eariler efforts by Bajracharya et al [5], with both these works serving as pioneering work in studying language design on a larger scale.…”

Section: Related Workmentioning

confidence: 99%

On the usage of pythonic idioms

Alexandru

Merchante

Panichella

et al. 2018

Proceedings of the 2018 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Sof

View full text Add to dashboard Cite

Developers discuss software architecture and concrete source code implementations on a regular basis, be it on questionanswering sites, online chats, mailing lists or face to face. In many cases, there is more than one way of solving a programming task. Which way is best may be decided based on case-specific circumstances and constraints, but also based on convention. Having strong conventions, and a common vocabulary to express them, simplifies communication and strengthens common understanding of software development problems and their solutions. While many programming ecosystems have a common vocabulary, Python's relationship to conventions and common language is a particularly pronounced. The "Zen of Python", a famous set of high-level coding conventions authored by Tim Peters, states "There should be one, and preferably only one, obvious way to do it". This 'one way to do it' is often referred to as the 'Pythonic' way: the ideal solution to a particular problem. Few other programming languages have coined a unique term to label the quality of craftsmanship gone into a software artifact. In this paper, we explore how Python developers understand the term 'Pythonic' by means of structured interviews, build a catalogue of 'pythonic idioms' gathered from literature, and conjecture on the effects of having a language-specific term for quality code, considering the potential it could hold for other programming languages and ecosystems. We find that while the term means different things to novice versus experienced Python developers, it encompasses not only concrete implementation, but a way of thinking -a culture -in general.

show abstract

Section: Related Workmentioning

confidence: 99%

On the usage of pythonic idioms

Alexandru

Merchante

Panichella

et al. 2018

Proceedings of the 2018 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Sof

View full text Add to dashboard Cite

show abstract

“…Previous similar studies have used a range of tools e.g. purposebuilt bytecode analysis [31], Byte Code Engineering Library [1], Soot Framework [32], Codecrawler [18], and MOOSE [13]. It was noted that Tempero et al's study on inheritance use in Java "had memory limitations that restricted the size of the systems than we could analyse" [32].…”

Section: Study Instrumentationmentioning

confidence: 99%

Inheritance usage patterns in open-source systems

Stevenson

Wood

2018

Proceedings of the 40th International Conference on Software Engineering

View full text Add to dashboard Cite

is research investigates how object-oriented inheritance is actually used in practice. e aim is to close the gap between inheritance guidance and inheritance practice. It is based on detailed analyses of 2440 inheritance hierarchies drawn from 14 open-source systems. e original contributions made by this paper concern pragmatic assessment of inheritance hierarchy design quality. e findings show that inheritance is very widely used but that most of the usage paerns that occur in practice are simple in structure. ey are so simple that they may not require much inheritance-specific design consideration. On the other hand, the majority of classes defined using inheritance actually appear within a relatively small number of large, complex hierarchies. While some of these large hierarchies appear to have a consistent structure, oen based on a problem domain model or a design paern, others do not. Another contribution is that the quality of hierarchies, especially the large problematic ones, may be assessed in practice based on size, shape, and the definition and invocation of novel methods-all properties that can be detected automatically.

show abstract

“…They reported a high correlation between LOC, number of methods (NOM), and out degree of classes. Baxter et al (2006) reported a similar study, however, unlike Wheeldon and Counsell (2003), have observed some metrics that do not follow the power laws. They opined, their use of a more extensive corpus compared to Wheeldon and Counsell (2003) is the reason for the difference.…”

Section: Related Workmentioning

confidence: 75%

Effects of measurements on correlations of software code metrics

2019

View full text Add to dashboard Cite

Context Software metrics play a significant role in many areas in the life-cycle of software including forecasting defects and foretelling stories regarding maintenance, cost, etc. through predictive analysis. Many studies have found code metrics correlated to each other at such a high level that such correlated code metrics are considered redundant, which implies it is enough to keep track of a single metric from a list of highly correlated metrics. Objective Software is developed incrementally over a period. Traditionally, code metrics are measured cumulatively as cumulative sum or running sum. When a code metric is measured based on the values from individual revisions or commits without consolidating values from past revisions, indicating the natural development of software, this study identifies such a type of measure as organic. Density and average are two other ways of measuring metrics. This empirical study focuses on whether measurement types influence correlations of code metrics. Method To investigate the objective, this empirical study has collected 24 code metrics classified into four categories, according to the measurement types of the metrics, from 11,874 software revisions (i.e., commits) of 21 open source projects from eight well-known organizations. Kendall's τ-B is used for computing correlations. To determine whether there is a significant difference between cumulative and organic metrics, Mann-Whitney U test, Wilcoxon signed rank test, and paired-samples sign test are performed. Results The cumulative metrics are found to be highly correlated to each other with an average coefficient of 0.79. For corresponding organic metrics, it is 0.49. When individual correlation coefficients between these two measure types are compared, correlations between organic metrics are found to be significantly lower (with p <0.01) than cumulative metrics. Our results indicate that the cumulative nature of metrics makes them highly correlated, implying cumulative measurement is a major source of collinearity between cumulative metrics. Another interesting observation is that correlations between metrics from different categories are weak.

show abstract

Understanding the shape of Java software

Cited by 106 publications

References 20 publications

On the usage of pythonic idioms

On the usage of pythonic idioms

Inheritance usage patterns in open-source systems

Effects of measurements on correlations of software code metrics

Contact Info

Product

Resources

About