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

21–30 of 69 posts

Re: Source Code Typography

#21

Post by Fa773NM0nK »

"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 keep my fingers in speed with my thoughts. In addition to that if I have to press tabs to align each of the statements in my 'for's, I'll be left in a much poorer way.

Re: Source Code Typography

#22

Post by JungleGymSam »

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…

I'm a layman so I ask this question with sincerity. Would your opinion change if the formatting was performed manually, at the moment of your choosing?

Re: Source Code Typography

#23

Post by thedufer »

While I like the idea of talking about typography in code, I don't think it's likely that we're as badly off as the post suggests. In fact, pretty much all of those examples make it harder for me to read.

>We’ve also re-set the data type such that there is no space between char and * - the data type of both of these variables is “pointer to char”

No. No no no. That is how you end up with people who can't parse `char* a, b;`. What you're doing is declaring that `* to` and `* from` are `char`s. The common reading that the post suggests is wrong and detrimental to reading C properly.

Re: Source Code Typography

#24

Post by dsego »

oneeyedpigeon wrote: post #18
dsego wrote: 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 par…

I guess your example is so idiomatic that it's easy to recognise what it does at a glance. It's good to use easily recognisable patterns. The problem is that I really feel that pointer arithmetic should be separate, because in more complicated code the above style might lead to off-by-one errors that are hard to detect. Also, I don't think the comparison with 0 is pointless. I feel that you should only remove the comparison when an expression gives a boolean result. One other problem here is that, at least for me, it seems safer to only write termination conditions inside parens and the copying code in the loop's body.

Re: Source Code Typography

#25

Post by kruhft »

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.

Re: Source Code Typography

#26

Post by georgef »

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 ever found to think about C declarations (ironically, I think I read this in some article maligning C's syntax in favor of Go's), is that each declaration is of the format

    [type] [expressions--one for each new variable--that equate to type];
Thus, the way I think of declaring a char pointer is

    char [de-referencing the variable (which is a char pointer) to arrive at the char];
    char *str;
(Obviously, not everyone is going to agree that that is simple, but it works for me and my brain.)

Anyway, the point is that while typography is great, it can be just as harmful as helpful if you communicate the wrong impression to the reader. And to be fair, it really looks like the author is not at home in C: besides his misconception about pointer declaration, he didn't bat an eye at the old-style argument-declaration syntax that has been obsolete since ANSI C.

Also, I hope I never write a for loop that looks so massively bloated--a matter of opinion I guess.

Re: Source Code Typography

#27

Post by jmoiron »

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 is missing (which is good, because you don't have a compiler to let you know).

It can be difficult to spot the lack of a trailing comma, or the end of this declaration list having a comma instead of a semicolon (, vs ;), both of which will break the execution of your script.

So please, do not change your code to make it look better without understanding why it's like that in the first place.

The classic example is tchanging the following to allman/gnu style braces would break it in JavaScript:

    // works, returns {a:1,b:2}
    return {
        a: 1,
        b: 2
    }

    // semicolon inserted after return, returns undefined
    return
    {
        a: 1,
        b: 2
    }

Re: Source Code Typography

#28

Post by kruhft »

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.

I apologize, the Foreward is the inspirational work I was speaking of:

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-5.html

Not that the contents of the Preface should be ignored :)

Re: Source Code Typography

#29

Post by Fa773NM0nK »

JungleGymSam wrote: post #22
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…

I'm a layman so I ask this question with sincerity. Would your opinion change if the formatting was performed manually, at the moment of your choosing?

"formatting was performed manually"? What do you mean by that?

I'd rather it be performed automatically. But, I find very few tools that would format it the way I want.

Re: Source Code Typography

#30

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.

Cool! I'll surely give it a read!
Post reply on HN