4 ms·

We did the same for the linter in our JavaScript project. Of course, the linter config is focused mostly on pitfalls and "good parts", not on code style (except

• vanderZwan 9y ago
  Can't most of these code-style issues be auto-formatted on save these days? Years ago when I still programmed in Go I made use of that all the time: if it didn't format on save I knew I had a compiler error somewhere.
  • masklinn 9y ago
    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.
    • nerdponx 9y ago
      assignments inside a conditional check I see this in C code often. Why do people seem to like doing this?
      • 77pt77 9y ago
        Masochism?
      • noselasd 9y ago
        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 ...
        • prewett 9y ago
          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).
          • masklinn 9y ago
            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; } ... }
            • tbirdz 9y ago
              char c; do { c = getchar(); } while (c != EOF);
              • noselasd 9y ago
                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);
      • masklinn 9y ago
        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()) { // }
        • masklinn 9y ago
          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)) { // }
      • GuB-42 9y ago
        if ((err = func())) goto fail_err; Two of the most hated thing of C but so convenient...