4 ms·
There's different kind of alignment, the one you get from breaking too long line. // some code // ... var some_call_result = some_object.a_method(with, q
by dozzie 10y ago
There's different kind of alignment, the one you get from breaking too long
line.
// some code
// ...
var some_call_result = some_object.a_method(with, quite_long, list_of,
parameters)
In the second line you get indent (up to `var' keyword level), and then
alignment. The former would be fine with tabs, but the latter must be spaces.
Unfortunately there's no editor that deals with tabs in this situation
correctly, which means spaces is the only way to go.
- spinningarrow 10y agoWhile I see what you're getting at, I actually prefer indentation in this case as well. Something like: var some_call_result = some_object.a_method( with, quite_long, list_of, parameters ) Alignment adds inconsistent negative space to the code which I find breaks the flow and makes it hard to read because lines start at arbitrary columns. If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need.
- dozzie 10y agoWhat you presented indeed has no alignment spaces, so all-tabs approach works. The thing is, there are codebases that use "my" line breaking, and with no editor that handles that case correctly, tabs are just no-go. > If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need. I gladly accept this drawback, for the sake of situations when a linebreak is necessary, but the argument list is just too short to be split it into separate lines like in your example. (The necessity is a matter of taste, obviously.) I admit, these situations are rare, but they happen from time to time, so I simply don't use tabs.