On 17Mar2015 23:42, Alexander Walters
What coding style would be used for such a tool? PEP-8? What about a tool for those of us who believe that PEP-8 got a few things wrong?
autopep8 at least lets you pick and choose specific issues to apply or ignore. As someone who now aims for a "mostly pep8" style, that is very handy. Aside: I always wish "fix it" tools to have this kind of granularity. In a former life I got to use SGI's C compiler. Like GCC, it had a "lots of warnings" mode, somewhat like a builtin lint. _Unlike_ GCC, the SGI compiler let one suppress specific warnings, which was very very nice.
What about for the tribal knowledge that pythonistas develop over time that are not part of the standard? Would such a tool include this?
Such things get progressively harder to formalise into stuff a tool can implement. I imagine one could implement quite a lot of knobs, but I also imagine that some knobs would require huge code support, and perhaps be intrusive enough to make the default knobs (very?) hard to debug/maintain. Using PEP8 as a guide at least gives a concrete baseline for the feature set. I'm not arguing that that is all one should ever want, just that it is well defined and very broadly appplicable.
And what of third party tools that do the same thing? I have no evidence to support this, but I have the feeling that when the standard library includes something in a new space, third party work in that space slows (json and sqlite come to mind).
Sure. But that isn't always a bad thing; life is too short. In an ideal world the included battery is amenable to extension and then the supplied battery enables faster third party work, at least in the form of adding to the battery.
Good coding style really should not be something we ship in the library, it should be something we teach.
Yes and no.
I wholely agree that good style comes from within, and that it should be taught
"what and why"; blindly applied mechanical style does not itself improve code
quality. Though having consistent style does at least usually improve code
readability and maintainability. Not to mention diff noise.
That said, having a tool that will _apply_ a desirable style is very useful.
Taking myself as an example: my personal library has gads of old code with bad
style (and bad design choices!) I tend to mostly-PEP8 the old code as I come
across it during development (committing separately from semantic changes
unless I've rewritten something outright). That work is slow and incremental.
Having just downloaded autopep8 and given it a tiny trial run against a single
module I found that a bare run produced a diff of more or less the entire file,
but adding "--indent-size 2" (my personal major divergence from PEP8) got the
diff down to a reviewable bunch of small changes, all of which I approve.
Performing that task by hand was an ongoing indefinite inconsistent minor
improvement activity. Now I can branch and restyle vigorously, because I have a
tool to do the picky editing. Yay!
Aside: why the bad style from the outset? When coming to a new language or
system I find it useful to write batteries myself, sometimes because the
supplied battery does not match my needs but usually because the battery is
tractable and I learn quite a lot about the problem domain during this process.
And the same applies to style; my old code has poor style, some leaked across
from other languages. Having written plenty of code according to my whim, I can
then look at a suggested style like PEP8 and evaluate it with context. Now I
mostly aim for PEP8 because I've come to informed decisions about its choices,
and mostly agree with them.
Metaaside: the above is also something of an excuse for the state of some of
the code I've put out there:-)
Cheers,
Cameron Simpson