Just to be clear, I prefer tabs over spaces myself, so I'm not arguing against tabs. What I'm arguing against is mixing tabs with spaces, with the expectation that every contributor to the codebase uses sufficiently smart editors to not break the formatting.
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.
> Just to be clear, I prefer tabs over spaces myself, so I'm not arguing against tabs. What I'm arguing against is mixing tabs with spaces, with the expectation that every contributor to the codebase uses sufficiently smart editors to not break the formatting.
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).
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.