Hacker News Reader

Comment by slazaro | Hacker News Reader

They always seemed to me like solutions to a nonexistent problem. They make the code less readable, but ligatures exist and they seemed like a cool tech thing to implement, and they might look cool in screenshots. But in practice, in my opinion, they're worse than just having the normal characters. But I guess it's a matter of opinion, no harm in other people using them.

View on HN

We have studies since ages ago that consistency in code style is one of the most important requirements for code quality.

This goes down to the details like that you should either use spaces over tabs OR prescribe editor config such that the code looks similar on each machine.

Of course this doesn't automatically mean that code ligatures are harmful, but I would be quite wary of using them. At the very least it introduces some friction, not sure if the arguably lower mental load of using real mathematical symbols instead of the ASCII symbols makes up for it.

I'v been coding now for like 15 years and I'm not old enought to understand the debate between spaces vs tabs :)

I guess my IDE choices never surface the issue for me... visually they just look the same. I cannot say which codebase uses spaces which uses tabs. I never even think about it. I just smash tab character and don't care that there have been spaces. Or enter or { and IDE does the indentation. I just choose not to press space 2-4-8-16 times in a row.

Now I hope I won't get bulldozed over by HN crowd...

Well, the tabs vs spaces had been mostly resolved and spaces won. But obviously it was never about what physical keys to press, nobody on the spaces side would spam the space bar to indent stuff (except maybe in the unfortunate situations of having to use an editor with no choice of setting the tabulator to emit spaces, or a textfield in a non-editor UI where the tabulator cycles the focus instead).

I'm still in the "tabs for indentation, spaces for alignment" camp. If you adhere to it, it makes your code look nice on any tab size.

For a solo project, sure, you do you. But for any meaningful collaboration, deliberately mixing tabs and spaces - and relying on a manual, semantic convention to use them the "right" way - will inevitably lead to a maintenance / consistency nightmare.

To add to your comment, it's kinda common to find projects that have spaces and tabs improperly mixed in the indentation. Making a quick search among the projects I have cloned, I'm seeing indentations like

  tab * 4 + space * 7 + tab * 2
  tab * 2 + space * 1 + tab * 1
  tab * 1 + space * 4 + tab * 2
  space * 16 + tab * 3 + space * 4
  tab * 4 + space * 2 + tab * 2 + space * 2
  tab * 3 + space * 3 + tab * 1 + space * 6

The code ends up looking janked unless you use the particular tab-width of the space/tab-indenter[1], which isn't always 8. It completely defeats the whole purpose of the tab indentation.

[1] On those first 2, given the odd (not even) number of spaces, it's likely that use of spaces was for alignment, but then a tab-indenter added tabs to that...

Typing formulas in Excel

It's too bad spaces won, tabs is just correct I think, since one can configure the tabstop to use any indent size they would like. I'm quite tired of reading 2-space indent. Seems everything has moved this way now except python. I'm even seeing C with it, which is especially jarring. I think the languages that use braces for indentation particularly need 4. Python needs it least, and I can read Ruby because its blocks are delimited by words and it's bad style to write long methods

Agreed, four is optimal and has luckily been the standard in projects I’ve worked in. Encourages you to avoid deep nesting as well.

Spaces vs. tabs causes a lot of issues for Python programmers who share their code with other programmers. The other place where spaces vs. tabs is an issue is with makefiles, probably one of the most annoying features of POSIX.

I also remember old school bourne shell wanting tabs in some places (case statements?), but bash doesn't have that issue.

These days, I try avoid them outside of makefiles.

Considering the way `/bin/sh` had a bunch of different implementations before POSIX standardization minimized that in the mid-1990s, I wouldn’t be surprised if one of those distinguished spaces from tabs.

That said, the original UNIX V7 implementation of /bin/sh didn’t distinguish different kinds of whitespace:

https://www.in-ulm.de/~mascheck/bourne/v7/

You're right. I don't see any evidence of what I claimed. It doesn't look like it was ever whitespace sensitive. This would have been in the 90's, probably Linux. I feel like the compatibility issue involved case statements, maybe it was the parenthesis thing.

> I also remember old school bourne shell wanting tabs in some places (case statements?), but bash doesn't have that issue.

From bash(1):

> If the redirection operator is <<-, then the shell strips all leading tab characters from input lines and the line containing delimiter.

That's also how it works with zsh.

This is why my here-doc delimiters are always un-indented despite surrounding indentation.

Wish bash had something like ruby's `<<~`, which accepts either space or tab indentation of the delimiter and additionally removes the indentation of the block (likely based on the least indented line).

One of the main arguments for tabs over spaces was always that people wanted to configure how much space a level of indentation makes up on screen.

With tabs pretty much every editor except something like notepad.exe could do it since ancient times, with spaces the editor needs to do a bit more processing, so you were a bit more restricted in editor choice, if you really were bothered so much by the indents chosen in the project.

So it is actually quite similar to the ligature discussion. It would be good if the code looked the same for everybody but now instead of saying "But 8-space indents waste so much space on the screen :(" some people now go "But I don't like seeing things like != or -> instead of modern Unicode symbols :("

I'm in the same boat, I always just press tab and let my IDE or text editor fill in with N spaces.

Granted, I'm also someone who heavily encourages the use of Black as the Python formatter in projects I'm on, specifically because it has no configurable options - can't have a holy war about formats if nothing can be changed.

> "understand the debate between spaces vs tabs"

The reason spaces won is that it's not (spaces) vs (tabs), it's (spaces) vs (tabs AND spaces).

Oh, for Pete’s sake. The bodies from this holy war are barely cool…

I feel like tabs could have won if there was a stretchable tab character instead of it looking like a bunch of spaces. Being invisible meant that it was treated as a bunch of spaces. I could see it being visible as a very light gray block with just a tiny right margin. This way it would be easy to see how many indents there are.

They don't detract from readability for me, so it's just pretty symbols = me more happy

When I program or I write maths I see and think of -> >>= <*> etc as a single, semantically meaningful symbols. Not only do I use a ligature for them, but I make my keyboard to use one single key. For the same reason I have a key emitting “forall” which Emacs then displays as ∀.

Reply on news.ycombinator.com