launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Tue, Jun 14, 2011 at 1:55 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> Currently we get two (IMO) distinct benefits from running linters:
>  * we find out about functional issues:
>   - repeated definitions
>   - unsafe constructs
>  * We find out about cosmetic issues:
>  - whitespace
>  - indentation
>
> I think we get great value from the former, and limited if any value
> from the second.
>
> So, I'd like to propose we do something other projects do: restrict
> lint to reporting on functional issues, and use an idempotent pretty
> printer to reformat our code automatically.
>

A good way to do the first one is to throw out all of our linters
except pyflakes.

> We would add a post-commit hook in pqm that would reformat the changed
> files using the pretty printer, and we'd no longer need to spend any
> time thinking or worrying about formatting.
>

We'd also have to ditch whatever rules we have about formatting that
aren't supported by the pretty printer. Oh, and we'd still worry about
doctests (moin? rST? how many columns in your Python?), Javascript and
whatever else.


I don't generally find the difference between cosmetic linter vs
pretty printer to be all that significant for me. What matters more is
false positives from the tool and missed rules from the tool. If we
had a cosmetic linter that reported exactly what we cared about, we
could apply a pre-commit hook or something against new bad lint.

Personally, I'd kind of like to try a pretty printer on a smaller
project myself before applying it to Launchpad. Maybe I'll get a
chance to play with testtools soon.

Oh, that reminds me. Using a pretty printer in the way you describe
will make code reviews friendly (less nit-picky) and make it easier
for people who work on many different Python projects to contribute to
Launchpad. (Each project has its own silly rules. 76? 78? 79?)

jml