Some style changes don't affect code now but they can have an adverse
impact in the future. Indent falls into this category. For a
language that defines blocks via indentation, python is very lenient
about indentation so many things work but later code additions make
those indentation levels SyntaxErrors or logic errors.
Really a productive thing to be doing here is figuring out if there's
any help that people can give in this area that we would accept rather
than hand waving about sometime in the future... So here's a few that
i think we might be able to agree on from our other conversations.
* non-4 space indent. non-4 space indent leads to SyntaxErrors later
when more code is added to the block. For example:
def test():
if True:
do_this()
+ elif True:
+ do_that()
When the elif is added at the proper 4 space indent, the 3-space
indent of "if True" makes it a SyntaxError.
* mixed tabs and spaces: In python, tabs are equivalent to 8 space
indent so tabs and spaces can be mixed and the interpreter will do
something with it. however, in editors, tabs are not limited to 8
spaces. A good many programmers have it set to display 4 spaces as
that's the indentation level that they expect when they hit the tab
key on their keyboard. reading a file that has mixed tabs and spaces
is insanity in this case. Writing a file that is currently all tab
can be dangerous if you don't realize that the existing indentation is
100% tabs. You may add four space indent that looks right since your
editor is displaying tabs a four spaces but you're really putting
everything at a different indentation level.
* A github hook or tie in to travis that does the enforcement you are
after. It would need to compare the style errors in the parent commit
to the style errors after the commit is applied and then fail if the
commit has new errors in it.
-Toshio
On Tue, Jul 28, 2015 at 10:01 AM, Brian Coca <[email protected]> wrote:
> If it affects how code works, I do not consider it a style change it
> is a bugfix.
>
> If they change unrelated sections as part of a fix, I consider that a
> style change, if the section was so bad it was unreadable, that is an
> acceptable change as I stated above.
>
> For the enforcement I agree, it s a lot easier with a clean base, but
> it is useless to cleanup the base and then have a thousand PRs which
> can 'dirty' it again. Without having an enforcement in place or to be
> put in place right after the style cleanup, it really makes little
> sense to me to go down this road.
>
> Aside from the attribution issues, which I don't see a way around, in
> many cases the nature of our code makes a lot of the linting and style
> checks give out false positives, specifically with modules. One
> solution would be to ignore certain types of issues, but that will
> also hide the actual real positives.
>
> I'm not against having a style guide and enforcing it, I just see pure
> style PRs as near useless at this point, if not counter productive.
>
> Also I think we should be putting our efforts elsewhere right now.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/CAJ5XC8%3DA%2BaGc9r4BdvwbvCHJPdVjGh3o8WhmjCCLooMHg1fcjg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAG9juEr56HoPYMfN%3DP7WYpePsYOfNyvzecmaPH%2BHpa7Ez%3Drxew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
