Understanding someone else's code: Analysis of experiences

Lakhotia, Arun

doi:10.1016/0164-1212(93)90101-3

Cited by 68 publications

(39 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…This finding was confirmed by the studies of Ted Tenny [19]. But as the example of Lakhotia shows, sometimes programmers do not care that someone else might want to understand the source code [13].…”

Section: Introductionsupporting

confidence: 72%

Do Code and Comments Co-Evolve? On the Relation between Source Code and Comment Changes

Fluri

Würsch

Gall

2007

14th Working Conference on Reverse Engineering (WCRE 2007)

173

View full text Add to dashboard Cite

Comments are valuable especially for program understanding and maintenance, but do developers comment their code? To which extent do they add comments or adapt them when they evolve the code? We examine the question whether source code and associated comments are really changed together along the evolutionary history of a software system. In this paper, we describe an approach to map code and comments to observe their co-evolution over multiple versions. We investigated three open source systems (i.e., ArgoUML, Azureus, and JDT Core) and describe how comments and code co-evolved over time. Some of our findings show that: 1) newly added code|despite its growth rate|barely gets commented; 2) class and method declarations are commented most frequently but far less, for example, method calls; and 3) that 97% of comment changes are done in the same revision as the associated source code change.

show abstract

Section: Introductionsupporting

confidence: 72%

Do Code and Comments Co-Evolve? On the Relation between Source Code and Comment Changes

Fluri

Würsch

Gall

2007

14th Working Conference on Reverse Engineering (WCRE 2007)

173

View full text Add to dashboard Cite

show abstract

“…In general, people may find it easier to read a model about the domain they are familiar with than other models. While this has not been established for process models, it is known from software engineering that domain knowledge affects the understanding of particular code [23]. We aim to neutralize the impact of domain knowledge by using abstract letters as activity names.…”

Section: Potential Interactionsmentioning

confidence: 99%

The Impact of Secondary Notation on Process Model Understanding

Schrepfer

Wolf

Mendling

et al. 2009

Lecture Notes in Business Information Processing

View full text Add to dashboard Cite

Abstract. Models of business processes are usually created and presented using some visual notation. In this way, one can express important activities, milestones, and actors of a process using interconnected graphical symbols. While it has been established for other types of models that their graphical layout is a factor in making sense of these, this aspect has not been investigated in the business process modeling area. This paper proposes a set of propositions about the effects of the secondary notation, which entails layout, on process model comprehension. While individual graphical readership and pattern recognition skills are known mediators in interpreting visual cues, these propositions take expertise into account. The goal of this paper is to lay the foundation of follow-up, empirical investigations to challenge these propositions.

show abstract

“…However, studies of program comprehension consistently find that programmers would prefer to focus on small sections of code during software maintenance [52,35,36,20], and "try to avoid" [45] comprehending the entire system. The result is that programmers skim source code (e.g., read only method signatures or important keywords) Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page.…”

Section: Introductionmentioning

confidence: 99%

Improving automated source code summarization via an eye-tracking study of programmers

Rodeghero

McMillan

McBurney

et al. 2014

Proceedings of the 36th International Conference on Software Engineering

165

106

View full text Add to dashboard Cite

Source Code Summarization is an emerging technology for automatically generating brief descriptions of code. Current summarization techniques work by selecting a subset of the statements and keywords from the code, and then including information from those statements and keywords in the summary. The quality of the summary depends heavily on the process of selecting the subset: a high-quality selection would contain the same statements and keywords that a programmer would choose. Unfortunately, little evidence exists about the statements and keywords that programmers view as important when they summarize source code. In this paper, we present an eye-tracking study of 10 professional Java programmers in which the programmers read Java methods and wrote English summaries of those methods. We apply the findings to build a novel summarization tool. Then, we evaluate this tool and provide evidence to support the development of source code summarization systems.

show abstract

Understanding someone else's code: Analysis of experiences

Cited by 68 publications

References 5 publications

Do Code and Comments Co-Evolve? On the Relation between Source Code and Comment Changes

Do Code and Comments Co-Evolve? On the Relation between Source Code and Comment Changes

The Impact of Secondary Notation on Process Model Understanding

Improving automated source code summarization via an eye-tracking study of programmers

Contact Info

Product

Resources

About