Live data from Hacker News

Source Code Typography

naildrivin5.com

11–20 of 69 posts

Re: Source Code Typography

#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 cue presented by the formatting above is that there is a parallel assignment from the group of expressions on the right to the group of variables on the left. That is, at some level the eye can't help but see the code above as

                   { e }
         { v }     { x }
    var  { a }  =  { p } ;
         { r }     { r }
         { s }     { s }
But the evaluation and assignment are not parallel! They are sequential. The difference may not matter in this example, but it's easy to imagine this kind of formatting applied to examples where it would.

The less-formatted original version below actually represents the reality more faithfully because its shape does not suggest parallelism:

    var x = shape.left(),
        y = shape.right(),
        numSides = shape.sides();
It looks more like a sequence, which it is.

Indeed, typography is a subtle and tricky thing.

Re: Source Code Typography

#12
Personally, I've always found code with a "table structure" prettier but less readable in practice. It's also fussy and time-consuming to maintain. I favor information density and flow.

Re: Source Code Typography

#13
Given that we can't get developers to agree on where to place { I highly doubt we'd ever be able to settle on more esoteric formatting issues.

I'm also not sure that I want a developer spending much of his brain space or time prettying up the code beyond what is currently considered well formatted code. While it might be nice, there's also probably better things she could be working on.

Re: Source Code Typography

#14
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-…

I think it's an easy thing to get used to, especially if the parentheses are a bit thicker. They're just a more slender character than a curly brace, so they don't appear to take up as much space as the others even in a monospaced font.

Re: Source Code Typography

#15
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 arguments are indented, functional code will show more variation in indentation. Functional code looks fluid on the page; imperative code looks solid and blockish, like Basic." -- On Lisp (http://www.paulgraham.com/onlisptext.html; page 30)

As function size grows, it doesn't look quite so pretty. An example from news.arc:

  (if no.user
      (submit-login-warning url title showtext text)
     (~and (or blank.url valid-url.url)
           ~blank.title)
      (submit-page user url title showtext text retry*)
     (len> title title-limit*)
      (submit-page user url title showtext text toolong*)
     (and blank.url blank.text)
      (let dummy 34
        (submit-page user url title showtext text bothblank*))
     (let site sitename.url
       (or big-spamsites*.site recent-spam.site))
      (msgpage user spammage*)
     (oversubmitting user ip 'story url)
      (msgpage user toofast*)
     (let s (create-story url process-title.title text user ip)
       (story-ban-test user s ip url)
       (when ignored.user (kill s 'ignored))
       (submit-item user s)
       (maybe-ban-ip s)
       "newest"))
There's a multi-branch if here, with lots of else ifs. But it's hard to see. In my toy dialect[1], I've added[2] colons as syntactic sugar that expands to nothing:

  (if no.user
      : (submit-login-warning url title showtext text)
     (~and (or blank.url valid-url.url)
           ~blank.title)
      : (submit-page user url title showtext text retry*)
     (len> title title-limit*)
      : (submit-page user url title showtext text toolong*)
     (and blank.url blank.text)
      : (let dummy 34
          (submit-page user url title showtext text bothblank*))
     (let site sitename.url
       (or big-spamsites*.site recent-spam.site))
      : (msgpage user spammage*)
     (oversubmitting user ip 'story url)
      : (msgpage user toofast*)
     : (let s (create-story url process-title.title text user ip)
         (story-ban-test user s ip url)
         (when ignored.user (kill s 'ignored))
         (submit-item user s)
         (maybe-ban-ip s)
         "newest"))
[1] https://github.com/akkartik/wart#readme

[2] http://arclanguage.org/item?id=16495

Re: Source Code Typography

#16

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…

Typography doesn't address /what/ should be written but rather /how/ it should be presented to make what was written as readable as possible.

I think this hints at what you're saying, though the author's presentation style may imply that his is the way formatting needs to be done.

"What was written" is analogous to "what the author meant". If they author makes the assumption that those operations may be executed in parallel, irregardless of order, then the exampled typesetting may be appropriate. "Better" typography shouldn't imply that it looks pretty, as in artistic. It should be more readable, without getting in the way of conveying the author's intent. It should aid the reader in reading, and in reading, arriving at the author's meaning.

As with anything, I don't think blindly adhering to example is a good idea; this case is no different.

You're dead-on that typography is subtle and tricky!

Re: Source Code Typography

#17
post #13

Given that we can't get developers to agree on where to place { I highly doubt we'd ever be able to settle on more esoteric formatting issues. I'm also not sure that I want a developer spending much of his brain space or time prettying up the code beyond what is currently considered well formatted code. While it might be nice, there's also probably better things she could be working on.

You should read Code Complete 2. I was surprised but there are actually reasonable arguments against placing the opening brace on a new line. I don't have the book with me now, but I can look it up later if you're interested.

Re: Source Code Typography

#18
post #6

Reading Code Complete (and listening to Crockford's talks) has really opened my mind to writing clearer code constructs. For example, the for-loop's job in the first example should be to track indexes. There shouldn't be code that "does stuff" between parens. Instead of superficially breaking the for-loop into several lines and wasting time on aligning semicolons, it could be re-written as a while loop with clarity i…

Yes, a for loop is ridiculous for a string copy; K&R do it like so:

  while (*t++ = *f++)
      ;
The pointless comparison to 0 is removed, and the semi-colon is required to terminate the statement. Of course, the point about this version is, once you understand it, it's trivial to recognise. Parsing the 'full' version, especially as formatted in the article, takes a lot longer because it's not familiar and contains more parts to read, any of which could deviate from what might be expected. The other positive is much more code is visible at once.

Re: Source Code Typography

#19
Looking at this thread is why we need tools that let us structure code the way "WE" like it, but that outputs said code in a defaulted format.

Basically IDE formatting should be outside of the actual code formatting allowing people to format code how they see fit. Some are going to like to see the code the "standards" way and that's fine; Many of us will not.

@tmoertel's point is a prime example of this, as the only relationship I personally see in the aligned code is that they are all variables. His perceived parallelism was not present in my personal view of that same code snippet. Now for me white-space denotes parallelism more poignantly than alignment.

  var  x                  = shape.left(),
         y                  = shape.right(),
                                                           
meh, I give up trying to format this code block. :P

*This denotes parallels between variables to me. Not the alignment.

The only parallel that is draw for me is that all the items are variables (this would also be reinforced by the color I give variables). I group things with white-space; so that means in the context of the function using the variables as I've laid them out above; x,y are related and most likely linked, where numSides is needed but not necessarily associated inside the function with the x,y variables.

So ya, this stuff is very subjective and as @tmoertel said "subtle and tricky".

O.

Re: Source Code Typography

#20
I come from a photography and design background, and I've tended to naturally write code much like the author is suggesting.

However, the for loop is mystifying to me, but I don't fully understand the actual code there. Would anyone care to explain it?

Post reply on HN