3 ms·

What about alignment? The space character is much narrower in most fonts, making code have a terrible rythm.

macrael 4y ago
I've found I don't miss the ability to carefully align stuff outside of the initial indentation. I actually use a slightly modified Avenir that prints a wider space if it's the first thing in a line, making the indentation stand out more. The rhythm of a general line of code I think is improved because it reads like regular text.
Narishma 4y ago
That's what tabs are for.
Stratoscope 4y ago
The key to using a proportional font is to give up alignment completely, and only use indentation. Once you do that, it no longer matters whether you use a proportional or monospaced font. The Black formatter for Python is an interesting example. It strictly uses indentation only and never uses alignment. As a result, Black-formatted code is equally readable in any font, monospaced or proportional. I use my own customized proportional font called Trebuchet++, and Black code looks great in it. If you didn't know I was using a proportional font, you might not even notice that it wasn't monospaced. As you may guess, Trebuchet++ started out as Trebuchet MS, which I found I really enjoy reading on a high-DPI display. Then I started tweaking things in FontForge: Trebuchet MS has a terrible tilde character that looks too much like a minus sign. So I put in a better defined glyph for that. One problem in a proportional font if you use names_with_underscores as required by too many coding standards: the underscore character is much too wide compared to a period. This gives a visual grouping that is the opposite of what you want, for example in foo_bar.moo_car(), "bar" and "moo" are closer together than "foo" and "bar" or "moo" and "car". This is misleading visually. So I used FontForge to add a bit of space on each side of the dot, and add negative space on each side of the underscore. In the example above, this pulls the "foo" and "bar" in "foo_bar" closer to each other, and similary for "moo_car". At the same time, it adds some separation between "bar" and "moo". The difference is subtle, but in terms of visual grouping it avoids having the code read like this: foo bar moo car So it reads more like this: foo bar moo car I have a couple of other tweaks I haven't gotten to yet. In particular I want to add a bit of margin on the inside of parentheses and square brackets. In my own code where I get to choose the style, I've always uses a space inside those. I find this offers a real improvement in readability. But if I can't do that, at least I can fix it with some font tweaks!
eviks 4y ago
That's where the nonexistent support for variable-width tabulation (or flexible tabstops) comes in! Unfortunately even the newer programming editors don't match these type of Word-level basics

I've found I don't miss the ability to carefully align stuff outside of the initial indentation. I actually use a slightly modified Avenir that prints a wider space if it's the first thing in a line, making the indentation stand out more. The rhythm of a general line of code I think is improved because it reads like regular text.

Narishma 4y ago

That's what tabs are for.

Stratoscope 4y ago

The key to using a proportional font is to give up alignment completely, and only use indentation. Once you do that, it no longer matters whether you use a proportional or monospaced font. The Black formatter for Python is an interesting example. It strictly uses indentation only and never uses alignment. As a result, Black-formatted code is equally readable in any font, monospaced or proportional. I use my own customized proportional font called Trebuchet++, and Black code looks great in it. If you didn't know I was using a proportional font, you might not even notice that it wasn't monospaced. As you may guess, Trebuchet++ started out as Trebuchet MS, which I found I really enjoy reading on a high-DPI display. Then I started tweaking things in FontForge: Trebuchet MS has a terrible tilde character that looks too much like a minus sign. So I put in a better defined glyph for that. One problem in a proportional font if you use names_with_underscores as required by too many coding standards: the underscore character is much too wide compared to a period. This gives a visual grouping that is the opposite of what you want, for example in foo_bar.moo_car(), "bar" and "moo" are closer together than "foo" and "bar" or "moo" and "car". This is misleading visually. So I used FontForge to add a bit of space on each side of the dot, and add negative space on each side of the underscore. In the example above, this pulls the "foo" and "bar" in "foo_bar" closer to each other, and similary for "moo_car". At the same time, it adds some separation between "bar" and "moo". The difference is subtle, but in terms of visual grouping it avoids having the code read like this: foo bar moo car So it reads more like this: foo bar moo car I have a couple of other tweaks I haven't gotten to yet. In particular I want to add a bit of margin on the inside of parentheses and square brackets. In my own code where I get to choose the style, I've always uses a space inside those. I find this offers a real improvement in readability. But if I can't do that, at least I can fix it with some font tweaks!

eviks 4y ago

That's where the nonexistent support for variable-width tabulation (or flexible tabstops) comes in! Unfortunately even the newer programming editors don't match these type of Word-level basics