[code-quality] Code-quality & PEP257

[Ian Cordasco]

On Wed, Apr 17, 2013 at 8:49 AM, Ian Cordasco
<graffatcolmingov at gmail.com> wrote:
> On Mon, Apr 15, 2013 at 2:59 PM, Vladimir Keleshev
> <vladimir at keleshev.com> wrote:
>> Hi Ian,
>>
>> I'm actually on the mailing list as well (since maybe 2 weeks ago). You
>> might remember my email about proposing a common format for error messages.
>> I think it's a great idea to coordinate development of our static-analysis
>> tools. Adding pep257 to flake8 might be a good idea. Shall we call it
>> fla257ke8? :o)
>>
>> But I'm not sure I understand the purpose of flake8. Wouldn't having a
>> common error format between all the tools defeat the purpose of flake8? Then
>> a dummy runner would suffice. Imagine a world where all static analysis
>> tools have a common output format and same command-line interface and error
>> conventions.
>>
>> Cheers,
>> Vladimir
>
> Hey Vladimir,
>
> I'm awful with names, so I apologize for not putting your post there
> together with the fact you work on PEP257.
>
> flake8 (as soon as we update to pyflakes 0.7 which was just announced)
> will have a consistent error format. (Prior to 2.0, our vendored copy
> of pyflakes provided column reporting which was just introduced in
> pyflakes 0.7 and was missing in every official version prior to it.)
> As for the purpose of flake8, it was created to run pep8 and pyflakes
> and optionally check the McCabe complexity score. It is already
> extensible to check naming conventions via pep8, so extending it (most
> likely through an add-on) to check doc-strings would be a logical
> step.
>
> I'm not readily familiar with pep257's error reporting, but in
> skimming over the code I noticed the Error class. I'm sure if we had
> to, we could monkey patch your tool (as we already monkey patch
> pyflakes), to standardize the output for flake8 users. Due to the fact
> we can do that (and already do), I'm not sure attempting to make a
> standard way to report errors, warnings, etc. is an immediate
> priority. It's certainly something to consider, but we will encounter
> the issue where tools are old enough to have other tools written to
> parse their output. They could add options for different styles of
> reporting, but if they're anything like pep8, they already have those
> options which makes this a non-issue.
>
> Anyway, I look forward to working with you on integrating pep257 into
> flake8 and I hope to hear more from you.
>
> Cheers,
> Ian

And after re-reading a couple Flake8 issues, I re-discovered this
project: https://github.com/fedora-static-analysis/firehose It was
suggested to us by the author itself and you'll probably find it very
interesting Vladimir. :)

I'm looking into it myself