Hacker News Reader

I used to have a coworker who was REALLY slow at reading code. For the longest time, I couldn't figure out why, but eventually he told me he was dyslexic.

I mentioned that I had hear of some fonts that were specifically made for people with dyslexia, so he downloaded one and tried it out. There was an almost immediate improvement in his output of code, and it was always interesting to go read over his shoulder and see things not-monospaced.

Personally, I only stick to monospaced fonts, but I wouldn't be totally opposed to trying something else. I even tried dotsies for a while (http://dotsies.org/) but could never get used to it and it slowed me down too much.

> For example, it cured the bad habit I had of lining too many things up in columns

I don't like this style either, but it's a style not a "bad habit."

> I don't like this style either, but it's a style not a "bad habit."

Point well taken. But this was just a personal observation. If other people use column alignment, it would certainly be presumptuous of me to call it a "bad habit"!

For me, though, it was just that. I had no real reason for it other than having always done that way, and it was really starting to get in the way. So I was glad to be done with it.

It's a decision with a lot of downsides. Each one not very significative, like polluting diffs, that add into a mild nuisance.

nah, it's a bad habit.

It means constant readjustment and unnecessarily bloated diffs every time you change a function or variable name.

or the lovely

  foo := a;
  bar := b;

then a day later

  foo    :=  a;
  bar    :=  b;
  foobar := cd;

which also points to the problem that it lends itself to premature constant readjustment because a day later you have to move every thing again because as it turns out you really needed foobarlist as well. and each time you end up with a diff reporting that foo and bar (and then foobar) have changed too.

It's making busy work for yourself and ruining the usefulness of code review tools.

ALSO alignment vs indentation is the whole reason we have to have the spaces vs tabs argument.

> alignment vs indentation is the whole reason we have to have the spaces vs tabs argument.

Indeed, that is one of the things I like about the indentation-only style. Unlike column alignment, you can use either spaces or tabs for indentation and the formatting still comes out fine.

One interesting talk I watched recently: https://channel9.msdn.com/Events/GoingNative/2013/The-Care-a...

In it, they make a really good argument that humans simply shouldn't be doing this type of formatting work. Let the computers do it, clang-format can get it right every time in a fraction of the time a human can.

Pick whatever style you want, let the computers deal with it. I quite like this, now I just write a big long single line, hit a button and have it fixed for me.

It's not a bad habit if it looks better and doesn't involve any time investment.

I've seen plenty of suboptimal code in review, commented about what I consider a better/more readable version to be, and gotten the response "this is what the clang formatter produces". Boo to automatic formatting. It produces the worst lowest-common-denomninator version of code.

>It means constant readjustment and unnecessarily bloated diffs every time you change a function or variable name.

Your variable example is the thing that peeves me most about golang, since gofmt insists on aligning consecutive variable names and types in that columnar fashion.

What's really puzzling about that gofmt decision is that Rob Pike and other Go core team members are known to code in proportional fonts!

https://news.ycombinator.com/item?id=10416364

The diff could be smarter and notice that you just inserted some white space.

Many GUI apps actually do that but unfortunately not your typical diff or git which insist in dealing with full lines only.

I'm sure many know, but for those who don't, `diff` (and `git diff`) accept -w and -b to ignore all white space and changes in the amount of white space, respectively. I find these very handy.

Somewhat related, if you're looking at a diff on GitHub and want to ignore whitespace, you can just tack on `?w=1` to the URL (https://github.com/blog/967-github-secrets).

Though you still end up committing whitespace changes that can then cause unexpected conflicts, later.

For github I crafted together this little bookmarklet to ignore whitespace on diffs (use it daily for our code reviews):

javascript:(function()%7Bopen(location.href+'?w=1');%7D)();void(0);

Here is a thought.

Maybe no formatting characters should be allowed to be saved embedded in source code, and instead presentation filters should handle everything related to formatting, documentation, etc.

It might work..

Git supports custom "clean/smudge" filters on push and pull exactly for this sort of things. Unfortunately neither github not gitlab consider them so your online diffs would look like a mess of you did that.

It looks interesting, but then one would have to define a normalization for the AST - either something like an XML printout of the AST, or a standard formatting for source code (perhaps whitespace-only minification?). It would also pose an issue when presenting code in "dumb" media (eg. a txt file).

Alas, if only tabs realized columns could occur in locations other than 8 or 4 space tab stops.

http://nickgravgaard.com/elastic-tabstops/

It's a non problem. Use a code formatter prior to code commit.

If needed allow your editor to have a task to reformat a code file on Open to apply formatting you desire vs the teams or project guidelines.

On the one hand, I agree that the time of typewriters and their fonts is (or should be) long gone. On the other hand, something keeps telling me that program code is not (and should not be) exactly a piece of literature, and there may be some advantages to being able to see code as a two-dimensional object rather than linear text.

Block selection and anything having to do with IO formatting are very good reasons why monospaced fonts are still useful.

That being said the idea that a programmer being resistant to changing their font style is indicative of general intellectual laziness is one of the most laughable things I've ever heard. I'd be more convinced if someone told me that refusing to change syntax highlighting themes implied you're a bad programmer.

> ...the idea that a programmer being resistant to changing their font style is indicative of general intellectual laziness is one of the most laughable things I've ever heard.

Let me just mention that this isn't what I said at all. I don't blame you for misunderstanding, I must not have explained my thoughts clearly.

I didn't say anything about intellectual "laziness", and I certainly didn't mean that someone who didn't want to change their coding font was intellectually lazy.

I was talking about intellectual curiosity, specifically with reference to my former CEO who questioned the sanity of anyone who would code in a proportional font.

Instead of wondering why someone would make such a non-mainstream decision and being even slightly interested in their reasons for it, he simply dismissed it out of hand as the bad habit of a weirdo.

That's the lack of intellectual curiosity I was talking about.

Ironically, I'd disagree and say that your CEO was being intellectually lazy by explaining your preference for proportional font by the absurd declaration that anyone who does it is simply sophomoric or inexplicable.

However, I would not take this kind of instance of intellectual laziness to be indicative of a more general complacency when it comes to ideas, tools, or self-development more generally.

By contrast I think intellectual curiosity is a great thing when present and lamentable when not, but I don't think it's a prerequisite to be a good professional in almost any field, including programming related ones.

Sublime-text-style multiple cursor text manipulation would break here. And your code would look different than everyone else's machine. How would you display a guideline to make sure you were under a characters-per-line style?

What advantages are there? I could never see it working for me. I want a program to format my code with resonable defaults and be done with it.

How would multiple cursors be affected by this? I use a proportional typeface and multiple cursors for all sorts of things, I can't really see how these concepts are even related.

As you say, use automatic formatting and you don't need to worry about line-length. (Otoh, having a mandatory max line length makes about as much sense as having a max identifier length or a max lines per file.)

Max column length (line length) does make sense in one case. It simplifies side-by-side comparison. We have a max 100 column rule which is perfect for our merge and review tooling :). It was raised from 80 few years back and probably raises again to 120 as everybody has all their monitors 1920x1080 now. The idea is everybody should see the entire line in one go without wrapping enabled.

A second reason is that it prevents nesting as a side effect. You are forced to make methods and don't go into nested if/for. Much easier to check for our (custom) linter than verifying for/if nested loop depth.

Oh, Turning on word wrap is evil...

You can't drag a cursor down vertically and know what will happen, something I do surprisingly often because it is very powerful.

Line length guide lines makes sense for me as a visual indicator of what will wrap when I hit the max lines per file. They are also nice ways to gauge when you are nesting too deep or making overly complicated expressions.

Max line length allows you to do nice things with window management and diff tool layout and not spend forever moving around to see the text. I am a convert after thinking it didn't matter. Now it being 80 characters is arbitrary but so would almost any other number be.

Typically, when you do column selection, the lines are identical to the left of the cursor or you're selecting the end of the lines, which both still work in a proportional font.

> your code would look different than everyone else's machine.

Not if you use an indentation-only style like my second example. One of the great things about that style is that it looks the same on anyone's machine, whatever kind of font you use.

If you read some of my code, you'll never know that I wrote it in a proportional font. It looks the same if you view it in a monospaced font.

> How would you display a guideline to make sure you were under a characters-per-line style?

Most programmer's editors have more than one way to do that. There is usually a column number in the status line, and some editors can be configured to change the background color on any part of a line that exceeds your required line length. That works with any font, and it's visually less obtrusive than a red vertical line partway across your editor window.

Also, an indentation-only style naturally leads to much shorter line lengths. If you compare my two examples above, the column-aligned version extends to column 77, while the indented version only goes to column 40! That's barely half the line length for the same code.

In practice, I think a lot less about line length since I switched to the indentation-only style, since my lines of code tend to be so much shorter as a result. And I tend to write the simplest functions I can without excessive nesting, so it's pretty rare that I come close to any worries about line length.

> What advantages are there?

For a proportional font, I simply find it easier to read and nicer looking. And as I mentioned, it also helped teach me to use indentation instead of column alignment.

I'm not saying you or anyone should necessarily convert the the Proportional Church, only that it is a worthwhile exercise to try it for a while.

What proportional font do you use? I'd like to give coding in a proportional font a try but would like something designed for programming instead of just experimenting with Verdana.

Yeah, Verdana is not great. I used to use Georgia, but when I started doing more on OSX I found that it didn't render well in all apps - the character strokes were too skinny. It looked great in Windows though.

For the last couple of years have been using Trebuchet MS. It's not designed specifically for programming, but it has many of the attributes of a good coding font, in particular all of the easily confused characters like 0Oo and 1Il are easily distinguished.

The one thing I don't like about Trebuchet is that it has a really terrible tilde (~). Sometime I will sit down with a font editor and swap in a better tilde.

I tend to use largish fonts on a high-DPI display, and Trebuchet really looks nice with that setup, both on Windows and macOS.

Someone else recommended Input, which is designed for programming and comes in both proportional and monospaced variants. When I tried Input it didn't look as nice as Trebuchet MS to my eyes though.

That will give you a few to try out!

Agree on indentation-only-style. Alignment is just a painful mess to maintain every time I encounter it.

Use a decent code editor?

Jetbrains editors have it built in (change some settings and then ctrl+alt+l does it for you.) Sublime, VSCode, Atom, etc.. all have prettify plugins.

Aligned code is easy to read code. Aligning code is a pain in the ass. A good code editor once again saves the day (and man hours!)

It's odd to claim that editors that don't support this aren't decent.

I use the proportional font "Input", which is designed for programming. I really enjoy it. The only annoyance is matching indentation in certain scenarios.

I would probably want to hit you with a baseball bat if I had to spend any time reading your code with my monospaced font. At least for the type of code that I work in that lends itself to code alignment.

> I would probably want to hit you with a baseball bat if I had to spend any time reading your code with my monospaced font.

Well, that's a good way to get a head start on the "hell or purgatory" thing, isn't it! :-)

I'm not saying every kind of code is suited for a proportional font. If you use ASCII art, or if you are writing out two-dimensional matrices or the like, a monospaced font will serve you better.

The kind of casual and unnecessary column alignment in my first example is what I was talking about. The second (indented) example is perfectly readable in either a monospaced or proportional font. So if you run across it you hopefully won't need your baseball bat.

Ok. So do you use tabs or spaces? Do any reasonable editors support tabs of this sort?

I've been interested to try programming using proportional fonts for a while, but really like ligatures and don't want to do away with them (I'm using Hasklig at the moment.)

Does anyone have a recommendation? I'm having trouble finding anything at the moment.

What about code that naturally represents tables, like this?

    rotationMatrix = [[ cos(x), -sin(x), 0],
                      [ sin(x),  cos(x), 0],
                      [      0,       0, 1]]

Yup, that's a great example of where a monospaced font helps. I don't claim that proportional fonts are ideal for every kind of code, only that it's an educational experience to try them out, even if just for a while.

Your example is interesting because it combines two different kinds of alignment. One of them I find unhelpful - pushing everything to the right to match the length of the variable name. The other is the useful alignment within the matrix. So personally I would make this minor change:

  rotationMatrix = [
      [ cos(x), -sin(x), 0 ],
      [ sin(x),  cos(x), 0 ],
      [      0,       0, 1 ]
  ]

Now you have the nice matrix layout without having to realign the code if you ever rename rotationMatrix.

This is such a nice display of art and it is what I mostly judge a coders ability by.

Ditto for me. Going proportional made me consider using saner formatting policies rather than fancy ones. I've also narrowed my code column width by writing more vertically and less horizontally to make scanning easier on my eyes while also allowing for more side by side buffers.

At least you still get people complaining about you. It means they care for your soul.

Try using a tab-size of 3 spaces.

There is another example of when mono spacing is useful; multiple calls to the same function with diffrent arguments.

But that's basically hardcoded tabular data, and should really be solved by an editor with proper tab-stops. Not by abusing the monospaceivity and spaces for alignment.

But that's basically hardcoded tabular data, and should really be solved by an editor with proper tab-stops. Not by abusing the monospaceivity and spaces for alignment.

That’s the crux of the issue for me.

I can think of many ways I’d like to present code in my idealised programming language(s) that would use significantly more advanced layout and typography than today’s typical environments.

However, I wouldn’t actually want to use any of them unless my programming tools all supported them properly. That means the editor, but also the source control and diff tools, the code review and bug tracking systems, and so on.

In the absence of any standard conventions for how to represent that extra metadata in an underlying format as robust and flexible as plain text, it’s hard to see this ever happening, though I imagine it would be fun to try.

I never used a proportional font while coding in my life and I always used the second way of indenting. If this is the only advantage of the proportional fonts I guess that the mis-alignment disadvantage far, far outweighs it.

To each their own. Personally I dislike nested function calls in general and would use intermediate variables with descriptive names.

  var calculatedOne = andthisCalculatedOne(anArgumentThatMeansSomething,
                                       anotherWordyName);

  myFunctionThatDoesStuff(someArgument, calculatedOne);

Edit: That "anotherWordyName" is supposed to be column justified, HN really needs <code> tags instead of this indentation nonsense.

The extra vertical space is easily worth the increase in readability IMO.

I've never touched proportional formatted code beyond a day or two when I was forced to by my environment, and all I encountered was more annoyances in getting my code to align properly. I'm glad you found some benefit, but I'd argue those benefits could be achieved any number of other ways.

> Personally I dislike nested function calls in general and would use intermediate variables with descriptive names.

Oh, I agree completely that step-by-step is often more readable than deep nesting.

OTOH, your example is a good illustration of the problems with column indentation. If it hadn't been HN's goofy code formatting that messed you up, it would have been some code refactoring that changed the length of one of those variable or function names.

Great answer, thanks for that insight! (I was just joshing!)

> I was just joshing!

I know, and I apologize for hinting that you of all people may have lacked intellectual curiosity! That comment was really directed toward the former CEO of mine... :-)

Actually I'm glad you put in that little joshing swipe against us proportionalites, as it gave me an excuse to have some fun exploring the topic.

I feel like proportional fonts make sense for me when coding in lisps. Not sure why.

I really wonder why, because alignment is one of the core things in lisp code style. Take this trivial snippet:

    (let ((foo 1)
          (bar 2))
      (print foo)
      (print bar))

The (print ...) statements should just be indented two spaces, so you don't need a monospaced font for that, but the bindings should be aligned... "(let (" in a proportional font generally won't have the same width as 6 spaces.

How do you deal with this?

Why did you format the code snippets in your comment in a monospace font?

Also, I'm curious. I want to see how the code looks like. I want to know what are the downsides of monospace and the benefits of proportional. The one you cited isn't too much of a deal, since it is just a habit you can create using monospace still.

> Why did you format the code snippets in your comment in a monospace font?

Because I don't know of a way to get HN to format text in a proportional font without losing the line breaks. Believe me, I've tried. :-)

> Also, I'm curious. I want to see how the code looks like.

I am glad you are curious about it!

> I want to know what are the downsides of monospace and the benefits of proportional. The one you cited isn't too much of a deal, since it is just a habit you can create using monospace still.

Indeed, and now that you mention it, I'm not entirely sure which happened first. I may have switched to the second style with indentation instead of column alignment before I started using a proportional font, just because I was tired of the excessive line lengths and always having to fiddle with the spaces.

Regarding the downsides and benefits, will it sound like a cop-out if I say it's just something you have to try for yourself?

Part of my preference for proportional fonts isn't even tied to any rational reasons. I spend much of my day looking at code, and I just find proportional fonts easier to read, more beautiful and pleasant to look at. But beauty, of course, is in the eye of the beholder.

Might be easier to just go with screenshots

Well at least for yourself you could adjust code blocks with Stylish [1] and some custom css.

[1]: https://userstyles.org/

HN is a web page, and HTML swallows multiple-spaces into a single space.

Let me test                 something.

Edit: crap, doesn't work

I'm pretty sure that if HN allowed you to do what you just tried, it would be a XSS vulnerability. :P

Nah, you can do it on Reddit because they use Markdown instead of HN's homegrown comment formatter. In case you ever need to post a proportional font code sample over there, the trick is to use   for all the leading spaces, and also add two regular spaces at the end of each line before the last one.

Unicode has some wonky characters - I use zero-width space, probably the most ridiculous of them to bypass filters at times. For intentionally wide spaces you have a few options:

Test unicode non-breaking space.

Test                                                                    unicode  narrow no break space.

Test unicode figure space.

EDIT: So there you have it, if you want a non-breaking space on hackernews, use unicode's figure space or narrow non-breaking space. Apparently they already filter out the normal non-breaking space.

Please don't do this. It's unreadably broken on mobile Chrome (turns into a gigantically wide space).