Source Code Typography
naildrivin5.com
Source Code Typography
1–10 of 69 posts
Re: Source Code Typography
#2Code 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
#3Re: Source Code Typography
#4Re: Source Code Typography
#5Re: Source Code Typography
#6 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
#7I really feel that the for loop should be converted to a while loop - that would probably make the intent clearer.
Re: Source Code Typography
#8Also, I think color is really useful and something that's not used as much in traditional typography.
Re: Source Code Typography
#9Re: Source Code Typography
#10A 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.