Almost monospaced: the perfect fonts for writing • Hacker News Board

Re: Almost monospaced: the perfect fonts for writing

#101

Post by hnbad » Mon, Nov 07, 2022, 8:18 AM UTC

opk wrote: post #32

bsimpson wrote: post #21

Isn't the whole point of monospaced fonts columnar alignment (e.g. the table in the article)? Seems like "almost" defeats the point. Then again, I don't see values lined up much these days: { "someKey": "someValue", "someOtherKey:" "someOtherValue, and if you only care about leading whitespace (that is, the whitespace before a character appears on the line), maybe it doesn't matter how your font is spaced. I suspect…

I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Only rarely is the vertical alignment useful because mostly code isn't read vertically. Used in moderation, the reverse Christmas tree style used in the Linux kernel can be as good for readability (…

Arguably another problem with lining up code like in the example is that it emphasizes the relationship between the keys and between the values rather than between each key-value pair. This may be useful when writing out matrices but in the example of an object/dict with key-value pairs it seems a distraction more than an affordance.

Re: Almost monospaced: the perfect fonts for writing

#102

Post by anilakar » Mon, Nov 07, 2022, 8:22 AM UTC

pmontra wrote: post #97

sverhagen wrote: post #94

Earlier quoted context omitted.

In circumstances, and depending on configuration, the code formatter tool may still aim for alignment, such as assignment operators on subsequent lines. Whether you like that or not, for me the question still stands: how does that jive with "almost monospaced".

I've been using proportional fonts in programming for about ten years. I stopped doing things like abc = 1 d = 2 which add very little readability value IMHO. Things like func(arg1, arg2, arg3) usually don't align well because func( has a different width than the five spaces in the lines below. However 1) my text editor (emacs) aligns those lines for me (probably any programmer's editor does) so at least I don't have…

Formatting your code in an unintuitive way because of the font is a code smell to me.

Re: Almost monospaced: the perfect fonts for writing

#103

Post by pmontra » Mon, Nov 07, 2022, 8:25 AM UTC

anilakar wrote: post #102

pmontra wrote: post #97

Earlier quoted context omitted.

I've been using proportional fonts in programming for about ten years. I stopped doing things like abc = 1 d = 2 which add very little readability value IMHO. Things like func(arg1, arg2, arg3) usually don't align well because func( has a different width than the five spaces in the lines below. However 1) my text editor (emacs) aligns those lines for me (probably any programmer's editor does) so at least I don't have…

Formatting your code in an unintuitive way because of the font is a code smell to me.

Honest question: which one is unintuitive?

Re: Almost monospaced: the perfect fonts for writing

#104

Post by amadvance » Mon, Nov 07, 2022, 8:31 AM UTC

pmontra wrote: post #97

sverhagen wrote: post #94

Earlier quoted context omitted.

In circumstances, and depending on configuration, the code formatter tool may still aim for alignment, such as assignment operators on subsequent lines. Whether you like that or not, for me the question still stands: how does that jive with "almost monospaced".

I've been using proportional fonts in programming for about ten years. I stopped doing things like abc = 1 d = 2 which add very little readability value IMHO. Things like func(arg1, arg2, arg3) usually don't align well because func( has a different width than the five spaces in the lines below. However 1) my text editor (emacs) aligns those lines for me (probably any programmer's editor does) so at least I don't have…

I do something similar also with if() and others:

  if (condition...
      && condition...
      && condition...
  ) {

Re: Almost monospaced: the perfect fonts for writing

#105

Post by mikojan » Mon, Nov 07, 2022, 8:42 AM UTC

thaumasiotes wrote: post #88

opk wrote: post #32

Earlier quoted context omitted.

I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Only rarely is the vertical alignment useful because mostly code isn't read vertically. Used in moderation, the reverse Christmas tree style used in the Linux kernel can be as good for readability (…

> I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Seems wrongheaded to me; that's the same reason Elm wanted you to write arrays like this: [item1 ,item2 ,item3 ,item4 ] instead of a sane way. It means adding or removing an element only changes o…

This looks bad. Haskell is much better:

  [ item1
  , item2
  , item3
  , item4
  ]

Re: Almost monospaced: the perfect fonts for writing

#106

Post by galaxyLogic » Mon, Nov 07, 2022, 8:47 AM UTC

rocqua wrote: post #84

opk wrote: post #32

Earlier quoted context omitted.

I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Only rarely is the vertical alignment useful because mostly code isn't read vertically. Used in moderation, the reverse Christmas tree style used in the Linux kernel can be as good for readability (…

The value of alignment (at least for me) is not in making the text of the code more readable. Instead, the value is communicating the structure of the code. Seeing the same shape repeatedly tells me a lot about what is happening. It also helps highlight changes between two lines that are very similar.

> the value is communicating the structure of the code.

I agree and I think that is the same thing as code-readability. Code-readability means you can easily understand the code.

I personally try to abide by what I call "hedge" formatting convention, the punctuation forms a vertical hedge which then shows the structure of your code clearly:

[ a

, b

, c

]

Moving my eyes down to look for the closing bracket is easier (to me) than moving my eyes from left to right to spot it somewhere on the right side of the page.

Note how above ALL the punctuation is in the same (first) column, Having read that it then becomes easier to read what is on the rest of the columns.

In general it helps when things that are the same, or have the same purpose, on each line are in the same horizontal position. It is is then easier to see what is different about each line, since it is easy to see what is the same.

Re: Almost monospaced: the perfect fonts for writing

#107

Post by devmunchies » Mon, Nov 07, 2022, 8:47 AM UTC

I use a lowercase “L” and “LST” (in lowercase) for variables representing lists in function args.

For me the lower L and the number 1 have to be different. Most mono fonts make them almost identical.

Typing “lst” looks like 1st (First). They either need to curve the bottom of the lowercase “L” or remove the bottom bar of the one.

Re: Almost monospaced: the perfect fonts for writing

#108

Post by Cthulhu_ » Mon, Nov 07, 2022, 9:00 AM UTC

bsimpson wrote: post #21

Isn't the whole point of monospaced fonts columnar alignment (e.g. the table in the article)? Seems like "almost" defeats the point. Then again, I don't see values lined up much these days: { "someKey": "someValue", "someOtherKey:" "someOtherValue, and if you only care about leading whitespace (that is, the whitespace before a character appears on the line), maybe it doesn't matter how your font is spaced. I suspect…

You know, now you mention it, I thought about this and realized I mainly want items to START on the same column, after that I don't care; only exception is tables in markdown, but those are few and far between.

I might give these fonts a try, although I've been used to Menlo for a long time.

Re: Almost monospaced: the perfect fonts for writing

#109

Post by ako » Mon, Nov 07, 2022, 9:02 AM UTC

sverhagen wrote: post #94

ako wrote: post #85

Earlier quoted context omitted.

I stopped manually formatting code long ago, just accept what the code formatter tool decides is good enough. Saves a lot of time.

In circumstances, and depending on configuration, the code formatter tool may still aim for alignment, such as assignment operators on subsequent lines. Whether you like that or not, for me the question still stands: how does that jive with "almost monospaced".

It should ignore "almost monospace". Most projects have multiple developers, you should assume different developers have different IDE/font preferences, so your formatting shouldn't try to cater for it.

Re: Almost monospaced: the perfect fonts for writing

#110

Post by vore » Mon, Nov 07, 2022, 9:03 AM UTC

thaumasiotes wrote: post #88

opk wrote: post #32

Earlier quoted context omitted.

I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Only rarely is the vertical alignment useful because mostly code isn't read vertically. Used in moderation, the reverse Christmas tree style used in the Linux kernel can be as good for readability (…

> I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Seems wrongheaded to me; that's the same reason Elm wanted you to write arrays like this: [item1 ,item2 ,item3 ,item4 ] instead of a sane way. It means adding or removing an element only changes o…

Leading comma is better at resolving textual 3-way merges, e.g.:

   [ a         [ a       [ a
   , b         , b    /  , b
   , c   -->   , c   /   , c
   , d         , d  /    , dd
   ]           , e       ]
               ]

Your usual 3 way merge algorithm will correctly deduce:

   [ a
   , b
   , c
   , dd
   , e
   ]

Contrast this with trailing comma:

   [ a,         [ a,       [ a,
     b,           b,    /    b,
     c,   -->     c,   /     c,
     d            d,  /      dd
   ]              e        ]
                ]

You now have a merge conflict between "d," and "dd".

However, if you were to require a trailing comma after the final element you wouldn't have this problem.