Graph-based Pattern-oriented, Context-sensitive Code Completion

Anh Tuan Nguyen, Tung Thanh Nguyen, Hoan Anh Nguyen, Ahmed Tamrawi, Hung Viet Nguyen, Jafar Al-Kofahi,
Tien N. Nguyen

Video Demo Downloads

Motivating Examples

Alternative Patterns

 

Example 1
Figure 1. SWT Usage Example 1

 

The lines 4-7 of Figure 1 illustrates an SWT usage pattern for creating a Button object. According to SWT documentation, a Button object can be instantiated with two parameters: one for its SWT window container, and one for the button style. Then, other properties of the button could be set including its textual label (via method setText), its size (via setSize), and its location (via setLocation).

Example 2
Figure 2. SWT Usage Example 2

 

SWT also provides another usage pattern in which the layout (e.g. size, location) of a button is controlled indirectly via a FormData object. As seen in Figure 2, instead of calling setSize and setLocation, one can specify the layout information via a FormData object (line 3), and associate it with the button. Then, the layout’s properties (e.g. right corner, bottom position) can be set via that FormData object (lines 5-6).

This example shows that there might exist multiple usage patterns for a specific task (called alternative patterns). Alternative usage patterns can share or involve different API elements (classes/methods), and an API element can be involved in different usage patterns. This implies that a pattern-oriented code completion tool must be context-sensitive, i.e. it must take into account the context of the code under editing, such as the API elements currently in use, in order to provide suitable code completion.

For example, assume that in a code fragment, a developer wrote the code to create a Button object as in the line 1 of Figure 2. If the code completion tool is activated, both of the patterns for creating a button are still under consideration.

Example 2b

 

However, if (s)he finished the lines 1-3 of Figure 2, due to the existence of a FormData object, the tool could predict that the developer intends to use the pattern of creating a button having a layout object. Thus, it should recommend toward that pattern for code completion (e.g. recommend line 4), rather than its alternative pattern. That is, it should recommend a call to setLayoutData (line 4), and should not recommend the calls to two methods setSize and setLocation.