Codeq. Code quality as a service | Hacker News Reader

Codeq. Code quality as a service

codeq.io

23 pointsivoflipse22 comments

Open articleView on HN

This isn't static analysis.

Compare the output of a "real" static analysis tool that finds logic bugs[0]

https://www.dropbox.com/s/md35ca9mjrny4o1/Screen%20Shot%2020...

With their whitespace recommendations

https://codeq.io/github/tianyang-li/rna-seq-len-est-0/master...

Which seem to mostly be a wrapper around autopep8: https://github.com/hhatto/autopep8.

Even Pylint / Pyflakes would be more "static analyzer" than this tool, although it's a stretch.

[0] In this case it trips an assert, so the bug can't "really" happen. Still, it's pretty impressive stuff.

I remember how impressed I was when I used clang's static analyser for the first time. I love it, more than makes up for that headache of switching from GCC on OSX.

In what way is pylint not static analysis?

Not sure what you mean by that, but PyLint gets errors like

- calling non-existent members (including class hierarchy analysis)

- reading non-existent variables

See the Exxxx messages http://pylint-messages.wikidot.com/all-messages

I was referring to this quote: "Even Pylint / Pyflakes would be more "static analyzer" [...] although it's a stretch."

Why is it a stretch to say that Pylint does static analysis? This is exactly what Pylint does.

In the case of this tool, it seem that "code quality" means "formatted the way this tool's author believes is correct." I disagree with this definition.

When I think of code quality, I consider things like:

    - consistent memory management practices
    - consistent use of accessor methods vs. direct ivar access
    - descriptive method, function, and variable names
    - commentary to describe caveats and tricky functionality

Those first two (as well as formatting concerns) can be handled by tools while the next two are very "human" and subjective.

Came here to say exactly this.

Here's a sample of the output: https://codeq.io/github/yakxxx/memek/master/crawler/tests/te...

> Trailing whitespace (1, 29, 34)

    Missing optional whitespace around operator (6, 48)

    Blank line contains whitespace (11, 15, 19, 23—25, 33, 44—45, 53—55)

    Continuation line under-indented for visual indent (17, 21)

    No spaces around keyword / parameter equals (17, 21, 48)

    Line too long (100 > 79 characters) (21)

    Too many blank lines (3) (26)

    Continuation line over-indented for hanging indent (29, 34)

    Missing whitespace after ':' (30—31, 35—36)

    Line too long (81 > 79 characters) (30, 35)

    Continuation line indentation is not a multiple of four (30, 35)

    Line too long (80 > 79 characters) (31, 36)

    Closing bracket does not match indentation of opening bracket's line (38)

    Too many blank lines (2) (46)

    Line too long (91 > 79 characters) (47)

    Blank line at end of file (55)

Not to mention that it's quite simple to have your CI server perform these kinds of checks already.

If I'm not mistaken these are the exact messages pep8 produces.

So it's basically pep8 as a service.

- consistent use of accessor methods vs. direct ivar access

This is your second thing you think of when you think of code quality? I think we're right back at "formatted the way this tool's author believes is correct." Your other 3 points are good though, and I'd also add

  - uses generic code only where required, and uses exceptional code only when needed

I did not express a preference for either. I expect consistency in quality code. Anecdotally, being inconsistent when writing code leads to more bugs reports.

'codeq' is also the name of the static analysis tool released late last year

https://github.com/Datomic/codeq

So, PEP8 as a service...

http://www.python.org/dev/peps/pep-0008/

Code Climate (https://codeclimate.com/) is a similar service for Ruby projects that I think does a really good job of this.

And they don't falsely claim to be a static analyser.

Oh come on

Save yourself the money and run pep8 (better, forget about pep8 and run autopep8) and PyLint. Tune their output to your taste

Code style is important but it can be borderline pedantic sometimes.

Also, more than 80 chars fit in my screen

Not to mention that static code analysis can go so far

> Also, more than 80 chars fit in my screen

This isn't the argument, and you know it. I can split an editor window three ways on my MBP and still have all the code look fine if everyone keeps their code to 80 character lines.

This isn't an argument either

Most of the editors do automatic line wrapping, and it looks good regardless of the width picked for the window.

I'm not advocating we start doing very long lines, I'm just saying a hard limit of 80 chars is debatable.

As part of PEP8, it is just as debatable as any other part of PEP8. But if you totally disregard PEP8, you are being annoying

I think this is a great service which I would use for various of my projects. I understand that now it's mostly a MVP but with a few additional features this could become very interesting.

- As others pointed out, the error/reporting needs to be better. Ideally it should gives insight that a normal pep8 parser wouldn't give. I.e. I don't mind that much for the whitespaces.. but if you help me avoid a real bug, that's a huge deal.

Nice effort, but two lines in my shell give me the exact same result, and I can manipulate that to my needs.

Not everything has to be wrapped "as a service".

The advantage of this approach is that it can be integrated into a public build process as e.g. a GitHub service hook. This gives the results a URL, which is a powerful thing.

This might be an off topic question, but is there a way to get ongoing static analysis on either Python or Ruby.

The same way CLANG works with OBJ-C in Xcode.

Reply on news.ycombinator.com