Recognizing Words from Source Code Identifiers Using Speech Recognition Techniques

Madani, Nioosha; Guerrouj, Latifa; Penta, Massimiliano Di; Guéhéneuc, Yann‐Gaël; Antoniol, Giuliano

doi:10.1109/csmr.2010.31

Cited by 57 publications

(48 citation statements)

References 24 publications

(46 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Good quality identifiers must be understand-able, complete, and unambiguous. To obtain these properties, expert may use splitting/expansion [Madani et al(2010)Madani, Guerrouj, Di Penta, Guéhéneuc, and Antoniol] approach to split identifiers such as cmdpntr into cmd pntr and then expand the resulting words into command pointer. The results of the splitting/expansion approach have all the above-mentioned properties of good identifiers.…”

Section: Identification Of Preventive Measuresmentioning

confidence: 99%

Factors Impacting the Inputs of Traceability Recovery Approaches

Ali

Guéhéneuc

Antoniol

2011

Software and Systems Traceability

View full text Add to dashboard Cite

In requirement engineering, researchers have proposed various tractability recovery approaches. To the best of our knowledge, all traceability recovery approaches have low precision and recall. Our main claim in this chapter is that there exist factors that impact the traceability approaches' inputs, in particular source document, target document, and experts' opinion, that cause low precision and recall. In this chapter, we pursue four objectives: first, to identify and document factors that impact traceability recovery approaches' inputs; second, to identify metrics/tools to measure/improve the quality of the inputs with respect to the identified factors, third, to provide precautions to control these factors, and, fourth, to empirically prove and quantify the effect of one of these factors-expert's programming knowledge-on the traceability recovery approaches' inputs. To achieve the first two objectives, we perform an incremental literature review of traceability recovery approaches and identify and document three key inputs and the seven factors impacting these inputs, out of 12 identified factors. We analyse the reported results in literature for the identified factors to address our third objective. We conduct an empirical study to assess the impact of expert's programming knowledge, to address our fourth objective. We use the effort, number of correct answers, and time to measure the effect of expert's programming knowledge on traceability recovery. We conclude that, in the literature, seven factors impacting the inputs of traceability recovery approaches have been identified, documented, and reported along with related metrics/tools and precautions. We suggest that practitioners should be wary of these seven factors and researchers should focus on the five others to improve traceability recovery approaches.

show abstract

Section: Identification Of Preventive Measuresmentioning

confidence: 99%

Factors Impacting the Inputs of Traceability Recovery Approaches

Ali

Guéhéneuc

Antoniol

2011

Software and Systems Traceability

View full text Add to dashboard Cite

show abstract

“…The issue submitter (and patch creator as well) stated that this inconsistency was propagated to another plug-in (ApacheDS plug-ins for Studio) via a resource file (server.xml) and in the documentation as well. Even if a writer distinguishes the two words based on their definition consistently throughout the project [16], program readers may not precisely catch the slight difference between the words and this can eventually result in a misunderstanding. Similar issues are observed in a wide range of programs, such as in a pair of Real and Scala described in Issue 7 .…”

Section: Three Types Of Inconsistent Identifiersmentioning

confidence: 99%

“…For example, the word free can be used as a verb, adjective, and adverb in natural language while only the use as a verb of the word was observed in a specific software project. One of the real cases for this inconsistency is shown in an issue report 16 that indicates that the word return in a variable name returnString can be confusing since return is often used in a method identifier as a verb. Consequently, the corresponding patch 17 changes returnString to resultString.…”

Section: Three Types Of Inconsistent Identifiersmentioning

confidence: 99%

“…These words were validated by the subjects during the manual evaluation. Although there are several techniques [8,16] that can recover the original words from abbreviated code identifiers, our approach uses a manual approach since it is simple and effective for our purpose. Automatic abbreviation recovery remains a task for future work.…”

Section: Collecting Abbreviationsmentioning

confidence: 99%

See 1 more Smart Citation

Automatic identifier inconsistency detection using code dictionary

Kim

2015

Empir Software Eng

View full text Add to dashboard Cite

In the revised version of our manuscript, we have incorporated all the comments and suggestions of the three reviewers as best as we can. This letter includes both the reviewer comments and our responses to these comments. In these responses, we have explained changes made to the manuscript on the basis of the reviewers' suggestions. We have also mentioned the locations in our revised manuscript where the changes have been made to help the reviewers locate these revisions. Wherever possible, we have provided an excerpt of the revised part. Sincerely yours, The Authors Editor's CommentsIn preparing the new revision authors addressed most of the reviewers concerns. The writing style improved and comparison with another tool is now presented.The paper quality was substantially improved, however, there are still a few points authors may want to consider prior to publication. In particular some style issues (reviewer 1) and some concern about the presented examples (see reviewer 3). We understand that sometime it may be more a matter of taste, nevertheless, it is important that examples clearly motivate and properly set the stage for the paper. ⇒ We revised the style and example issues according to the reviewer comments. Please see the following responses.Overall we suggest authors check the style (reviewer 1) and seriously consider comments of reviewer 3 on the paper presented examples, ambiguity and the need of such an approach. ⇒ For the Reviewer 1's comments, we revised all the style issues in Abstract, Section 1, 2, 3, and 4 as suggested. For the Reviewer 3's comments, we tried to convince why we used the examples and how our evaluation process confirmed that the examples are valid. Note that 16 human subjects reviewed the detection results and these are some of examples shown in the paper. Reviewer #1's Comments:The authors substantially improved the manuscript: they added a comparison with existing work, fixed a few errors, and rephrased most of the unclear sentences. ⇒ We appreciate the constructive suggestions and comments.I would suggest a few minor improvements before publication: incFile(): Based on the Javadoc of the method ("Method implements the logic for filtering file name inclusion") this must be expanded to 'include' rather than 'increase' as it is currently in Table 2. ⇒ This example in Table 2 is removed from the row ("inc ⇒ increase") as the reviewer pointed out."inconsistent identifiers frequently and inevitably occurs" "this issue can be arise" "We then conducted a user study to check the validity of these results. This study asked 16 developers to evaluate the precision and recall of detection results." > "To evaluate the precision and recall of detection results we conducted a user study involving 16 developers." "A naming convention defines a specific way in which names identifiers in programs." > to name? ⇒ All these typos and grammar errors are fixed accordingly. Reviewer #2's Comments:The authors have properly addressed my remaining comments and suggestions. In particular, they have perf...

show abstract

“…Current approaches to identifier name tokenisation [7,8,15] report accuracies of around 96% for the tokenisation of unique identifier names. However, some approaches ignore identifier names containing digits [8,15], or treat digits as discrete tokens [7].…”

Section: Introductionmentioning

confidence: 99%

Improving the Tokenisation of Identifier Names

Butler

Wermelinger

et al. 2011

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Identifier names are the main vehicle for semantic information during program comprehension. Identifier names are tokenised into their semantic constituents by tools supporting program comprehension tasks, including concept location and requirements traceability. We present an approach to the automated tokenisation of identifier names that improves on existing techniques in two ways. First, it improves tokenisation accuracy for identifier names of a single case and those containing digits. Second, performance gains over existing techniques are achieved using smaller oracles. Accuracy was evaluated by comparing the output of our algorithm to manual tokenisations of 28,000 identifier names drawn from 60 open source Java projects totalling 16.5 MSLOC. We also undertook a study of the typographical features of identifier names (single case, use of digits, etc.) per object-oriented construct (class names, method names, etc.), thus providing an insight into naming conventions in industrial-scale object-oriented code. Our tokenisation tool and datasets are publicly available 1 .

show abstract

Recognizing Words from Source Code Identifiers Using Speech Recognition Techniques

Cited by 57 publications

References 24 publications

Factors Impacting the Inputs of Traceability Recovery Approaches

Factors Impacting the Inputs of Traceability Recovery Approaches

Automatic identifier inconsistency detection using code dictionary

Improving the Tokenisation of Identifier Names

Contact Info

Product

Resources

About