DEV Community

loading...

Discussion on: Who Killed The Tab?

Collapse
kallmanation profile image
Nathan Kallman

Thanks for picking on me! :P

I want to agree with you; and I don't want to "control" how you view the code. I'll clarify that I really am focused on the "worst case" of mixed tabs and spaces in my opinion on "know[ing] that the way I see my code is the same way you or anyone else will see it". Which some styles of coding would essentially require mixing tabs and spaces; see this multilined example of a validation in ruby on rails (borrowed from real examples I've seen in production code):

validates :something,
          :presence => true,
          :inclusion => { :in => ALLOWABLE_VALUES }
Enter fullscreen mode Exit fullscreen mode

(We can have a separate discussion on if this is a good style or not, but) How would I write that with tabs? should I have 2 tabs and 2 spaces? 4 tabs and 2 spaces? 10 spaces? Now I have mixed indention that will be subtly broken for everyone who isn't me.

We now have these amazingly sophisticated IDEs that can do so much to format code however a particular dev wants to see it

Just as a counterpoint; not all code is written and read in IDEs. They also appear in command lines; in git clients; in GitHub (or GitLab or BitBucket etc.); in CodePen's; in StackOverflow; in DEV posts and comments :) ...


To be honest, it shouldn't be that difficult for these "sophisticated" IDEs to solve this problem by treating groups of 2 or 4 (or whatever) spaces as something to be rendered with a different width (same width as tab would be). This solves the problem of always being forced to see unaccessible indentation with the problem of getting all the various places code appears to render tabs "correctly".


So, semantically I want tabs; but for historical reasons I see why spaces were chosen.

Thread Thread
defman profile image
Sergey Kislyakov πŸ‡·πŸ‡Ί πŸ‡ΊπŸ‡Έ • Edited

If everyone used tabs, your code example would probably look something like this:

validates
[tab]:something,
[tab]:presense => true,
[tab]:inclusion => { :in => ALLOWABLE_VALUES }
Enter fullscreen mode Exit fullscreen mode

It seems logical to me (a statement with the arguments being a nested thing (thus the indentation)). This would not introduce the problem you described (mixing tabs and spaces), though it might not be liked by some people because there's one line that could be gone.