Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Saheel Godhane

dblp:164/5981 · DBLP profile ↗
← Back
1ranked-venue papers
0as first author
0since 2021 · last 2016
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Empirical software engineering · 70% Debugging and program repair · 23% Software maintenance and evolution · 7%

Topics — the 5 heaviest of 6, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Empirical software engineering › mining software repositories › source-code mining
code naturalness
0.212016
On the "naturalness" of buggy code · ICSE 2016
Empirical software engineering › mining software repositories
defect prediction
0.212016
On the "naturalness" of buggy code · ICSE 2016
Debugging and program repair
fault localization
0.212016
On the "naturalness" of buggy code · ICSE 2016
Empirical software engineering
mining software repositories
0.212016
On the "naturalness" of buggy code · ICSE 2016
Software maintenance and evolution › code review
code inspection
0.112016
On the "naturalness" of buggy code · ICSE 2016

Methods — techniques the papers use, named apart from their topics

statistical language model · 0.2entropy · 0.2
YearPublicationVenuePosition
2016 On the "naturalness" of buggy code
abstract
Real software, the kind working programmers produce by the kLOC to solve real-world problems, tends to be "natural", like speech or natural language; it tends to be highly repetitive and predictable. Researchers have captured this naturalness of software through statistical models and used them to good effect in suggestion engines, porting tools, coding standards checkers, and idiom miners. This suggests that code that appears improbable, or surprising, to a good statistical language model is "unnatural" in some sense, and thus possibly suspicious. In this paper, we investigate this hypothesis. We consider a large corpus of bug fix commits (ca. 7,139), from 10 different Java projects, and focus on its language statistics, evaluating the naturalness of buggy code and the corresponding fixes. We find that code with bugs tends to be more entropic (i.e. unnatural), becoming less so as bugs are fixed. Ordering files for inspection by their average entropy yields cost-effectiveness scores comparable to popular defect prediction methods. At a finer granularity, focusing on highly entropic lines is similar in cost-effectiveness to some well-known static bug finders (PMD, FindBugs) and ordering warnings from these bug finders using an entropy measure improves the cost-effectiveness of inspecting code implicated in warnings. This suggests that entropy may be a valid, simple way to complement the effectiveness of PMD or FindBugs, and that search-based bug-fixing methods may benefit from using entropy both for fault-localization and searching for fixes.
Baishakhi Ray, Vincent J. Hellendoorn, Saheel Godhane, Zhaopeng Tu, Alberto Bacchelli, Premkumar T. Devanbu
ICSE3