> Patterns are easier to identify with a non-monotonous font, as
> research into word-shapes shows.
Link?
I doubt most such research is considering code, so I'd like to see your sources. I totally agree that English text is easier to read when correctly typeset, but reading code and reading English are very different activities, at least for me. English is mainly read through occasionally overlapping sweeps, with a linear tendency. I read code by jumping around within constraints established by my understanding of structure.
From experience, I know where to look for arguments, for loop bindings, for destructuring; I know how to read a with-* macro, a declaration, a comment block. If those conventions are violated, my code reading slows and errors can creep in.
> What you're saying only applies if your "patterns" consist of forcing
> everything into the same length.
No, what I'm saying applies whenever structure can be made visible by aligning tokens to a grid. If that grid is 1em wide, the alignment is easy.
Consider a totally trivial non-indentation example: returning the English-language representation of a mathematical operator using case.
Because the operators are all the same width, I can immediately see the syntax error: a break in the column of double-quotes. If those strings were not all aligned to the same grid, the error would not be obvious, and I'd have to rely on syntax highlighting. Syntax highlighting helps in this case, but not always.
The effect is even more profound when considering common test code: it's usual to walk a table of data and answers, applying the same test to each, and thanks to monospacing you can ensure that multiple values are grouped in both axes.
You can achieve this for whole-token alignment with careful tab settings, but I'm sure as hell not going to edit code in Microsoft Word. You cannot achieve it within tokens without using monospaced fonts.
Have you ever worked at a low enough level, or with a programming language that uses short tokens, such that you're interacting with a collection of functions like
/_2op
*_2op
+_2op
-_2op
=_2op
>_2op
<_2op
? Having those be the same width helps my brain "unpack" the meaningful content from the "annotation" (the fact that they're all two-operand functions).
> I suspect that you might not know what you're talking about, but only because
> of your choice of language ("shape of a form", "code is structure and
> patterns" - what exactly is that supposed to mean, if anything?)
What part of "make it easier for me" rubbed you the wrong way? I was conveying personal opinion.
Most of my code is written in various Lisps, in which the structure of code is directly manipulated. I'm not sure how to explain the importance of pattern and structure if you don't get it… perhaps some examples of patterns might help you:
public static void main(String[] args)
public void foo()
public void bar()
The structural layout, indentation, and use of established patterns in code fulfills the same role that, say, 12-bar blues does: everyone knows how to work within the framework, so nobody wastes their time trying to figure out how to communicate before they can make something happen. My opinion is that variable-width fonts inhibits my ability to spot the patterns and structure in the code, so I'm forced to read it more carefully to extract the same information.
Link?
I doubt most such research is considering code, so I'd like to see your sources. I totally agree that English text is easier to read when correctly typeset, but reading code and reading English are very different activities, at least for me. English is mainly read through occasionally overlapping sweeps, with a linear tendency. I read code by jumping around within constraints established by my understanding of structure.
From experience, I know where to look for arguments, for loop bindings, for destructuring; I know how to read a with-* macro, a declaration, a comment block. If those conventions are violated, my code reading slows and errors can creep in.
> What you're saying only applies if your "patterns" consist of forcing > everything into the same length.
No, what I'm saying applies whenever structure can be made visible by aligning tokens to a grid. If that grid is 1em wide, the alignment is easy.
Consider a totally trivial non-indentation example: returning the English-language representation of a mathematical operator using case.
Because the operators are all the same width, I can immediately see the syntax error: a break in the column of double-quotes. If those strings were not all aligned to the same grid, the error would not be obvious, and I'd have to rely on syntax highlighting. Syntax highlighting helps in this case, but not always.The effect is even more profound when considering common test code: it's usual to walk a table of data and answers, applying the same test to each, and thanks to monospacing you can ensure that multiple values are grouped in both axes.
You can achieve this for whole-token alignment with careful tab settings, but I'm sure as hell not going to edit code in Microsoft Word. You cannot achieve it within tokens without using monospaced fonts.
Have you ever worked at a low enough level, or with a programming language that uses short tokens, such that you're interacting with a collection of functions like
? Having those be the same width helps my brain "unpack" the meaningful content from the "annotation" (the fact that they're all two-operand functions).> I suspect that you might not know what you're talking about, but only because > of your choice of language ("shape of a form", "code is structure and > patterns" - what exactly is that supposed to mean, if anything?)
What part of "make it easier for me" rubbed you the wrong way? I was conveying personal opinion.
Most of my code is written in various Lisps, in which the structure of code is directly manipulated. I'm not sure how to explain the importance of pattern and structure if you don't get it… perhaps some examples of patterns might help you:
The structural layout, indentation, and use of established patterns in code fulfills the same role that, say, 12-bar blues does: everyone knows how to work within the framework, so nobody wastes their time trying to figure out how to communicate before they can make something happen. My opinion is that variable-width fonts inhibits my ability to spot the patterns and structure in the code, so I'm forced to read it more carefully to extract the same information.