Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Source Code Typography

naildrivin5.com

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Source Code Typography

#51

Post by LowKarmaAccount »

The elephant in the room is that many languages have adopted or have been influenced by the C language's miserable practices of ending a statement with a semicolon, and using the equals sign as an assignment operator. Both of these practices break with conventional usages to no discernible advantage.

Another impediment to readability is the insistence upon representing code by using hideous, low contrast colors on a dark background, especially when the code snippets are mixed with the conventional representation of black text on a white background.

My favorite quote about C's synatx was written by Erik Naggum: "If you care to know my opinion, I think semicolon-and-braces-oriented syntaxes suck and that it is a very, very bad idea to use them at all. It is far easier to write a parser for a syntax with the Lisp nature in any language than it is to write a parser for thet stupid semiconcoction. Whoever decided to use the semicolon to _end_ something should just be taken out and have his colon semified. (At least COBOL and SQL managed to use a period.)"

Re: Source Code Typography

#52

Post by limmeau »

akkartik wrote: post #15
davidw wrote: post #10

On a bit of a related subject one thing I've always idly wondered about Lisp and typography is how hard the curvy parens, together with not much indentation make it hard to line stuff up vertically. A random elisp example: (while (> count 0) (re-search-backward regexp bound) (when (and (> (point) (point-min)) (save-excursion (backward-char) (looking-at "/[/*]"))) (forward-char)) (setq parse (parse-partial-sexp saved-…

Yeah, I agree. Lisp is best with small functional blocks. "It used to be thought that you could judge someone's character by looking at the shape of his head. Whether or not this is true of people, it is generally true of Lisp programs. Functional programs have a different shape from imperative ones. The structure in a functional program comes entirely from the composition of arguments within expressions, and since a…

Racket (and maybe other Schemes) lets you interchange [] and () freely. Helps a bit. e.g.

         (cond
           [(positive? -5) (error "doesn't get here")]
           [(zero? -5) (error "doesn't get here, either")]
           [(positive? 5) 'here])

Re: Source Code Typography

#53

Post by limmeau »

dsego wrote: post #40
georgef wrote: post #26

When I first started programming in C, I did the same thing with pointers (i.e., char* str; instead of char *str; ). Unfortunately, this creates the wrong impression that char* str1, str2; creates two pointer-to-char variables, whereas actually str1 is a char pointer and str2 is simply a char. Indeed, I was confused on this point myself when I was a newbie, which led to great confusion later on. The clearest way I've…

What is wrong with having str1 and str2 declared on separate lines? Like this: char* str1; char* str2; What is gained with combining these declarations (except for less typing)?

Grouping comes to mind, e.g.

        int x, y;
        int width, height;
        int area;
        int numPoints;

Re: Source Code Typography

#54

Post by jmhain »

breadbox wrote: post #48

The C example is a great demonstration that typography is not an objective practice. That someone could take the original strcpy() and, with the express goal of improving its appearance, produce something so unpleasant to read ... When I was younger I did a lot more interior alignment between lines, like with the list of variable declarations. Over the years I've found that they add a lot of busywork effort to the ed…

No need to pick between optimization for reading and editing. You can have both by using tools like gofmt and astyle.

Re: Source Code Typography

#55

Post by yareally »

LowKarmaAccount wrote: post #51

The elephant in the room is that many languages have adopted or have been influenced by the C language's miserable practices of ending a statement with a semicolon, and using the equals sign as an assignment operator. Both of these practices break with conventional usages to no discernible advantage. Another impediment to readability is the insistence upon representing code by using hideous, low contrast colors on a…

> The elephant in the room is that many languages have adopted or have been influenced by the C language's miserable practices of ending a statement with a semicolon, and using the equals sign as an assignment operator. Both of these practices break with conventional usages to no discernible advantage.

The convention of = stems from mathematics and using it to assign input to variables there. Algebra probably being the first to use it about 1000 years ago.

Re: Source Code Typography

#56

Post by [deleted] »

LowKarmaAccount wrote: post #51

The elephant in the room is that many languages have adopted or have been influenced by the C language's miserable practices of ending a statement with a semicolon, and using the equals sign as an assignment operator. Both of these practices break with conventional usages to no discernible advantage. Another impediment to readability is the insistence upon representing code by using hideous, low contrast colors on a…

[deleted]

Re: Source Code Typography

#57

Post by wirrbel »

yareally wrote: post #55
LowKarmaAccount wrote: post #51

The elephant in the room is that many languages have adopted or have been influenced by the C language's miserable practices of ending a statement with a semicolon, and using the equals sign as an assignment operator. Both of these practices break with conventional usages to no discernible advantage. Another impediment to readability is the insistence upon representing code by using hideous, low contrast colors on a…

> The elephant in the room is that many languages have adopted or have been influenced by the C language's miserable practices of ending a statement with a semicolon, and using the equals sign as an assignment operator. Both of these practices break with conventional usages to no discernible advantage. The convention of = stems from mathematics and using it to assign input to variables there. Algebra probably being t…

Assignments != Equation

Assignments are pretty unmathematical since they represent memory operations and (usually) allow for mutation.

Wirth chose := in Pascal for a reason (with the comparison operator begin = instead of == there which is at least closer to the mathematical = operator).

Re: Source Code Typography

#59

Post by astrodust »

tmoertel wrote: post #11

Typography is a subtle and tricky thing. What seems “better” may actually provide misleading cues. For example, consider the alignment in the following, improved snippet from the blog post: var x = shape.left(), y = shape.right(), numSides = shape.sides(); It may be “better” typographically, but it also suggests a false parallelism. The eye can't help but interpret closely packed things as groups. So the subliminal c…

The kind of people that line up their assignments and other syntax elements of the same sort are the ones that prefer justified text, even in inappropriate cases. It's annoying.

You also end up with "floaters", where if in this case `numSides` is removed, x and y assignments will have a needless number of spaces. These can be corrected, but you'll also inherit "blame" for the change, which is misinformation.

Keep them tight, learn to read code that way. Code is not ASCII art.

Re: Source Code Typography

#60

Post by wirrbel »

I think looking at musical typesetting is even closer to the problem of typesetting source code. lilypond.org does explain some ideas about musical typesetting. For example when and when not to align notes, etc.

The OP does seem to favour a table-like grid layout for source code, yet I rather feel like source code describes hierarchical trees (that is why we like the indenting). Arranging things in a tabular way is not principally beneficial. Sometimes you encounter things like this:

    int                x =       get_width();
    const long double  y = 1.5 * get_width();
But what use is the aligning? Type, identifier and value of `x` are far apart, it is easy to switch lines here.

Now most programming languages have a big problem with indentation and layout because their syntax is weird. C's habit of putting types in front, etc. That is probably why the GNU C styleguide is proposing something like this:

    int
    strcpy( ....
Type and identifier on separate lines. This style is not widely adopted, and that probably shows another aspect of typography: What is typographically correct depends on what is common.
Post reply on HN