The setting we want to consider
So we have this config setting.
Layout/DotPosition:
Enabled: true
EnforcedStyle: trailing
I'd like to make some arguments against it, provide counterarguments to the reason it's the default, and then wrap up with a summary.
Arguments against it
It causes code churn in git
@samphippen mentioned in the podcast that they choose syntactic preferences with the goal of reducing git churn. Lets analyze this setting with that metric in mind:
We append a line and look at the diff. What we see is that a leading dot causes a 1-line diff and a trailing dot causes a 3-line diff because we had to modify the end of the previous line. Not a huge deal, but it does increase cognitive overhead. You just have to be more on top of your game because the diffs have a less favourable signal to noise ratio.
It's cumbersome to edit
Lets swap the last 2 lines instead. We find we can't just move lines around, because each line is not self-contained, it's partially on the line before it. Since the last line isn't before anything, it deviates from the pattern and we have to futz around with its trailing dot. The last line perpetually needs our attention.
It puts important info way off at EOL
How one line relates to the next is pretty important, but there's lots of reasons a line might continue,
in this example, maybe it's a method call, or maybe it's line1 &&\n line2 or line1 -\n line2 and so on. Important info is hard to access making this difficult to read.
Addressing the incumbent reasoning
Why is it set this way?
The readme gives the reasoning (here):
Trailing dots on multi-line method chains - chosen because it makes copying lines into a REPL easier
This is a pragmatic solution, and it does accomplish the stated goal, but if buggy REPLs are this problematic, then shouldn't we fix them instead?
Alternative: fix the REPLs
There's more to it than my exploration addressed, but that hopefully illustrates that it's within our ability to do. We don't need every codebase to adopt disadvantaged syntax to deal with REPL bugs. We can instead fix the REPL bugs. I've reported my findings here.
Alternative: jump into an editor
In pry, you can also use edit if the thing you're building is getting unwieldy. Then you can work with it in your text editor (similar to bash's C-x C-e).
Alternative: start the REPL from the code of interest
But honestly, the desire to paste code into REPLs isn't very compelling. The REPL is line based, so it's not a great editor (plus, Readline is just not very good at it). Instead, of trying to bring the editor into the REPL, use the editor to put the REPL in the context of interest. This is super powerful because you can jump into any context you can invoke (I often set up a test to reproduce getting into that environment, and then put a pry at the confusing spot so I can poke around).
Alternative: Seeing is Believing
Oh, and I'll pitch my gem, too: REPLs are useful for very specific types of problems. Despite the didactic interestingness of the Little LISPer, I wouldn't do these kinds of experiments in a REPL, I'd use SiB.
Yeah... it can handle leading dots like it's nobody's business!
Conclusion
To summarize my points:
- It generates distracting diff churn
- It is cumbersome to edit
- It hides adjacent lines' relationship way off at the end of the line
- The stated reason is that it's to compensate for REPL bugs, but we can fix the REPLs
- There are numerous alternatives to pasting code into the REPL, many of which are likely better.
For these reasons, I propose that we change the setting from trailing to leading.
Cheers.
The setting we want to consider
So we have this config setting.
I'd like to make some arguments against it, provide counterarguments to the reason it's the default, and then wrap up with a summary.
Arguments against it
It causes code churn in git
@samphippen mentioned in the podcast that they choose syntactic preferences with the goal of reducing git churn. Lets analyze this setting with that metric in mind:
We append a line and look at the diff. What we see is that a leading dot causes a 1-line diff and a trailing dot causes a 3-line diff because we had to modify the end of the previous line. Not a huge deal, but it does increase cognitive overhead. You just have to be more on top of your game because the diffs have a less favourable signal to noise ratio.
It's cumbersome to edit
Lets swap the last 2 lines instead. We find we can't just move lines around, because each line is not self-contained, it's partially on the line before it. Since the last line isn't before anything, it deviates from the pattern and we have to futz around with its trailing dot. The last line perpetually needs our attention.
It puts important info way off at EOL
How one line relates to the next is pretty important, but there's lots of reasons a line might continue,
in this example, maybe it's a method call, or maybe it's
line1 &&\n line2orline1 -\n line2and so on. Important info is hard to access making this difficult to read.Addressing the incumbent reasoning
Why is it set this way?
The readme gives the reasoning (here):
This is a pragmatic solution, and it does accomplish the stated goal, but if buggy REPLs are this problematic, then shouldn't we fix them instead?
Alternative: fix the REPLs
There's more to it than my exploration addressed, but that hopefully illustrates that it's within our ability to do. We don't need every codebase to adopt disadvantaged syntax to deal with REPL bugs. We can instead fix the REPL bugs. I've reported my findings here.
Alternative: jump into an editor
In pry, you can also use
editif the thing you're building is getting unwieldy. Then you can work with it in your text editor (similar to bash'sC-x C-e).Alternative: start the REPL from the code of interest
But honestly, the desire to paste code into REPLs isn't very compelling. The REPL is line based, so it's not a great editor (plus, Readline is just not very good at it). Instead, of trying to bring the editor into the REPL, use the editor to put the REPL in the context of interest. This is super powerful because you can jump into any context you can invoke (I often set up a test to reproduce getting into that environment, and then put a pry at the confusing spot so I can poke around).
Alternative: Seeing is Believing
Oh, and I'll pitch my gem, too: REPLs are useful for very specific types of problems. Despite the didactic interestingness of the Little LISPer, I wouldn't do these kinds of experiments in a REPL, I'd use SiB.
Yeah... it can handle leading dots like it's nobody's business!
Conclusion
To summarize my points:
For these reasons, I propose that we change the setting from
trailingtoleading.Cheers.