Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
heuristics_for_identifying_code_elements [2013/06/16 23:36] mnrose |
heuristics_for_identifying_code_elements [2013/06/16 23:40] (current) mnrose |
||
|---|---|---|---|
| Line 7: | Line 7: | ||
| * Rigby & Robillard 2013: Naming conventions, camel casing and lightweight techniques based on regular expressions, just as in Bachelli et al. 2010. Uses "regular expressions approximated following constructs in the Java Language Specification": qualified terms, package names, variable declarations, qualified variables, method chains, class definitions including inheritance, declarations, method overrides, inner classes, constructors, stack traces, annotations, and exceptions. Regular expressions are ordered from most precise to most flexible. | * Rigby & Robillard 2013: Naming conventions, camel casing and lightweight techniques based on regular expressions, just as in Bachelli et al. 2010. Uses "regular expressions approximated following constructs in the Java Language Specification": qualified terms, package names, variable declarations, qualified variables, method chains, class definitions including inheritance, declarations, method overrides, inner classes, constructors, stack traces, annotations, and exceptions. Regular expressions are ordered from most precise to most flexible. | ||
| - | * Bachelli et al. 2010: References entities by their names. Use of camel casing for class names. Original source for lightweight linking technique. Switches to strict matching by name when a code-like term turns out not to be compound. Has a regular expression that accounts for punctuation within names because entity name can be written as a single word separated from others by empty space or connected by punctuation. | + | * Bachelli et al. 2010: References entities by their names. Use of camel casing for class names. Original source for lightweight linking technique. Switches to strict matching by name when a code-like term turns out not to be compound. Has a regular expression that accounts for punctuation within names because entity name can be written as a single word separated from others by empty space or connected by punctuation. |
| + | |||
| + | * Antoniol et al. 2002: Assumes "people use meaningful names for program items", capitalizes on mnemonics for identifiers. | ||
| + | |||
| + | * Xie et al. 2012: Might be useful if we could get more information as to their methods. Paper is on identifying sentences that contain the information required for code contracts and inferring method specifications from that information, but it doesn't state how the sentences are identified in the first place. | ||
