Program code development involves producing program code portions that can be part of one or multiple program files. The program code portions can be created from scratch, or alternatively, previously created program code portions can be reused, possibly with modifications. To be able to reuse previously created program code portions, a developer can perform a search for such previously created program code portions that are relevant to the developer's current work.
Some implementations are described with respect to the following figures.
A program code can refer to computer-readable instructions for performing specific tasks. The program code can be in the form of a source code, which includes code according to a specific programming language. The source code can be transformed into executable code for execution by a computer,
A program code portion can refer to a subset that is less than an entirety of a program file that contains the program code. Alternatively, a program code portion can refer to an entirety of the program file. A program code portion can also be referred to as a program code snippet.
A program code portion can be labeled with one or multiple tags that indicate content of the program code portion. As examples, tags can include the following types of information associated with content of the program code portion: information identifying the technology of the program code portion, information identifying the language of the program code portion, information identifying one or multiple topics associated with the program code portion, information identifying one or multiple skills (of personnel) associated with the program code portion, and so forth.
The technology of a program code portion can specify an environment that the program code portion is designed to work in. For example, the environment can be an environment of a specific operating system, such as WINDOWS®, Linux, Unix, and so forth. Alternatively, the environment can be a web-based environment, a database environment, and so forth.
The language of a program code portion specifies the syntax and the semantics of instructions that make up the program code portion. The syntax defines the form of the instructions, while the semantics assign meanings to terms, operators, and other elements of the instructions.
The tags associated with a program code portion can be useful for various purposes, such as enhancing program code search (to find a program code portion that is relevant to current work of a program developer), to summarize a lengthy program code portion, to assist a developer in understanding the program code portion, and so forth.
Traditional program tagging mechanisms may lack flexibility in tagging program code. Some traditional tagging mechanisms employ program analysis of a program code before tagging can be performed of the program code. The program analysis involves first parsing the program code according to a specific program language syntax; as a result, such traditional program tagging mechanisms cannot be applied to tag program codes according to a language that the program tagging mechanisms are not designed for (or trained for). Also, traditional program tagging mechanisms have to be applied for a complete program module that is to defined by appropriate semantic definitions.
In accordance with some implementations, a tagger is provided that performs automatic tagging of a program code portion, where the tagger can be used for program code portions of any programming language or technology, and to identify tags from a collection of tags that does not have to be predefined. The tagger does not assume any specific programming language or technology of the program code portion. The tagger can be used for tagging program code portions of different programming languages without having to modify the tagger, and without having to re-train the tagger. This enhances flexibility over other program tagging mechanisms that are designed to work with specific programming languages or technologies (and thus assume specific programming language syntax and semantics) such other program tagging mechanisms would not be useable to tag program codes of other programming languages or technologies without modification or retraining of the program tagging mechanisms.
The tagger according to some implementations can also be applied to tag any arbitrary portion of a program code. An “arbitrary” portion of a program code refers to any portion of the program code that is found within the program code. The program code portion that is tagged does not have to be a semantically defined module, according to specific semantic definitions of a respective programming language. For example, certain programming languages specify that a semantically defined module is defined between an opening brace {and a closing brace}. Alternatively, the semantically defined module is included within a single
Since the tagger does not assume any specific programming language or technology, the tagger can be used for tagging program code portions according to new programming languages or technologies.
By being able to tag arbitrary program code portion, regardless of the programming language or technology of the program code portion, tagging of a hybrid collection of program codes is possible, where the program code portions in the hybrid collection can be according to different programming languages or technologies.
The tagger according to some implementations also does not assume a predefined collection of tags. Having to specify a predefined collection of tags for a program tagging mechanism reduces flexibility in the use of the program tagging mechanism. The program tagging mechanism would not be able to assign a new tag (that is not part of the predefined collection of tags) to a program code, unless the program tagging mechanism is modified or re-trained. The tagger in a accordance with some implementations is able to assign new tags to program code portions, which increases flexibility and ease of use of the tagger.
The tagging performed by the tagger according to some implementations is based on a data structure that is created based on examples that include respective program code portions associated with corresponding tags that indicate content of the respective program code portions (e.g. the programming language of a program code portion, the technology of the program code portion, topic(s) of a program code portion, skill(s) associated with a program code portions, etc.). As noted above, the tagger is able to support new programming languages and/or new tags without having to modify or retrain the tagger. Rather, to support tagging for a new programming language and/or for a new tag, a collection of examples that include respective program code portions associated with corresponding tags can be updated by simply adding one or multiple further examples relating to the new programming language and/or new tag. In this manner, even though the collection of examples is modified, the tagger remains unmodified, and can continue to be used for tagging additional program code portions.
The index creator 106 parses the program examples in the collection 108. The parsing can include removing of non-text elements from each program example. A non-text element of a program example can include any of the following: an operator, a bracket, or any other element of the program code portion that is not text. Note that the parsing does not assume any specific programming language or technology; the parsing distinguishes between text and non-text elements.
The index creator 106 can also rewrite text in a program example into words according to specified coding conventions. For example, text such as “findNextElement,” which is according to the camel-hump convention, can be rewritten into the following words (which make up a token): “Find next element.” Similarly, the text “find_next_Element” can also be rewritten into the foregoing token. Rewriting text in different forms into common tokens (each token including one or multiple words) allows for better accuracy in comparing the program examples to program code portions to be tagged, as discussed further below.
The index creator 106 may also perform other pre-processing of the program examples. For example, the index creator 106 may remove redundant text in each program example, Removing redundant text helps to provide more compact program examples so that subsequent tagging can be performed more efficiently and accurately.
The examples index 104 is an index that associates sets of tokens (words produced by the index creator 106) with respective one or multiple tags. For example, the examples index 104 can include multiple entries, where each entry contains a respective set of tokens, and associated one or multiple tags (or pointers or references to such one or multiple tags). The pointers or references specify locations where the respective tags can be retrieved. Note that in some cases, a set of tokens of an entry in the index 104 may include just one token.
The tagger 102 also receives a program code portion 110 that is to be tagged. The program code portion 110 is compared to the examples index 104 by the tagger 102, which produces one or multiple tags 112 for the program code portion 110.
The tagger 102 determines (at 204) at least one tag to associate with a first program code portion based on the data structure.
At a later point in time, the tagger 102 receives (at 206) an updated version of the data structure, which may be updated due to addition of one or multiple program examples corresponding to a new programming language, a new technology, and/or a new tag not represented by the data structure received at 202.
The tagger 102 remains unmodified even though the updated version of the data structure is received. The un-modified tagger 102 determines (at 208) at least one tag to associate with a second program code portion based on the updated version of the data structure.
The application stage 304 receives (at 306) a program code, which can be a program file (or multiple program files). A portion of the received program code is selected (at 308), where the selected portion can be less than the entirety of the received program code, or the selected portion can be the entirety of the received program code. The selection of the program code portion can be a manual selection (made by a human) or an automatic selection (made by the tagger 102 or some other automated entity based on one or multiple selection criteria). In other implementations, other techniques can be used for providing a portion of the received program code as input to the tagger 102. In further implementations, the program code to be tagged is not a part of any program file. For example, the program code can, for example, be attached a requirements document, be part of an online programming manual, be an answer to a question in an interview, and so forth.
The selected program code portion is then parsed (at 310), which can include removing non-text elements of the selected program code portion, and extracting text elements (elements of the program code portion that contains text and is without non-text elements) from the selected program code portions. The parsing can also rewrite text of the selected program code portion into one or multiple sets of tokens. Note that the parsing does not assume any specific programming language of the selected program code portion.
The one or multiple sets of tokens are then compared (at 312) by the tagger 102 to elements (one or multiple sets of tokens) of the program examples in the examples index 104. Based on the comparing, the tagger 102 calculates (at 314) scores for respective tags identified by the comparing. Using the scores, one or multiple tags can be selected (at 316), such as the N tags having the highest scores (where N can be greater than or equal to one).
The tasks 310, 312, and 314 can be performed by the tagger 102. The tag selection performed at 316 can also be performed by the tagger 102, or alternatively, can be performed by a user or an application or another entity. An application can refer to machine-readable instructions that can receive the tags and respective scores from the tagger 102, and that can use these scores to select a subset of the tags.
The comparing performed at 312 can use a similarity function, such as a cosine document similarity function. In other examples, other types of similarity functions can be used.
To find a set of similar program examples (that are similar to a given program code portion that is to be tagged), the similarity function can use a metric that measures how similar two text portions are (in this case, a “text portion” refers to tokens parsed from a program code portion in a program example and tokens parsed from the given program code portion to be tagged). If a cosine document similarity function is used, then the metric that measures similarity of text portions is a cosine document similarity metric.
Once a set of the top K (K≧1) most similar program examples from the examples index 104 is found by the cosine document similarity function (or some other similarity function), the tagger 102 assigns a score to each one of the tags associated with the top K most similar program examples. In some implementations, a score for a tag can be calculated as follows. Note that the same tag may be associated with multiple program examples. For example, program example A is labeled with tags p and q, and program example B is labeled with tags p and r—in this case, the set of tags include p, q and r, where p repeats both program examples A and B.
For each tag, the tagger can sum (or perform another aggregate such as average, identify a maximum or minimum, etc.) the similarity scores of all the examples in the set of top K examples that are labeled with this tag. In the foregoing case, for tag p, the similarity scores of both program examples A and B are summed. However, the score for tag q is the similarity score of program example A, and the score for tag r is the similarity score of program example B.
Next, the maximal score for the set of tags is determined. The maximal score can be the maximum of scores computed for the tags in the set of the tags. The tagger 102 next divides the scores of each tag in the set of tags by the maximal score, to produce normalized scores for the respective tags. The normalized scores can then be returned as scores for the tags, which can be output for selection at 316. Alternatively, the normalized scores can be compared to a specified threshold, and those tags from the set of tags having normalized scores that exceed the specified threshold are returned as tags for selection at 316. More generally, some other filtering function can be used to select a subset of tags returned by the tagger 102.
More formally, let D be a set of labeled program examples, where tags(d) denotes the set of tags of a program example d. Let sim(x, y) be the similarity function (e.g. a cosine document similarity function) that determines similarity between documents x and y (i.e. program code portion to be tagged and program example). The tagger 102 can be represented as a function label(x, k, c, D), where x is a program code portion to be tagged, k is the number of similar program examples from the examples index 104 to consider, c is a specified threshold, and D is the collection of program examples labelled with tags. The function label(x, k, c, D) returns a set of tags together with their scores, as follows.
Although specific techniques of assigning scores to tags for a given program tag portion to be tagged have been discussed above, it is noted that other techniques for assigning scores to tags can be used in other implementations. Also, in other implementations, other techniques for selecting tags output by the tagger 102 can be employed.
By using the tagger 102 according to some implementations, tagging of program code portions can be performed without having to design or train the tagger 102 for any specific programming language or technology. The tagger 102 can be made less complex and thus can execute more efficiently. The tagger 102 can also be flexibly used with any arbitrary portion of a program code, and can be used for various tags without having to design or train the tagger 102 for a predefined set of tags.
The processor 402 can be coupled to a network interface 404 to allow the computer system 400 to communicate over a data network, Additionally, the processor(s) 402 can be coupled to a non-transitory computer-readable or machine-readable storage medium (or storage media) 406, which can store the collection of program examples 108 and other information, including instructions and data.
The storage medium or media 406 can include any of various different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.
In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2013/075288 | 12/16/2013 | WO | 00 |