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

31–40 of 69 posts

Re: Source Code Typography

#31

Post by maxerickson »

jwarren wrote: post #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?

Well, I guess you expect that it is copying something. It is implemented using C pointers, which enjoy a reputation of being difficult to explain. For example:

http://stackoverflow.com/questions/15151377/what-exactly-is-...

Accepting some level of fuzziness, the ++ parts are moving through two spots in memory, the * parts are copying the contents of the one to the other. It all goes 1 byte at a time.

(I apologize if my assumption that you are not familiar with C is off base)

Re: Source Code Typography

#32

Post by Fa773NM0nK »

kruhft wrote: post #25
Fa773NM0nK wrote: post #21

"occasional performance concerns require putting readability in the backseat, but this is rare" occasional ? Seriously? rare ? Seriously? "Source code should be written to be understood by people." Nope, Source code should be written to be executed. If people can understand it easily, its a plus point, not a baseline. Considering that the keyboard is the primary way we write sources, I find it difficult enough to kee…

> "Source code should be written to be understood by people." This viewpoint is described well in the Preface to the First Edition of Structure and Interpretation of Computer programs, 2nd paragraph: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html I would suggest reading the whole Preface. It's quite an inspirational work for this field.

"The source of the exhilaration associated with computer programming is the continual unfolding within the mind and on the computer of mechanisms expressed as programs and the explosion of perception they generate. If art interprets our dreams, the computer executes them in the guise of programs!"

Enjoyed it! Thanks!

Re: Source Code Typography

#33

Post by gknoy »

jwarren wrote: post #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?

    for (; (*to = *from) != 0; ++from, ++to)
to and from are pointers to characters. When we increment them, we point to the next memory location in each string.

    "hello"  // a sequence of bytes with a zero marking the end 
     ^-- to
In our loop, we don't need to allocate any helper variables, and can just increment our pointers to point to the next memory slot in each string. I'm not a C expert, so I may get this subtly wrong, but I believe this is equivalent to:

    do {
        *to = *from;    // copy character from source to destination
    } while (0 != *to); // until we reach the '\0' terminator

Re: Source Code Typography

#34

Post by brudgers »

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

There are a couple of things I see which influence the typographic decisions regarding the code. First is its size - not really big enough to justify a data abstraction for the strings forming regex's. Being standalone, there is a justification for inlining these that would not be there for a similar snippit from part of a larger system.

A second feature appears to be optimizing the layout to display in "forty lines." There are places where the lines could be shorter but aren't. Not abstracting the strings falls somewhat into this category.

Finally, the code snippet does not appear to be the output of a pretty printer. Instead the typography is based on considerations beyond readability.

Re: Source Code Typography

#35

Post by tmoertel »

prawks wrote: post #16
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…

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 p…

The point I was trying to make, however, is that since the example code is JavaScript, the reality is that a statement like that will always result in sequential evaluation and binding and, therefore, a typographical treatment that suggests otherwise will provide misleading cues always.

The author's intent doesn't matter at that point. The typographical treatment has already reached the reader's eyeballs.

If the language were Haskell, however, the align-on-equals treatment would actually communicate the truth. For example, the following code means exactly what its visual presentation suggests it means (see [1]):

    let x      = y + 1
        y      = foo 0
        foo i  = max 0 (i - 1)
    in ...
So this treatment adds clarity, not takes it away.

[1] http://www.haskell.org/onlinereport/exps.html#sect3.12

Re: Source Code Typography

#36

Post by _m_a_u_r_i_c_e_ »

A comma maybe is not so important in a language between humans like here --->, but in a programming language (as human-human AND human-computer medium) a comma is often an important separator. Missing it breaks often correctness, therefore having it first in the line based on importance is ok for me. No syntax compile tool needed to visualize its ok...

Re: Source Code Typography

#37

Post by vec »

Fa773NM0nK wrote: post #21

"occasional performance concerns require putting readability in the backseat, but this is rare" occasional ? Seriously? rare ? Seriously? "Source code should be written to be understood by people." Nope, Source code should be written to be executed. If people can understand it easily, its a plus point, not a baseline. Considering that the keyboard is the primary way we write sources, I find it difficult enough to kee…

One of my professors in college put it in a way that stuck with me. All source code has to be compiled by (at least) two different machines; the compiler and the programmer's brain. The machines have radically different parsers, but must end up with the same parse tree for the program to function correctly.

Re: Source Code Typography

#38

Post by rflrob »

jmoiron wrote: post #27

Unfortunately if you focus on beauty you sometimes break pragmatism. The JavaScript example in particular is not merely a typographical convention, but a way to avoid common errors. var i=1 , j=2 , k=3 You can remove any of the comma prefixed lines there (even the last one) and not introduce an error. You can add another similarly prefixed line anywhere to the list and not introduce an error. It's obvious if a comma…

I don't know JavaScript, but I found it easy to interpret the commas as ditto marks, essentially reminding you that there's an implicit var before each declaration. Even without understanding the original reasons behind the convention, I'm not convinced the OP made an improvement.

Re: Source Code Typography

#39

Post by jamesaguilar »

It's better to just use an autoformatter like clang-format. The miniscule time you'll save reading the code with clever formatting is going to be wasted in arguments with fellow contributors about how clever the formatting is and whether it's appropriate.

Re: Source Code Typography

#40

Post by dsego »

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)?
Post reply on HN