Which ones exactly? Not really a problem I've encountered often except when someone tries to mix both spaces and tabs, and in general editors are built with the existence of this very common character in mind. People tend to hit the tab key to indent anyway, and one tab char meaning one level of indent is perfectly intuitive and allows users to individually configure how large they want their indents to be.
for example ('-' is tab, '.' is space):
--function_with_lots_of_arguments(arg1, arg2, arg3,
--................................arg4, arg5, arg6);
of course, another style would be to just indent the continuation twice, without aligning it. (i personally prefer to align continuations.)
For example, this is the best way to define functions with argument lists long enough not to fit on a single line:
fn doThing(
argument1,
argument2,
argument3,
) {
<code>
}
More food for thought:
The style in your example is more consistent with the way nearly every programmer formats code that has more than one statement. For example:
if( shouldDoThings ) {
doOneThing();
doAnotherThing();
doLastThing();
}
if (shouldDoThings) {doOneThing();
doAnotherThing();
doLastThing();}
Somewhat related, the Rust coding style guidelines used to follow a heavily column-aligned style, but changed to indentation-only a year or two ago. I posted an example from the Servo source code with the old and new formats here:
>Not really a problem I've encountered often except when someone tries to mix both spaces and tabs
Mixing spaces and tab for indentation and alignment is how it should be done if you want things to remain aligned when you change the tab width.
How it should be done is to never write code that needs alignment if you're using tabs for indentation.
Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments("), add that many spaces after your indentation tabs on the next line, continue arguments. The fact that editors/auto-formatters don't do that speaks far more to their lack of desire for that code style then it does to the difficulty of doing it.
The simple fact remains that using tabs provides many accessibility benefits that spaces are just unable to provide, like being able to drop tab size when you boost font size (legibility for poor vision) so your code doesn't indent off the side of the screen, or far better support for indentation for proportional fonts (another thing that people swear by for increasing legibility).
With that out of the way...
>Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments(")
That breaks for `foo(bar(a,\nb,\nc))`
And if you fix it to be "len till the last unmatched (" then it breaks for `foo(bar(a,\nb),\nc)` because the two lines have to indent to different levels.
Just saying it's not as trivial as it seems.
>The fact that editors/auto-formatters don't do that speaks far more to their lack of desire for that code style then it does to the difficulty of doing it.
And is a reason to not use such a style in the first place, as I said.
That's still just an argument for "everyone use a specific formatter with these settings". Go's formatting is simple, built into the main implementation, and has no knobs, as a result, everyone uses it, and all code is formatted with tabs and spaces. It can work, esp. if a language adopts it early (like Zig could have).