Hi Allen,
Some common commenting techniques used with manually managed code formatting (i.e. manual linebreaks) are below.
I'm just putting them out there in case you're not already thinking about them (but you probably are!).
Basically, we probably wouldn't want these things to become more difficult once auto-wrapping is introduced...
This is a common construct:
Then if you want to turn off SOME_FLAG_2, pretty easy:
Another one is:
Then one wants to quickly remove the conditional:
I guess one simple way of handling those cases is that if somebody inserts a single-line comment somewhere while in auto-wrap mode, you'll also have to insert manual/appropriate linebreaks into the "real" non-autowrapped sourcecode.
The other point here is that some people may prefer bitflags be aggressively wrapped each onto their own line (like shown above) for easy commenting-out, and they may prefer that braces are aggressively wrapped to their own line (like above for the if statement) for similar reasons of easier commenting-out. I'm pointing all of this out because it could be easy to write off things like brace-wrapping rules and bitflag wrapping rules as mere cosmetic preference, but they can actually serve an important functional purpose in making certain editing tasks (commenting/uncommenting in this case) easier/faster.
Then again, down the line you may want to have a Comment out this "thing" under the cursor feature that you can bind to a key, so say:
And my cursor is on top of "SomeThingTwo". I can hit my "comment out this thing" hotkey and i'll end up with:
This gets a bit tricky, though. What if you have:
And your cursor is on top of another_thing. Well, that could mean:
Or:
So perhaps the "comment out this thing" key could cycle between all the possible states... in this case:
And:
And back to:
The "comment out this thing" feature perhaps better addresses the root issue here, rather than using code formatting rules as a workaround of sorts as shown at the beginning of this post. But I think that probably has to be experimented with a bit more to know for sure.
Some common commenting techniques used with manually managed code formatting (i.e. manual linebreaks) are below.
I'm just putting them out there in case you're not already thinking about them (but you probably are!).
Basically, we probably wouldn't want these things to become more difficult once auto-wrapping is introduced...
This is a common construct:
1 2 3 4 5 | someFlags = 0 | SOME_FLAG_1 | SOME_FLAG_2 | SOME_FLAG_3 ; |
Then if you want to turn off SOME_FLAG_2, pretty easy:
1 2 3 4 5 | someFlags = 0 | SOME_FLAG_1 //| SOME_FLAG_2 | SOME_FLAG_3 ; |
Another one is:
1 2 3 4 | if(something)
{
stuff;
}
|
Then one wants to quickly remove the conditional:
1 2 3 4 | //if(something)
{
stuff;
}
|
I guess one simple way of handling those cases is that if somebody inserts a single-line comment somewhere while in auto-wrap mode, you'll also have to insert manual/appropriate linebreaks into the "real" non-autowrapped sourcecode.
The other point here is that some people may prefer bitflags be aggressively wrapped each onto their own line (like shown above) for easy commenting-out, and they may prefer that braces are aggressively wrapped to their own line (like above for the if statement) for similar reasons of easier commenting-out. I'm pointing all of this out because it could be easy to write off things like brace-wrapping rules and bitflag wrapping rules as mere cosmetic preference, but they can actually serve an important functional purpose in making certain editing tasks (commenting/uncommenting in this case) easier/faster.
Then again, down the line you may want to have a Comment out this "thing" under the cursor feature that you can bind to a key, so say:
1 2 3 4 | enum { SomeThingOne, SomeThingTwo, SomeThingThree }; |
And my cursor is on top of "SomeThingTwo". I can hit my "comment out this thing" hotkey and i'll end up with:
1 2 3 4 | enum { SomeThingOne, /*SomeThingTwo*/, SomeThingThree }; |
This gets a bit tricky, though. What if you have:
1 2 3 4 | if(something && another_thing && one_more_thing)
{
stuff;
}
|
And your cursor is on top of another_thing. Well, that could mean:
1 2 3 4 | if(something && /*another_thing*/ && one_more_thing)
{
stuff;
}
|
Or:
1 2 3 4 | //if(something && another_thing && one_more_thing)
{
stuff;
}
|
So perhaps the "comment out this thing" key could cycle between all the possible states... in this case:
1 | if(something && /*another_thing*/ && one_more_thing) |
And:
1 | //if(something && another_thing && one_more_thing) |
And back to:
1 | if(something && another_thing && one_more_thing) |
The "comment out this thing" feature perhaps better addresses the root issue here, rather than using code formatting rules as a workaround of sorts as shown at the beginning of this post. But I think that probably has to be experimented with a bit more to know for sure.
Edited by AndrewJDR
on
On the topic of a Comment out hotkey/feature, I realized there are a bunch of different ways to granularize the problem. One example of what I mean is below.
For this example, imagine I start out on the following line:
And my cursor is over "one_more_thing".
The Comment out this statement/line feature cycles between statement/line commenting options per-keypress:
Or a more advanced case, Comment out this statement/line could cycle through these options (cursor is on top of "doSomething()"):
(Though, if I'm thinking in a vim-way, I would probably just handle full line-level commenting by making a visual selection of the current line, then hitting the Comment out this statement/line hotkey and reserve the non-visual mode hotkey for statement commenting only)
The Comment out identifiers feature cycles through different "identifier" commenting options per-keypress:
Btw, this ignores the fact that I often use #if 0 for block-level comments, but that's a bit of a different story.
For this example, imagine I start out on the following line:
1 | if(something && (another_thing && one_more_thing)) |
And my cursor is over "one_more_thing".
The Comment out this statement/line feature cycles between statement/line commenting options per-keypress:
1 | //if(something && (another_thing && one_more_thing)) |
1 | if(something && (another_thing && one_more_thing)) |
Or a more advanced case, Comment out this statement/line could cycle through these options (cursor is on top of "doSomething()"):
1 | doSomething(); doAnotherThing(); |
1 | /*doSomething();*/ doAnotherThing(); |
1 | //doSomething(); doAnotherThing(); |
(Though, if I'm thinking in a vim-way, I would probably just handle full line-level commenting by making a visual selection of the current line, then hitting the Comment out this statement/line hotkey and reserve the non-visual mode hotkey for statement commenting only)
The Comment out identifiers feature cycles through different "identifier" commenting options per-keypress:
1 | if(something && (another_thing && /*one_more_thing*/)) |
1 | if(something /* && (another_thing && one_more_thing)*/) |
1 | if(something && (another_thing && one_more_thing)) |
Btw, this ignores the fact that I often use #if 0 for block-level comments, but that's a bit of a different story.
Edited by AndrewJDR
on