Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> One of the drawbacks of white-space sensitivity is the accidental mixing of distinct white-spaces (e.g., tabs and spaces)

I discovered something really surprising regarding whitespace awareness of others, TL;DR that many juniors fundamentally misunderstand "tabs vs spaces", thinking that "tab" means the tab key rather than the tab character.

As a follow up to migrating a bunch of repos and discovering every possible combination of "wrong" indentation... I asked what people's preferences were, my assumption that the cause of this mess was different people working on the same repo with differing preferences. Only to find that this was not the case at all, they were mostly from the same individual. And those individuals had a severe misunderstanding of what "tab" vs "spaces" meant. Essentially many people are either not aware of the tab character or not aware that the tab key does not necessarily insert a tab character due to auto indent features. So those people interpret "using tabs" as "using the tab keyboard key", getting confused at why anyone would be using the space bar.

I then realised that the source of this misunderstanding comes from auto-indent defaults in modern text editors. The automatic, per-line indentation type detection, combined with automatic space insertion and automatic navigation over spaces when using cursor keys makes tabs and spaces indistinguishable unless you either turn these features off or render invisibles. This becomes a problem when chunks of code are pasted from somewhere else with different indentation styles, since they act as seeds of an indentation type that start to propagate and compete with adjacent line indentations. The worst combinations are competing space-based indentation levels, e.g 2 vs 4 spaces, when these are adjacent the automatic indentation behaviour cannot figure out which is correct since 2*2 = 1*4, 4*4 = 2*8 etc etc. This can make it impossible to set e.g a closing bracket onto the correct indent level. Rather than realise the auto indent is insufficient, It seems that novices will just submit to the editor - thinking it is somehow broken.

So rather than enforce a tab/space/indentation level style guide: I said I didn't care what they preferred, so long as they turned on invisibles and made sure their code is self-consistent by manually selecting an indentation style/level. i.e I've ended up mandating specific text editor settings rather than a style guide.



A tangent:

https://www.theverge.com/22684730/students-file-folder-direc...

Let's face it: The new generation has no clue how computers work.

Not that this would be a big surprise. My grandma also didn't know how computers work. That's not some knowledge you get born with. You need to learn it.

But the new generation never learned about "real" computers. They're just consumers of user grade entertainment and communication devices, until they get in contact with "real" computers the first time in university or on the job. (So exactly like for the generation of the now grand parents).

> The automatic, per-line indentation type detection, combined with automatic space insertion and automatic navigation over spaces when using cursor keys […]

That's absolutely crazy shit just to simulate the behavior of tabs with spaces!

If we would just use tabs (like they were invented, namely for indentation) there wouldn't be any issue.

The editor vendors should stop all this craziness described above and we would be good. Nobody is printing their source code any more on a line printer! Which was the only reason ever to actually use spaces for indentation. It's incredible how bullshit form the 70' still causes issues today even the actual reason for that bullshit can be found at best with luck in a museum.


Double space, quadruple space and tabs all being legal choices was a bigger mistake in Python than the concept of indentations itself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: