-
Notifications
You must be signed in to change notification settings - Fork 6
/
hints.txt
57 lines (55 loc) · 3.45 KB
/
hints.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
1: Think of mutating comparison operators in a condition, e.g, < to >= and == to !=... Consider all possibilities and combinations even == to >, != to <= ...for example.
Original: if x < 10:
Fix: if x >= 10:
- 2: Think of replacing variables with explicit values (when possible) or with close variable names
Original: result = add(x, y)
Fix: result = add(5, 8)
Original: mult = y + 1
Fix: add = z + 1
- 3: Consider changing some tokens partially, e.g, minXXX to maxXXX startXXX to endXXX, vice versa and so on... (consider all possibilities)
Original: start_elements_valid = True
Fix: end_elements_valid = True
- 4: Think of making conditions more complex (by adding 'and' / 'or' operators and the corresponding part) or less complex (by removing some of 'and'/ 'or' parts)
Original: if (x > 0 and y < 5):
More complex condition: if (x > 0 and y < 5 and z == 10):
Less complex condition: if (x > 0):
- 5: if your patch consists only of adding a comment or modifying a line into a comment, you should discard the patch and try to suggest mutation of the buggy line(s) of code instead
Orginal: '// Modify the logic for finding wrap position and padding text here to address the bug'
Fix: pos = findWrapperPosition(text, width, start);
- 6: in some cases you will be required to insert new lines of code, you should consider adding more lines at given location. Usually, the code around the insertion location give you an idea about the lines to insert. Also the type of assertion failure.
Example:
if (!Double.isNaN(v)) {
min = Math.min(minimum, v);
+ max = Math.max(maximum, v); // insertion happened here
}
if (!Double.isNaN(u)) {
+ minimum = Math.min(min, u);// insertion happened here
maximum = Math.max(max, u);
}
- 7: pay attention to the comments and doc string above the buggy code, specifically if any important comments exist above or next to buggy lines.
Example:
// - verify the header checksum
This comment indicates that a verification of the header checksum, which can be done by calling a method dedicated for that.
- 8: the usual fix of some null pointer exceptions is to add a condition on the variable(s) that can be null.
Original: entity.create()
Fix: if (entity != null){
entity.create()
}
- 9: Do not modify a file by replacing lines with a comment. If you want to delete a line you can add its number to the list of lines to delete.
Always suggest code and not comments only.
Example of forbidden fix because it only writes a comment and not actual code:
{
modifications: [{"line_number": 105, "modified_line": "// need to improve this code"}]
}
- 10: Pay attention the type of variables. The code before and after the buggy lines might give hints of what the type of a variable should be.
Example:
int x = 20;
double y = x * x; // x should have been declared as double in the previous line
- 11: You also should be careful with types in java, especially numerical types.
For example int * int might produce a double which means it should be stored in double variable
Another example is int + int would also produce double.
- 12: If the buggy line is a method signature, consider changing the signature of the method. Also, consider checking similar methods or neighboring methods by searching the code base.
Examples:
change private to public or protected and vice-versa
change the type of an argument
add or remove an argument