Email Re: [Python-projects] Possibility of using pylint to automatically reformt code?

On Sunday 02 April 2006 23:30, Brian Troutwine wrote:
> About a week ago I came into a poorly formatted medium sized project,
> somewhere on the order of 60,000 lines of code. The formatting is
> really sporadic--some source files have indents of 2, 4, or 8 spaces
> and lines of 60, 75, or 80 chars--and while pylint correctly points
> out where the files need to be changed to come into conformance with
> the style guidelines there is simply too much code to reformat all of
> that by hand.
>
> So, I began looking around the internet for python beautifiers. The
> closest thing I found was Guido's pindent, which lives in
> Tools/scripts/ of the python source tree, but it relies on end of
> block comments, can't change the length of lines, and has some other
> unwelcome restrictions. Given that pindent is the only thing I've
> found it looks now like it's time to either roll my own, or beg
> someone else to roll one.
>
> To that end I've got a question: How difficult would it be to use
> pylint as the backend to a source code re-formatter, assuming that I
> want the re-formatter to re-format as closely to the python style
> guide as possible? I've looked through the docs and pylint looks to be
> pretty inclusive, but with a little finagling I suppose I could get it
> would work. Would that be worth my time though? Has something like
> this already been done?

I don't think that breaking lines to fit into 80 columns is a job you could 
leave to a program. The purpose of this convention is to make the code 
readable in 80-column display, e.g. terminal windows (sometimes I have to 
work on a system with a 80x25 text display, and I really appreciate this 
convention). On such narrow displays the code gets wrapped on a mostly random 
positions making it hard to read. An 'automated code wrapper' could not do 
much more - break the line a whitespace close to column 80, which does not 
take the program logic into account. So there's not much advantage over long 
lines.

My advice would be to increase the line length or disable this message 
completely in pylintrc. Should you ever have to read and understand the code, 
break lines manually in a way that makes sense and the code more readable.

Other conventions like whitespace in expressions or lists ('a+b' vs. 'a + b') 
could probably be fixed by a program, but I've never heard of such a thing. 
Quick googling suggests http://www.polystyle.com/, you might give it a try.

-- 
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://pink.odahoda.de/
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects