Hacker News Reader

Comment by killahpriest | Hacker News Reader

Annoyingly clever. Even while running Ito JavaScript I have to debate whether I should be annoyingly clever or not.

  /* bad use of while loop with compound if-statement */
  while ((len = getline(line, MAXLINE)) > 0)
    if (len > max) {
        max = len;
        copy(longest, line);
    }
 if (max > 0) /* there was a line */
    printf("%s", longest);

What do you do?

View on HN

(i'm not certain what aspect you are trying to discuss but i'm assuming braces-- as that seems the primary point in the article)

My personal solution (again for JS) would be to use a new line with no braces to split up an if-statement, but to never nest a braced statement as part a pseudo-one-liner, nor to nest many levels of one-liners - as these situations could lead to confusion.

Eg for the above;

  while ((len = getline(line, MAXLINE)) > 0){
    if (len > max) {
        max = len;
        copy(longest, line);
    }
  }
  if (max > 0)
    printf("%s", longest);

This is a personal preference- i find it adequately splits up a one-line `if(max > 0) printf("%s", longest);` statement to be clearly identifiable as an if (while/for/etc) block, without the verboseness of the extra line/2 for braces, which i personally find makes code harder to read.

If I'm intentionally writing a one-line if I will write it on one line. I think using an indented second line without braces is less clear, and more prone to problems later when the code is modified.

So I'd write:

  if (max > 0) printf("%s", longest);

  if (max > 0) {
    printf("%s", longest);
  }

but never

  if (max > 0)
    printf("%s", longest);

I'm SO glad Zed has pointed this out! I dislike code like this and I dislike it even more when people say K&R style is the best, it's classic, believe/follow the creators of the language!

Fu that.

It's error prone, just like Zed says. Add braces, don't be lazy, it makes the code flow easier on the eye.

IMO, In JS, it's painfully dangerous to be "too" clever as well.

Sometimes I like to think about it like so: Will someone else "with less skill than me" be able to follow this code after me? Then again, being human I sometimes fail to think this way :(.

The overly clever argument is only valid if you think the point of K&R is to teach good programming style. In fact it's to teach you to read and write C programs. In many cases the learning point is achieved by the reader puzzling out why the code works and learning from this.

Complaining that this isn't easy enough is missing the point.

Arguing that the language shouldn't allow such constructs is again outside the scope of the argument. K&R designed the language, so presumably they agree with the design.

- if you hit a line longer than maxline you'll end up with a partial line in your 'longest' buffer

- if the line is so long that it will spill across several chunks of 'MAXLINE' length then you'll end up with the next to last bit

- you should probably use a character reader that uses realloc to resize the buffer area until even the longest strings fit or the program fails

- your getline invocation is wrong, the proper one is getline(&lineptr, &cursize, fp);

And the 'real' getline takes care of most of the above gripes, for instance all you'd have to do is to swap the pointer to 'longest' for a fresh one for the next iteration after finding a new longest entry.

Reply on news.ycombinator.com