Live data from Hacker News

Source Code Typography

naildrivin5.com

1–10 of 69 posts

Re: Source Code Typography

#2
The suggested transformations look nice for the trivial, tiny examples used, but would really hurt readability of code in general.

Code is not read linearly as a book - it is 'scanned' and reviewed back-and forth; and the compactness of the code is important for readability.

Also, on currently standard(sadly) computers, especially laptops, vertical space is very restricted in standard LCD dimensions. If you spread out a screen of semanically linked code to two screens, then you suddenly can't grasp it all at once w/o scrolling through the pages back and forth, and that is a real loss. Newlines and empty lines can and must be used to group things in "paragraphs", but the OP suggestions waste far too many lines.

Re: Source Code Typography

#4
If you also consider what commit diffs will look like if you have to insert or delete a variable, (particularly the last one) then comma first creates less cruft in your history.

Re: Source Code Typography

#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 in mind. Like this:

  while (*from != 0) {
    *to = *from;
    from++
    to++;
  }
To me this looks much saner (unless I'm doing something wrong, I'm a bit rusty on pointers). But I notice that a lot of "C-hackers" try to cram as much into one line as they can, often including every possible pointer incrementation and assignment. At least here, the variables are properly named. A lot of C code uses one-letter variables and reading those isn't a lot of fun, e.g.

  while((*t++ = *f++) != 0 ) 
(Note, I don't really know if this is correct.)

Re: Source Code Typography

#7
I positively hate that for loop rewrite. Having the semi-colon so expressly indented looks awful, especially on it's own line.

I really feel that the for loop should be converted to a while loop - that would probably make the intent clearer.

Re: Source Code Typography

#8
I think more important than a particular typographic style is consistency. Most of us move between large codebases that are formatted differently and I find that I can quickly adapt to a different style as long as it's consistent.

Also, I think color is really useful and something that's not used as much in traditional typography.

Re: Source Code Typography

#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-point (point)))
      (cond ((nth 3 parse)
             (re-search-backward
              (concat "\\([^\\]\\|^\\)" (string (nth 3 parse))) 
              (save-excursion (beginning-of-line) (point)) t))
            ((nth 7 parse) 
             (goto-char (nth 8 parse)))
            ((or (nth 4 parse)
                 (and (eq (char-before) ?/) (eq (char-after) ?*)))
             (re-search-backward "/\\*"))
            (t
             (setq count (1- count))))))
See where the ends of the parenthesis point? Not straight up or down, but diagonally.

Just a random thought... maybe it's just me.

Post reply on HN