6 ms·

In theory, tabs for indention and spaces for alignment would be the best way to handle whitespace. Unfortunately in practice, two factors are in the way: 1) M

by mg 5y ago

In theory, tabs for indention and spaces for alignment would be the best way to handle whitespace. Unfortunately in practice, two factors are in the way: 1) Most developers are confused by this type of whitespace usage. Simply because it is the less popular practice. So when you have a codebase that uses tabs for indention, you get more broken commits from developers who stumble in keeping the system intact. 2) Out of the box, VIM has no easy way to colorize tabs. So when you look at your code, tabs and spaces look the same. You cannot say from just if the whitespace is ok or messed up. You can show all non printing chars with "show list" but that is not very nice on the eyes. Or you can configure "show list" to only highlight tabs but then you lose the ability to show all non printing chars.

cryptica 5y ago
Mixed is the worst. It doesn't make sense logically. Isn't indentation just another kind of 'alignment'? After all, we use indentation to align text on the page... The differences between between all the supposedly distinct kinds of alignment are too subtle and difficult to describe in words to be used as a rule. It's better to stick to simple rules that are easy to follow and enforce - Leave no room for ambiguous interpretations. Also, I hate it when developers try to break up code in weird ways to align all the equal signs together for example. I would prefer that they never do this. Maybe if our eyeballs were stuck inside our heads in such a way we had to move our necks to read each letter, then it would be a good idea... Then it would be worth the complexity it adds. In the real world, however, moving one's eyeballs a few millimetres sideways isn't very difficult. There is no need to litter your pristine code with extra spaces just to save people from having to shift their eyeballs a bit when reading your code. You save the reader like 10 eyeball shifts out of 1000...
- benrbray 5y ago
  > I hate it when developers try to break up code in weird ways to align all the equal signs together for example. I do this in cases where I have many similar lines, for instance calling the same function many times with different arguments, and I want to make the differences between them more obvious. I find it to be much more maintainable and easier to read / identify bugs.
  - cryptica 5y ago
    I find that the skill of reading code correctly without relying on visual aids can be trained and is a valuable skill. Visual aids won't help you to train this skill. I'm confident that my ability to identify potential bugs quickly is correlated to my ability to visually spot tiny differences in the code. In both cases, you need to develop an extreme attention to detail.
    - benrbray 5y ago
      It's one of those tradeoffs we make to save time. I get practice tracing program logic by reading poorly organized code written by others, but for my own purposes, I have a standard, consistent way of organizing/formatting things that saves a lot of mental overhead. People make the same argument about static vs dynamic types -- "if you were a better programmer you wouldn't NEED to rely on type information!". Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier. What is language syntax but a visual aid that we all use to avoid writing assembly?
      - cryptica 5y ago
        >> Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier. That is an extremely interesting argument. Personally, I find that overhead to be useful; the difficulty of keeping track of all the different types encourages me to design simpler interfaces between components. When I'm struggling with remembering what type some variable is, I know I've made the method interface too complicated (e.g. maybe the component should just keep the instance state internally and only accept an ID instead of a whole instance as argument). I guess that's why I prefer dynamic typing; it forces me to keep my interfaces simple and to think more carefully about state and logic co-location (to get high cohesion, loose coupling). I like the Alan Kay quote about OOP "The Big Idea is Messaging". To understand this quote properly, we need to understand what "Messaging" means; it's about communication. Effective communication is about conveying intent; components should tell each other what needs to be done, not how to do it. Having complex interfaces which accept complex instances as arguments is akin to micro-managing the component. Typed languages are only particularly useful if you have complex interfaces. If you have simple method interfaces, you don't need a typed language because remembering what the parameters are for each method is trivial.
0-_-0 5y ago
Actually, in theory the best solution would be an IDE that handles whitespace sufficiently flexibly that the actual encoding of the whitesapce doesn't matter anymore. It has to reliably distinguish indentation whitespace from alignment whitespace. Then everyone could separately adjust the indentation to be N spaces in a codebase without needing to decide centrally on tabs/2spaces/4spaces etc.
samatman 5y ago
Don't agree, here's why: -- this comment is on the margin, the code is indented youCantDo("this kind of", "function parameter", "mixing tabs and spaces")
- dangerface 5y ago
  Don't agree, here's why: -- this comment is on the margin, the code is indented youCantDo("this kind of", "function parameter", "mixing tabs and spaces")
  - samatman 5y ago
    No idea what you tried to do here, but this doesn't line up properly. Fix it and I'll merge: except I wouldn't see it because CI won't pass code with tabs in it.
- tasuki 5y ago
  I don't get why people do that. It's ugly, and it breaks when the `youCantDo` name changes. youCanDo( "this kind of", "function parameter", "with just tabs" )
  - samatman 5y ago
    Ugly is subjective. Vertical space is at a premium, and 'wasting' five lines when three will do strikes me as uglier than the opposite. Adjusting spaces when things get refactored doesn't strike me as especially tedious, but YMMV. I don't go so far as to support "lisp style" closing braces for brace-block languages, though. It's just too weird.
    - twinkletwinkle_ 5y ago
      Agree that ugly is subjective. But adjusting spaces when things get refactored is bad, not because it's tedious but because it pollutes history. Changing whitespace on surrounding lines to my change makes eg `git blame` less informative. It's the same reason I believe in trailing commas.
mjsir911 5y ago
> Out of the box, VIM has no easy way to colorize tabs. From my vimrc: set list listchars=tab:>- It's not colorizing, but will list out a tab character as `>---` Not exactly sure what you mean by "show list" but I believe you can append to `listchars` whatever nonprintable character formatting you want
tom_mellior 5y ago
> Out of the box, VIM has no easy way to colorize tabs. This is slightly simplified from my .vimrc: highlight ExtraWhitespace ctermbg=darkred match ExtraWhitespace /\t/ It will highlight any tab in dark red. (My actual .vimrc uses /\t\| \+$/ to also highlight extra spaces at the ends of lines.) I hate (and am confused by) pretty much everything about vimscript, but this particular snippet is actually surprisingly clear.
- mg 5y ago
  Very nice! I hoped somebody might know an easy way like this when I mentioned it! HN for the win!

by mg 5y ago

cryptica 5y ago

Mixed is the worst. It doesn't make sense logically. Isn't indentation just another kind of 'alignment'? After all, we use indentation to align text on the page... The differences between between all the supposedly distinct kinds of alignment are too subtle and difficult to describe in words to be used as a rule. It's better to stick to simple rules that are easy to follow and enforce - Leave no room for ambiguous interpretations. Also, I hate it when developers try to break up code in weird ways to align all the equal signs together for example. I would prefer that they never do this. Maybe if our eyeballs were stuck inside our heads in such a way we had to move our necks to read each letter, then it would be a good idea... Then it would be worth the complexity it adds. In the real world, however, moving one's eyeballs a few millimetres sideways isn't very difficult. There is no need to litter your pristine code with extra spaces just to save people from having to shift their eyeballs a bit when reading your code. You save the reader like 10 eyeball shifts out of 1000...

benrbray 5y ago
> I hate it when developers try to break up code in weird ways to align all the equal signs together for example. I do this in cases where I have many similar lines, for instance calling the same function many times with different arguments, and I want to make the differences between them more obvious. I find it to be much more maintainable and easier to read / identify bugs.
- cryptica 5y ago
  I find that the skill of reading code correctly without relying on visual aids can be trained and is a valuable skill. Visual aids won't help you to train this skill. I'm confident that my ability to identify potential bugs quickly is correlated to my ability to visually spot tiny differences in the code. In both cases, you need to develop an extreme attention to detail.
  - benrbray 5y ago
    It's one of those tradeoffs we make to save time. I get practice tracing program logic by reading poorly organized code written by others, but for my own purposes, I have a standard, consistent way of organizing/formatting things that saves a lot of mental overhead. People make the same argument about static vs dynamic types -- "if you were a better programmer you wouldn't NEED to rely on type information!". Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier. What is language syntax but a visual aid that we all use to avoid writing assembly?
    - cryptica 5y ago
      >> Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier. That is an extremely interesting argument. Personally, I find that overhead to be useful; the difficulty of keeping track of all the different types encourages me to design simpler interfaces between components. When I'm struggling with remembering what type some variable is, I know I've made the method interface too complicated (e.g. maybe the component should just keep the instance state internally and only accept an ID instead of a whole instance as argument). I guess that's why I prefer dynamic typing; it forces me to keep my interfaces simple and to think more carefully about state and logic co-location (to get high cohesion, loose coupling). I like the Alan Kay quote about OOP "The Big Idea is Messaging". To understand this quote properly, we need to understand what "Messaging" means; it's about communication. Effective communication is about conveying intent; components should tell each other what needs to be done, not how to do it. Having complex interfaces which accept complex instances as arguments is akin to micro-managing the component. Typed languages are only particularly useful if you have complex interfaces. If you have simple method interfaces, you don't need a typed language because remembering what the parameters are for each method is trivial.

0-_-0 5y ago

Actually, in theory the best solution would be an IDE that handles whitespace sufficiently flexibly that the actual encoding of the whitesapce doesn't matter anymore. It has to reliably distinguish indentation whitespace from alignment whitespace. Then everyone could separately adjust the indentation to be N spaces in a codebase without needing to decide centrally on tabs/2spaces/4spaces etc.

samatman 5y ago

Don't agree, here's why: -- this comment is on the margin, the code is indented youCantDo("this kind of", "function parameter", "mixing tabs and spaces")

dangerface 5y ago
Don't agree, here's why: -- this comment is on the margin, the code is indented youCantDo("this kind of", "function parameter", "mixing tabs and spaces")
- samatman 5y ago
  No idea what you tried to do here, but this doesn't line up properly. Fix it and I'll merge: except I wouldn't see it because CI won't pass code with tabs in it.
tasuki 5y ago
I don't get why people do that. It's ugly, and it breaks when the `youCantDo` name changes. youCanDo( "this kind of", "function parameter", "with just tabs" )
- samatman 5y ago
  Ugly is subjective. Vertical space is at a premium, and 'wasting' five lines when three will do strikes me as uglier than the opposite. Adjusting spaces when things get refactored doesn't strike me as especially tedious, but YMMV. I don't go so far as to support "lisp style" closing braces for brace-block languages, though. It's just too weird.
  - twinkletwinkle_ 5y ago
    Agree that ugly is subjective. But adjusting spaces when things get refactored is bad, not because it's tedious but because it pollutes history. Changing whitespace on surrounding lines to my change makes eg `git blame` less informative. It's the same reason I believe in trailing commas.

mjsir911 5y ago

> Out of the box, VIM has no easy way to colorize tabs. From my vimrc: set list listchars=tab:>- It's not colorizing, but will list out a tab character as `>---` Not exactly sure what you mean by "show list" but I believe you can append to `listchars` whatever nonprintable character formatting you want

tom_mellior 5y ago

> Out of the box, VIM has no easy way to colorize tabs. This is slightly simplified from my .vimrc: highlight ExtraWhitespace ctermbg=darkred match ExtraWhitespace /\t/ It will highlight any tab in dark red. (My actual .vimrc uses /\t\| \+$/ to also highlight extra spaces at the ends of lines.) I hate (and am confused by) pretty much everything about vimscript, but this particular snippet is actually surprisingly clear.

mg 5y ago
Very nice! I hoped somebody might know an easy way like this when I mentioned it! HN for the win!