Single discussion thread covering multiple lines of code
Users want to comment on a block of code, not just an individual line of code.
AdminBrandon DuRette
(Admin, Code Collaborator)
shared this idea
There are underlying technical reasons why this is tricky, so our standard answer is to just comment at the top of the block of code you are commenting on and preface with an indicator of the block that you are discussing. For example:
“This method could be…”
or
“This loop would be better if…”
However, if there is overwhelming desire for this feature, it is something that we would consider adding.
13 comments
-
ruza
commented
* Ian T. Johns: I acknowledge that with simple revision changes automatic detection may be good enough. What I'm worried about are border cases. Like accidental commit of a version that has commented code removed ... followed by a fixed code ... just to make it more "soap opera" story the new version also fixes formatting defects that were on each line.
I want a tool that can help with moving to better code and can start from "a horror story" legacy code. The tool should help the transition, not impose more assumptions on the code/development.
*Tiffany Cooper: yes, it should allow multiple lines and multiple instances.
Example: defect #1 for lines 2,4,6 (1a); same defect (1b) on 5,9,13 and (1c) 7,21,23. -
Ian T. Johns
commented
This feature is absolutely necessary for any non-trivial code & I second several of the points mentioned previously:
* Timothy Strelchun: Multiple lines can be contiguous OR non-contiguous
* aleppke: Dropdown to include new line(s) into previously entered comment or defect group
* ruza: Although if implemented properly with revision changes, adjustment of comment/defect group lines might NOT be necessary -- the ability to continue to add new lines into the group AND mark as 'Accepted' on an individual line basis is importantFor example, a comment/defect is added at line 200. That exact same comment/defect occurs at line 275 & is added to that same comment/defect group with line 200. Lines 325, 400, & 550 are also then added to that group. Later, the coder corrects lines 200, 275, 325, & 550 -- but forgot to correct line 400. Therefore, the reviewer must be able to 'Accept' changes only for lines 200, 275, 325, & 550; but leave line 400 still flagged.
-
Will this also enable applying a defect to multiple lines of code?
-
Timothy Strelchun
commented
I just started using CC and quickly discovered this multi-line select limitation. Both contiguous multi-line select and non-contiguous multi-line select are important information to associate with a comment and/or defect note. It should be possible to at least manually enter the line numbers and/or ranges (comma separated) into the "line" field, but it currently accepts no input.
Usually a comment/defect may apply to a range of lines (and occur multiple times in the same file/files). When reporting the defect that information should be identified and recorded. By not tracking this basic data, this useful information will most likely be lost and require authors to figure it out on their own (hopefully!), or the reviewers will need to manually type in the defect comment field the line # range or other areas it occurs (or have to at least paste the same comment in multiple spots).
BTW: My organization at Intel is using 5.0.5027 so if this is addressed in a more recent that would be good to be aware of.
-
ruza
commented
Let me repeat: manual adjustment of line pointers for different version is a must for this feature to be fully usable.
-
seth.tager
commented
Crucible allows you to select multiple disjointed lines of code. I miss that feature in CC.
-
Srinath Balaraman
commented
For us, the standard multi-selection options are highly desirable. As mentioned by aleppke the standard click and drag, ctrl+click, shift+click is what we would like to see. We often times have similar comments for more than one line of code (which may not be a in the same block). For that ctrl+click is highly desirable.
-
aleppke
commented
As for the defects, I would like to have an option when marking as a defect to either "Create new defect" or "Mark as instance of existing defect" with a dropdown of all existing defects. The defect itself would keep track of all instances. You would then mark each instance as resolved and the defect's status as open or fixed would be based on whether there were any open instances.
-
aleppke
commented
I would like to see the standard multi-selection options (click and drag, ctrl+click, shirt+click). The comment/defect could then be shown on the side, lined up with the highest visible line its associated with. This would mean that the comment moves as the user scrolls so the comment is always visible provided one of the affected lines is visible.
-
Garen
commented
I shouldn't have to click and click and click and click, and paste and paste and paste and paste over and over and over and over again, merely to apply the same defect, to multiple lines/blocks. Defect count, I don't care about it in this case. During verification, I then want to go back and ensure that one type of defect was fixed in every single instance.
-
ruza
commented
Garen: there should be a distinguishing between those two uses.
Multiple instances of the defect should count into number of defects. Lines involved in a single defect should not. Example: buffer overflow - you should mark declaration and wrong use. There can be multiple buffers and usage places that exhibit same problem. -
Garen
commented
Perhaps an independent issue, but I also want to file a single defect against multiple blocks/lines of code. I don't want to clog up the defect log with a ton of defects, all of which have the same description. Even if I could just list the starting line numbers where the defect occurs for all N occurences, it'd be nice.
-
ruza
commented
I have heard the counter argument about finding corresponding lines in later revisions of the file. I think that is a weak argument.
Manual override of the of lines affected for given version would take care of that.
