Hacker News Reader

Comment by masklinn | Hacker News Reader

kozak is specifically saying their linter is mostly focused on any non-codestyle issue.

And compiler errors are not worth linting given you can just do a syntax check, linting is useful to avoid or require disambiguation of error-prone constructs.

Examples in JS would be `with`, `==`, assignments inside a conditional check, parseInt without a base (mostly in older browser), parseFloat, non-prefixed octal literals (073 rather than the explicit hex-style 0o73), string expression statements (outside of the "use strict" pseudo-pragma), and several scoping errors (which strict mode will mostly only check at runtime). All of these are syntactically perfectly valid, but more often than not they're also mistakes or sources of errors.

View on HN

assignments inside a conditional check

I see this in C code often. Why do people seem to like doing this?

Masochism?

Because

    while ((c = getchar()) != EOF) {
     //
    }

Is considered more idiomatic and readable than any alternatives that's not assigning to c within the conditional. You'll see similar idioms in many other languages, e.g.

     while((line = reader.readLine()) != null) {
     }

But if you're talking about e.g.

    if (foo = (bar & 0xf)) {
    }

It's just bad style ...

I think it's more idiomatic because otherwise you have to do:

  char c = EOF;
  while (c != EOF) {
    c = getchar();
    ...
  }

The idiomatic way reads better: "while next character is not EOF".

Your (excellent) example of bad style is bad because it reads poorly: "if the result of the assignment of bar & 0xf to foo is true". Not only that, but it is not obvious what the result of an assignment is, if anything. (Yes, I do know it is the value, but personally, I think <nothing> is a more logical result).

Don't you mean

    char c = getchar();
    while (c != EOF) {
        c = getchar();
        …
    }

Which not only reads badly but requires writing the "producer" twice. Though alternatively you could:

    while (1) {
        c = getchar();
        if (c == EOF) { break; }
        ...
    }

    char c;
    do {
        c = getchar();
    } while (c != EOF);

This is worse, in most cases as you normally want to do something to c after you have read it, forcing you to re-check the condition

    int c; //a char can't represent EOF
    do {
        c = getchar();
        if (c != EOF) {
           //do stuff
        }
    } while (c != EOF);

As demonstrated by other commenters, makes for a terse iterator-ish pattern in languages without iterators (like C, or until recently Javascript) e.g.

    while ((c = getchar()) != EOF) {
     //
    }

in a language with iterators would be

    for (c in chars()) {
     //
    }

And note that this C pattern only works when you can pass the "end of iteration" signal in-band, if you can't you will need to use more complex pseudo-iteration protocols e.g.

    while(generator(&c)) {
        //
    }

if ((err = func())) goto fail_err;

Two of the most hated thing of C but so convenient...

Reply on news.ycombinator.com