An Empirical Validation of the Benefits of Adhering to the Law of Demeter

Guo, Yangming; Wuersch, Michael; Giger, Emanuel; Gall, Harald C.

doi:10.1109/wcre.2011.36

Cited by 7 publications

(9 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In short, the LoD requires that a client object must only send messages to objects that are in its immediate scope, which enforces information hiding and makes all coupling explicit. Guo et al show that violations of the LoD lead to more defects [21] 2 . Guo et al's study also shows that violations of the LoD are very common in the Eclipse plugins they evaluated.…”

Section: Methods Chainsmentioning

confidence: 99%

“…2. Example code (3) is a simplified version of a violation of LoD in the JDT core presented in [21].…”

Section: Commentsmentioning

confidence: 99%

“…Method chaining has been advocated as a programming style that leads to more compact and more readable code [18,28]. Careless use of method chaining can lead to violations of the Law of Demeter [36] though, which can lead to more defects [21]. In coding guidelines source code comments are advocated as "absolutely vital to keeping ... code readable" 1 , but also that focus should be on code that clearly communicates intent and functionality to reduce the need for comments [20].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

The Role of Method Chains and Comments in Software Readability and Comprehension—An Experiment

Börstler

Paech

2016

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Software readability and comprehension are important factors in software maintenance. There is a large body of research on software measurement, but the actual factors that make software easier to read or easier to comprehend are not well understood.In the present study, we investigate the role of method chains and code comments in software readability and comprehension. Our analysis comprises data from 104 students with varying programming experience. Readability and comprehension were measured by perceived readability, reading time and performance on a simple cloze test. Regarding perceived readability, our results show statistically significant differences between comment variants, but not between method chain variants. Regarding comprehension, there are no significant differences between method chain or comment variants. Student groups with low and high experience, respectively, show significant differences in perceived readability and performance on the cloze tests. Our results do not show any significant relationships between perceived readability and the other measures taken in the present study. Perceived readability might therefore be insufficient as the sole measure of software readability or comprehension. We also did not find any statistically significant relationships between size and perceived readability, reading time and comprehension. Programming language fluency:Degree of knowledge/experience of the syntax and semantics of the PL.Domain knowledge: Degree of knowledge and/or experience in the application domain.Stress/motivation: Degree of engagement/interest in the task. Size:The plain volume of data/text/information. Readability:The properties that make some programs more easy to read than others.Complexity (spatial and structural): The complexity of the components and their interactions. Cognitive Factors E.g., cognitive load theory, program comprehension theoriesCoherence: Adherence to and application of standards, practices and idioms.

show abstract

Section: Methods Chainsmentioning

confidence: 99%

“…2. Example code (3) is a simplified version of a violation of LoD in the JDT core presented in [21].…”

Section: Commentsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

The Role of Method Chains and Comments in Software Readability and Comprehension—An Experiment

Börstler

Paech

2016

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…For the given method this exception already reduces the number of violations again by 6 and we reached a reduction from 21 potential violations down to 11. 14 (D3) Refactoring: Lift access to figure forward. As we are now able to put aside the obviously irrelevant accesses to the two "Data Classes", let us explore whether the remaining 11 violations are meaningful.…”

Section: Observations In Elbowhandleconstrainx(int)mentioning

confidence: 99%

“…I3) The extension of the idea is just given by naming the two classes. I4) Since the suggested adaptation is a result of 14 Although the comment claims that the DrawingEditor is a "Mediator" that decouples its "participants" (view, drawing, tools), it exposes them via the methods view(), drawing(), tool(). Consequently methods referring to the DrawingEditor may depend also on Drawing, DrawingView or Tool, potentially resulting in "Law of Demeter" violations.…”

mentioning

confidence: 99%

Did JHotDraw respect the Law of Good Style? - An exploratory deep dive into the nature of false positives of bad code smells

Speicher

2020

Programming

View full text Add to dashboard Cite

Developers need to make a constant effort to improve the quality of their code if they want to stay productive. Tools that highlight code locations that could benefit from refactoring are thus highly desirable. The most common name for such locations is "bad code smell". A number of tools offer such quality feedback and there is a substantial body of related research.However, all these tools, including those based on Machine Learning, still produce false positives. Every single false positive shown to the developer places a cognitive burden on her and should thus be avoided. The literature discusses the choice of metric thresholds, the general subjectivity of such a judgment and the relation to conscious design choices, "design ideas".To examine false positives and the relation between bad smells and design ideas, we designed and conducted an exploratory case study. While previous research presented a broad overview, we have chosen a narrow setting to reach for even deeper insights: The framework JHotDraw had been designed so thoughtfully that most smell warnings are expected to be false positives. Nevertheless, the "Law of Good Style", better known as the "Law of Demeter", is a rather restrictive design rule so that we still expected to find some potential bad smells, i.e. violations of this "Law".This combination led to 1215 potential smells of which at most 42 are true positives. We found generic as well as specific design ideas that were traded for the smell. Our confidence in that decision ranged from high enough to very high. We were surprised to realize that the smell definition itself required the formulation of constructive design ideas. Finally we found some smells to be the result of the limitation of the language and one could introduce auxiliary constructive design ideas to compensate for them.The decision whether a potential smell occurrence is actually a true positive was made very meticulously. For that purpose we took three qualities that the smell could affect negatively into account and we discussed the result of the recommended refactorings. If we were convinced that we had found a false positive, we described the relationships with design ideas.The realization that not only general design ideas but also specific design ideas have an influence on whether a potential smell is a true positive turns the problem of false positives from a scientific problem ("What is the true definition of the smell?") to a engineering problem ("How can we incorporate design ideas into smell definitions?"). We recommend to add adaptation points to the smell definitions. Higher layers may then adapt the smell for specific contexts. After adaptation the tool may continuously provide distinct and precise quality feedback, reducing the cognitive load for the developer and preventing habituation. Furthermore, the schema for the discussion of potential smells may be used to elaborate more sets of true and false smell occurrences. Finally, it follows that smell detection based on machine learning should also take signs of...

show abstract

Contrasting dedicated model transformation languages versus general purpose languages: a historical perspective on ATL versus Java based on complexity and size

2021

View full text Add to dashboard Cite

Model transformations are among the key concepts of model-driven engineering (MDE), and dedicated model transformation languages (MTLs) emerged with the popularity of the MDE pssaradigm about 15 to 20 years ago. MTLs claim to increase the ease of development of model transformations by abstracting from recurring transformation aspects and hiding complex semantics behind a simple and intuitive syntax. Nonetheless, MTLs are rarely adopted in practice, there is still no empirical evidence for the claim of easier development, and the argument of abstraction deserves a fresh look in the light of modern general purpose languages (GPLs) which have undergone a significant evolution in the last two decades. In this paper, we report about a study in which we compare the complexity and size of model transformations written in three different languages, namely (i) the Atlas Transformation Language (ATL), (ii) Java SE5 (2004–2009), and (iii) Java SE14 (2020); the Java transformations are derived from an ATL specification using a translation schema we developed for our study. In a nutshell, we found that some of the new features in Java SE14 compared to Java SE5 help to significantly reduce the complexity of transformations written in Java by as much as 45%. At the same time, however, the relative amount of complexity that stems from aspects that ATL can hide from the developer, which is about 40% of the total complexity, stays about the same. Furthermore we discovered that while transformation code in Java SE14 requires up to 25% less lines of code, the number of words written in both versions stays about the same. And while the written number of words stays about the same their distribution throughout the code changes significantly. Based on these results, we discuss the concrete advancements in newer Java versions. We also discuss to which extent new language advancements justify writing transformations in a general purpose language rather than a dedicated transformation language. We further indicate potential avenues for future research on the comparison of MTLs and GPLs in a model transformation context.

show abstract

An Empirical Validation of the Benefits of Adhering to the Law of Demeter

Cited by 7 publications

References 17 publications

The Role of Method Chains and Comments in Software Readability and Comprehension—An Experiment

The Role of Method Chains and Comments in Software Readability and Comprehension—An Experiment

Did JHotDraw respect the Law of Good Style? - An exploratory deep dive into the nature of false positives of bad code smells

Contrasting dedicated model transformation languages versus general purpose languages: a historical perspective on ATL versus Java based on complexity and size

Contact Info

Product

Resources

About