3 ms·
Why not always do this? Once you stop using column alignment/align with opening delimiter, and use hanging indent, these issues go away: int someLongFuncti
by guitarbill 8y ago
Why not always do this? Once you stop using column alignment/align with opening delimiter, and use hanging indent, these issues go away:
int someLongFunctionNameThatWillBeRefactored(int foo,
int bar);
someLongFunctionNameThatWillBeRefactored(longVariableName1,
longVariableName2);
and do
int someLongFunctionNameThatWillBeRefactored(
int foo,
int bar);
someLongFunctionNameThatWillBeRefactored(
longVariableName1,
longVariableName2);
or even
int someLongFunctionNameThatWillBeRefactored(
int foo, int bar);
Now tabs work fine. Spaces work fine. Elastic TabStops? Ironic that he mentions "Keep it simple, stupid!" and then overengineers this thing and every editor along the way.
Anyway, this will probably not go down well since everybody has been trained to use the former style, and now people "prefer" it, out of what seems to me to be habit.
- simias 8y agoI don't think scare quotes are warranted, I do prefer the former style, I find that it makes it easier to match the arguments to the function at a glance. Of course it's purely subjective. I do note that even your proposition doesn't really solve the problem of using Elastic TabStops, because if you imagine a comment spanning all three lines: someLongFunctionCall(⇥ /* This function call */ ⇥ longVariableName1,⇥ /* is really cool * ⇥ longVariableName2);⇥ /* and stuff */ You have an additional tab at the beginning of the two last lines which means (as far as I understand it) that the first comment line won't necessarily line up with the two others. Of course that showcases a potential issue with Elastic TabStops, not your particular coding style.
- guitarbill 8y agoBlock comments interleaved with code are rare in most codebases I've worked on, because it's almost always easier to put them on their own lines, above the statement: /* This function call is really cool and stuff */ someLongFunctionNameThatWillBeRefactored( longVariableName1, longVariableName2); So I sort of dismissed that use-case as a toy example. But yes, if you did that elastic tabstops would be useful... except the contents of the block comment doesn't get reflowed when the tabstop width changes. Which I'm sure we could do, but then we're getting into interesting territory w.r.t edge cases/usability for sure.
- piinbinary 8y agoOne (extremely minor) advantage of putting the closing paren on the next line (in languages that allow trailing commas, like Python) is that when adding or deleting an argument, the diff only touches that one line (you never have to move the paren)
- Izkata 8y agoBecause at least for me, the closing paren pulls my mind back to the correct indentation after the end of the block. Without it, I typically do a quick side-to-side and top-to-bottom scan to ensure the next block is at the level I'm expecting. Python is especially bad for me here, despite having used it everyday for years, because "if" and "while" and etc don't even have those closing markers.