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

61–69 of 69 posts

Re: Source Code Typography

#61

Post by dsego »

zb wrote: post #43
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…

Maybe the reason "C-hackers" do it that way is because it actually works, while your example completely fails to null-terminate the destination string.

Good point. I guess it gets a bit more complicated when you try to do the right thing. So I'll re-examine the simple while loop like oneeyedpigeon posted:

  while (*t++ = *f++)
      ;
This code really packs a lot of punch. The value of f is copied to t and then both pointers are incremented. If the value is 0 the loop is terminated. So there's always at least one character copied.

In my initial rash response the loop would exit without copying the 0. So to fix it I might just add a new line

  *to = 0;
(if I'm not mistaken the pointer is already incremented when the loop exits).

Another option would be a while loop with a break statement, It looks weird, but does express the correct intent, which is "continuously copy from source string and exit if you've reached the end":

  while (true) {

    *to = *from;
    if (*to == 0) break;

    from++
    to++;

  }

Re: Source Code Typography

#62

Post by danbmil99 »

I've always thought source code should use different fonts, and perhaps even non-monospace fonts in some cases (perhaps for strings, comments)

Why are we forced to stick with a single fixed-width font and color, limited use of italics, and no use of boldface?

Re: Source Code Typography

#63

Post by akkartik »

limmeau wrote: post #52
akkartik wrote: post #15

Earlier quoted context omitted.

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

Racket (and maybe other Schemes) lets you interchange [] and () freely. Helps a bit. e.g. (cond [(positive? -5) (error "doesn't get here")] [(zero? -5) (error "doesn't get here, either")] [(positive? 5) 'here])

Yeah I considered this:

  (cond
    [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*)]
    [t
     (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")])
Doesn't seem like an improvement. The big aha moment for me was to notice that in imperative languages (C, Java, python, ruby) you got the distinguishing separator between the check and the action:

  if (test expr goes here) { action goes here; }
  else if (next text expr) { ...; }
The intervening keywords also help, but the parens vs curlies are a huge visual signal.

Re: Source Code Typography

#64

Post by ricardobeat »

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…

The article also states that a comma is required between variable declarations is one of the least important pieces of information in this code.

That is wrong. The comma is not incidental, it is an operator that tells you the next declaration is locally scoped. A missing comma changes the result of all following assignments.

Re: Source Code Typography

#65

Post by spartango »

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…

Not too lean too heavily on the crutch of tooling, but it bothers me that this type of error can "slip through the cracks". Our tooling should make it patently obvious that this is a problem (before the code can be tested) if not automatically fixing it.

Indeed many tools (IDEs) do correct these kinds of problems, and it strikes me as silly that we have to worry about the execution of programs failing because of these types of typos/bugs.

Re: Source Code Typography

#66

Post by Luyt »

astrodust wrote: post #59
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…

The kind of people that line up their assignments and other syntax elements of the same sort are the ones that prefer justified text, even in inappropriate cases. It's annoying. You also end up with "floaters", where if in this case `numSides` is removed, x and y assignments will have a needless number of spaces. These can be corrected, but you'll also inherit "blame" for the change, which is misinformation. Keep the…

Also, when you introduce a new variable in such a block of initialisers, and it is longer than the other variables, you have to pad all the other declarations with spaces just to keep them aligned... what a waste of time. Apart from that, it also generates 'false' diffs with source code control systems which are configured to be sensitive to whitespace.

Re: Source Code Typography

#67

Post by Luyt »

danbmil99 wrote: post #62

I've always thought source code should use different fonts, and perhaps even non-monospace fonts in some cases (perhaps for strings, comments) Why are we forced to stick with a single fixed-width font and color, limited use of italics, and no use of boldface?

"Why are we forced to stick with a single fixed-width font"

Not necessarily ;-) Since proportional fonts became available in programmers' editors, I've been using them. See http://www.michielovertoom.com/incoming/desksnap-20101013.pn... for an example.

Sublime also allows proportional fonts, whereas TextMate does not.

Re: Source Code Typography

#68

Post by Luyt »

andrus wrote: post #41

Would like to know whether the author feels his rewrite is more successful than the original. The following takes me longer to read: for ( ; (*to = *from) != 0; ++from, ++to ) ; Whereas the idiomatic version seems simpler: for (; (*to = *from) != 0; ++from, ++to);

When I saw that ridiculous formatted for() in the article, I began suspecting the article was meant as a joke.

Re: Source Code Typography

#69

Post by JungleGymSam »

Fa773NM0nK wrote: post #29
JungleGymSam wrote: post #22

Earlier quoted context omitted.

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.

I meant that the formatting mentioned in the article was done when you chose to do it (by executing a command) rather than automatically as it recognized the syntax.

I guess I'm asking if you object to the formatting itself or the automation of it.

Post reply on HN