[Biopython-dev] Fwd: git pre-commit hook for PEP8 style checking

[Christian Brueffer]

I agree, that's why it's in the ignore_list in the hook :-)  The length
is configurable through "pep8 --max-line-length=n" though, in case we
agree something should be done about that sometime down the line.

The current ignored codes are these:

E121-E129, E131, and E501 (indentation and long lines)

Maybe we should also ignore the following for now:

E261 	at least two spaces before inline comment
E225 	missing whitespace around operator
E226  	missing whitespace around arithmetic operator
E227 	missing whitespace around bitwise or shift operator
E228 	missing whitespace around modulo operator

Especially whitespace around operators is controversial, I think.  I
like it most of the time, but in some cases (e.g., array slicing,
complex formulas), I find no whitespace to be more readable.

Thoughts?

Chris


On 10/20/14 7:54 PM, Peter Cock wrote:
> That sounds like a good approach Christian - start gently with only a
> small set of PEP8 tests on the commit hook :)
> 
> What about PEP8 E501 (line too long) with its default of 78 characters,
> this is really a human judgement call - and indeed PEP8 was actually
> revised here:
>  - https://hg.python.org/peps/rev/fb24c80e9afb
>  - http://legacy.python.org/dev/peps/pep-0008/#maximum-line-length
> 
> So unless the pep8 tool E501 line length is configurable, I would not
> favour including it in a standard git commit hook.
> 
> Peter
> 
> On Mon, Oct 20, 2014 at 6:32 PM, Christian Brueffer
> <christian at brueffer.de> wrote:
>> I also see PEP8 and docstrings as mostly seperate issues, especially since
>> I'm basically done fixing the few issues that concerned them.
>>
>> It's true that some error classes have a high occurrence, i.e., various
>> kinds of indentation issues (which are the biggest bunch currently excluded
>> from the commit hook), whitespace around operators etc.
>>
>> What I'd like to see is do is take measures to prevent easy stuff from
>> creeping back in (e.g., EOL and EOF whitespace, bad indentation ...), while
>> slowly chugging away at the bigger issues.
>>
>> That's also why I'd like input on which rules to in/exclude in the commit
>> hook.  I think it's better catch the worst offenders with buy-in from
>> everyone, than to enforce everything at once and have make the
>> commit process so annoying that people just add a git alias including
>> --no-verify :-)
>>
>> Chris