Taxonomy
Definitions
| Awareness | This category groups together information items the recommender should be aware of to improve its recommendations. |
| Awareness> Coding Context | The recommended code is based on a specific coding context, usually representing the code written by the developer in the IDE |
| Awareness> Coding history | The recommended code is generated/improved based on development activities performed in the past. The past development activities could be related to the developer receiving the recommendation or to other developers. In other words, "natural" coding solutions are favored. |
| Awareness> Developer's tasks | The code recommender is aware of the task(s) the developer is working on. Differently from the coding context that only captures the code under development in a specific moment, in this case a more complete view of the developer's tasks is available (e.g., the tool could mine from the issue tracker the issues assigned to the developer and use this information to generate/improve its recommendations) |
| Awareness> Developers' knowledge | If multiple recommendations are possible, the one using code that is more familiar to the developer must be used (e.g., the code using APIs already used in the past by the developer receiving the recommendation). |
| Characteristics of recommended code | This category groups together specific code characteristics (detailed in the leaf nodes) that might be desirable for the recommended code. |
| Characteristics of recommended code> Structural characteristics | The recommended code meets specific structural characteristics of the code (detailed in the leaf nodes) that might be desirable. |
| Characteristics of recommended code> Structural characteristics> Unambiguous | The recommended code is unambiguous (e.g., the tool does not suggest multiple imports with the same name, which make it difficult to identify the one actually needed) |
| Characteristics of recommended code> Structural characteristics> Easy to integrate in code under development | The recommended code does not require major changes to be integrated in the code under development (e.g., a code using object types not available in the language [8] but defined in other projects from which the recommended code has been learned is difficult to reuse). |
| Characteristics of recommended code> Structural characteristics> Precise typing information | The recommended code relies on specific types (e.g., java.time.LocalDate ) rather than the generic one (e.g., Object). |
| Characteristics of recommended code> Structural characteristics> Type Checked | The recommender checks types when completing statements, ensuring values assigned to a variable are compatible with its type. |
| Characteristics of recommended code> Adaptive | The recommended code is customized based on specific factors (detailed in the leaf nodes). |
| Characteristics of recommended code> Adaptive> Coding context | The recommended code is adapted to the code the developer is writing (see leaf nodes). |
| Characteristics of recommended code> Adaptive> Coding context> Identifier names | The recommended code is adapted to the context of the recommendation by using the same variable [10] names of the code it completes when possible. |
| Characteristics of recommended code> Adaptive> Coding context> System's vocabulary | The recommended code relies on the system's vocabulary when possible (e.g., by reusing therms to synthesize identifiers) |
| Characteristics of recommended code> Adaptive> Developer's coding style | The recommended code is adapted to the developer's coding style (e.g., using extra parenthesis to better format code if this is a practice frequently performed by the developer) |
| Characteristics of recommended code> Code quality | The recommended code meets specificy quality criteria (see leaf nodes) |
| Characteristics of recommended code> Code quality> Maintanability | The recommended code is easy to maintain |
| Characteristics of recommended code> Code quality> Performance | The recommended code appears is optimized in terms of performance (e.g., it does not introduce unneeded operations) |
| Characteristics of recommended code> Code quality> Robustness | The recommended code is robust when dealing with possible erroneous situations (e.g., a null check is implemented if needed) |
| Characteristics of recommended code> Code quality> High reusability | The recommended code is easy to reuse. This is particularly relevant for recommender systems suggesting code components at higher granularity (e.g., entire methods see Wen et al. ICSE 2021) |
| Characteristics of recommended code> Code quality> Meets best coding practices | The recommended code meets best coding practices. The latter depend on the language/paradigm in use. |
| Characteristics of recommended code> Code quality> Meets best coding practices> Meets company/client standards | The recommended code can be configured to meet specific best coding practices defined by the company/client (e.g., if variables are named with camelCase, the same convention must be adopted in the [9] recommended code). |
| Characteristics of recommended code> Code quality> High readability and understandability | The recommended code must be readable (e.g., avoid very long statements, adopt indentation) and easy to understand. |
| Characteristics of recommended code> Code quality> High readability and understandability> Concise Code | The recommended code is as short and simple as possible |
| Characteristics of recommended code> Code quality> High readability and understandability> Step-by-step solution | In case it spans across many statements, the recommendation is divided into multiple chunks (by using a blank line), each one responsible for a sub-task. |
| Characteristics of recommended code> Code quality> High readability and understandability> Meaningful identifiers | The recommended code must use meaningful identifiers rathern than placeholders. |
| Characteristics of recommended code> Code quality> Correctness | The recommended code must be bug-free. |
| Characteristics of recommended code> Code quality> Correctness> Bug/Vulnerability free | The recommended code is does not introduce bugs and/or vulnerabilities. |
| Characteristics of recommended code> Code quality> Correctness> Correct syntax | The recommended code does not introduce syntax errors. |
| Functionality | This category groups together the features developers would like to see in source code recommenders (see leaf nodes) |
| Functionality> Coverage of support | This subcategory details the desiderata of developers when it comes to the coverage of the recommender tool (i.e., the different coding scenarios it can support) |
| Functionality> Coverage of support> Language keywords | The recommender is able to suggest the language keywords when needed |
| Functionality> Coverage of support> Support for third-party libraries | The recommender is able to propose code recommendations when dealing with code using third-party libraries |
| Functionality> Coverage of support> Support for identifiers | The recommender provides support for identifiers, suggesting them when needed |
| Functionality> Coverage of support> Support for identifiers> Asks developer when meaningful identifiers cannot be defined | If the recommender cannot identify meaningful identifiers for a piece of code to recommend, it should interact with the developer for further information. |
| Functionality> Coverage of support> Autocomplete refactorings | The recommender is able to autocomplete a refactoring operation started by the developer. |
| Functionality> Coverage of support> Multi-lingual code statements (e.g., C# and SQL) | The recommender can generate code recommendations even when multi-lingual code statements (e.g., C# and SQL) are written by the developer |
| Functionality> Coverage of support> Support for multi-token code completion | The recommender can generate code recommendations that are not limited to a single token, but span several tokens. |
| Functionality> Coverage of support> Support for multi-token code completion> Assert statements | The recommender can automatically generate assert statements for a given test. |
| Functionality> Coverage of support> Support for multi-token code completion> Control structures | The recommender supports code completion for non-trivial code statements such as control structures (e.g., guessing the condition in an if statement). |
| Functionality> Coverage of support> Support for multi-token code completion> Entire statement(s) | The recommender can generate entire code statement(s). |
| Functionality> Coverage of support> Support for multi-token code completion> Implementation for stubs | The recommender is able to implement stub functions given their signature. |
| Functionality> Coverage of support> Support for multi-token code completion> Templates | The recommender can recommend code templates, representing "abstract code" that the developer can then fill-in (e.g., a template for a for loop). |
| Functionality> Coverage of support> Support for multi-token code completion> Functions' Invocations/Parameters | The recommender is able to recommend the parameters' values in a function invocation. |
| Functionality> Recommended modality | The modality used by the recommender when suggesting a recommendation |
| Functionality> Recommended modality> Ask additional information when what the developer is doing is not clear | If the recommender cannot infer what the developer is doing it is able to ask additional information to better contextualize the recommendations. |
| Functionality> Recommended modality> Multiple options available | The recommender is able to generate multiple recommendations for a given scenario. |
| Functionality> Recommended modality> Proactive: perceives when developer needs help | The recommender perceives when the developer needs help (e.g., it is not writing for long time) and starts triggering recommendations. It does not need to be explicitly invoked by the developer. |
| Functionality> Recommended modality> Smart ranking | When multiple options are available, the tool ranks the recommendations using a smart criterion rather than alphabetical order. |
| Functionality> Recommended modality> Open source | If the recommeded code is retrieved from a dataset, such a dataset must feature open source code which is less likely to result in licensing issues and is more likely to have been widely tested |
| Functionality> Provides additional information | The recommender provides additional information together with the suggestion |
| Functionality> Provides additional information > Highlights required edits | If the code that the developer is writing is very similar to other existing, it highlights the differences that might be errors. |
| Functionality> Provides additional information > Provides rationale justifying the recommendation | The tool provides a rationale to justify the given recommendation (e.g., you are seeing this code because ...). |
| Characteristics of recommended code> Provides additional information > Documentation | The recommended code includes the documentation |
| Characteristics of recommended code> Provides additional information > Documentation> Commented code | The recommended code features comments documenting the statements |
| Characteristics of recommended code> Provides additional information > Documentation> Code example | The recommender system can generate usage examples showing how to use specific API/methods |
| Functionality> Self-improving based on feedback | The recommender improves the suggestions based on the feedback received by the developer for past recommendations. |
| Functionality> Early prediction | The recommender is able to trigger recommendations early in the coding process (e.g., the developer just wrote a few code tokens). |
| Functionality> Configurable | The recommender is customizable based on developers' preferences (e.g., see leaf node) |
| Usability | This category groups together usability aspects they would like to see in source code recommenders (see leaf nodes) |
| Usability> Intuitive | The recommender is intuitive (e.g., shallow learning curve) |
| Usability> No overhead while coding | The recommender does not hinder coding (e.g., a button can be pressed to accept/decline the recommendations) and does not require context-switch. |
| Usability> Non-invasive | The recommender is never in control of the code writing, it only provides suggestion. |
| Usability> Non-invasive> Asks confirmation before changing code | The recommender asks confirmation to the developer before implementing code. |
| Usability> Integrated with IDE | The recommender is integrated within the IDE. |
| Usability> High responsiveness | The recommender is responsive, not causing lagging while coding. |
| Accuracy of recommendations | The recommended code is accurate (i.e., the recommender is able to suggest a code semantically equivalent to the one the developer was going to write) |
| Accuracy of recommendations> Filtering based on confidence | The recommender does not trigger recommendations when its confidence is low. |
| Accuracy of recommendations> Filtering based on confidence> Templating in low-confidence scenarios | If the recommender has a low-confidence about a recommendation, it is able to suggest a template for the recommendation rather than the complete raw code. |