4 ms·
If I cannot fit a function call on one line, I usually prefer this indent: int main() { printf( "%s, %s, %d", somevariable,
by kuon 8y ago
If I cannot fit a function call on one line, I usually prefer this indent:
int main() {
printf(
"%s, %s, %d",
somevariable,
somefunction(),
42
);
}
- guitarbill 8y agoWhy 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.
- wybiral 8y agoThis has been my preference too. Beats trying to keep weird alignment with the method names and makes param lists more consistent with other open/close bracket situations.
- ben509 8y agoThat's my preference, as well. My rationale is that you should pick one or the other: indentation can entirely eschew dangling closing brackets as in LISP, or closing brackets always track nesting. Otherwise it looks asymmetric and ugly.