Hi,
Just the other day I came across autopep8 - https://pypi.python.org/pypi/autopep8
I just tried it on some of the wx.lib.ogl modules.
wx.lib.ogl.basic.py had:
errors = 304
warnings = 269
after running autopep8:
errors = 18
warnings = 6
The remaining warnings where whitespace (W291) within documentation strings and the errors where all line length warnings (E501 , with a line length of 100 instead of the default79).
Would it, at some point in the future, make sense to use this on wx.lib to get a more consistent coding style?
Werner
Well, sorta. Something like this should be very carefully approached .
I occasionally(every once and a while, but at least once) use the PEP8 and AutoPEP8 for my projects to clean up obvious stuff as far as readability and obvious errors are concerned, but note only one feature is used at any given time.
Then the code MUST be checked manually by a human being(Ex: in a diff viewer) to make sure that the program didn’t chew up the input code and spit out something unusable or that would irritate others according to general coding style.
It is a very debated issue for most projects as PEP8 isn’t but a basic style guide. Most style points are agreeable on, but not all(esp by everyone). Ex: line length, lining up code, etc… that should be avoided.
When in doubt follow the zen. premature optimization is the root of optimized code sooner rather than later or never at all.
But then again… I think this type of work might rub Robin the wrong way, when it comes to his free time, as we haven’t gotten the trailing space eradicated yet…
Maybe some day… But HOPEFULLY before Phoenix goes live, we can all agree on the other cruft that should at least get some attention every once and a while and get something done about it.
So… your not the only one that occasionally thinks about these types of things.
I often see other developers bugged to the brink of “OK, I’ll do it. Just leave me alone for crying out loud.” before anything is ever done about
it because they might be the only one with access to change stuff like that for a project.
Sometimes this takes years. I depends on your priorities and motivation mostly.
All I ask for is that the code whitespace be trimmed and the readability consistent throughout(Think like a book) whatever that may entail.
···
On Wednesday, June 18, 2014 6:16:25 AM UTC-6, werner wrote:
Hi,
Just the other day I came across autopep8 -
https://pypi.python.org/pypi/autopep8
I just tried it on some of the wx.lib.ogl modules.
wx.lib.ogl.basic.py had:
errors = 304
warnings = 269
after running autopep8:
errors = 18
warnings = 6
The remaining warnings where whitespace (W291) within documentation
strings and the errors where all line length warnings (E501 , with a
line length of 100 instead of the default79).
Would it, at some point in the future, make sense to use this on wx.lib
to get a more consistent coding style?
Werner
Regarding line length: Anything less than 1024 is acceptable generally overall that won’t create an error with todays modern tech. So keeping lines 999 or less is rule of thumb for cross-compatibility.
Usually this is only done for database stuff(like the pyembedded image strings) or when "tidy"ing code before a RELz for optimization reasons, then not meant to be edited again afterward.
But in general 40-80-120-160-200 chars is a norm, depending on the resolution/max line length. Anything longer would only be easier readable by a computer, etc…
Shift+ScrollWheel should horizontally scroll also for people with disabilities or line length peevs, but then again… Not all editors are created equal.
Not everyone uses a keyboard or mouse to program with and vise versa, so that should be a concern higher that anything a style guide should ever influence you to change things stylistically.
autopep8 seems to try to do things on the ‘save side’ unless you use
the ‘aggressive’ flag, so this should hopefully not cause big
issues.
The little I saw autopep8 can be configured what one wants it to
optimize or not, so that should technically be easy - until we
people get involved:)
Definitely don’t want to rub Robin the wrong way, and I would be
surprised if this would do it. Anyhow if he says not interested
that is fine with me, if he says yes, then it is obviously him who
decides what should not be used in the autopep8:
Werner
···
On 6/20/2014 2:09, Metallicow wrote:
On Wednesday, June 18, 2014 6:16:25 AM UTC-6, werner wrote:
Hi,
Just the other day I came across autopep8 -
[https://pypi.python.org/pypi/autopep8](https://pypi.python.org/pypi/autopep8)
I just tried it on some of the wx.lib.ogl modules.
[wx.lib.ogl.basic.py](http://wx.lib.ogl.basic.py) had:
errors = 304
warnings = 269
after running autopep8:
errors = 18
warnings = 6
The remaining warnings where whitespace (W291) within
documentation
strings and the errors where all line length warnings (E501 ,
with a
line length of 100 instead of the default79).
Would it, at some point in the future, make sense to use this
on wx.lib
to get a more consistent coding style?
Werner
Well, sorta. Something like this should be very carefully
approached .
I occasionally(every once and a while, but at least once) use
the PEP8 and AutoPEP8 for my projects to clean up obvious
stuff as far as readability and obvious errors are concerned,
but note only one feature is used at any given time.
Then the code MUST be checked manually by a human being(Ex: in
a diff viewer) to make sure that the program didn’t chew up
the input code and spit out something unusable or that would
irritate others according to general coding style.
It is a very debated issue for most projects as PEP8 isn't
but a basic style guide. Most style points are agreeable on,
but not all(esp by everyone). Ex: line length, lining up code,
etc… that should be avoided.
When in doubt follow the zen. premature optimization is the
root of optimized code sooner rather than later or never at
all.
But then again... I think this type of work might rub Robin
the wrong way, when it comes to his free time, as we haven’t
gotten the trailing space eradicated yet…
https://pypi.python.org/pypi/autopep8/1.0.3#features
autopep8 seems to try to do things on the 'save side' unless you use
the ‘aggressive’ flag, so this should hopefully not cause big
issues.
I don’t recall what version I was using but it was probably pre 1.0 or so. I don’t recall if the aggressive flags thing was implemented at that point. I recall if I didn’t specify exactly what to do it would just wreak it all regardless, which made a mess of things in my opinion as it doesn’t(or maybe didn’t I should say) make a copy of the files processed before modding them. It was at that point I decided to just roll my own better implementation with the PEP8 source hooked into SourceCoder as a python lexer special option/helper with annotations and a bunch of nicer line by line type diff viewing graphically like winmerge sorta, but without the whole auto opps factor.
Plus it is easily configurable as to what to complain about with some checkbox settings. otherwise you get obviously time wasting lines such as the one in the attached screenie. ?!? Whaddaya mean space after # … see what I mean. certain things should be ignored of course per settings like a code commented style with two ##, etc…
It is a very debated issue for most projects as PEP8 isn't
but a basic style guide. Most style points are agreeable on,
but not all(esp by everyone). Ex: line length, lining up code,
etc… that should be avoided.
When in doubt follow the zen. premature optimization is the
root of optimized code sooner rather than later or never at
all.
The little I saw autopep8 can be configured what one wants it to
optimize or not, so that should technically be easy - until we
people get involved:)
I see the version is 1.0.3 now. I’ll have another look at what has changed since older versions. Hopefully it has fixed some of the over sites earlier versions had and make things easier to get done without extra hassle.
···
On Tuesday, June 24, 2014 9:44:24 AM UTC-6, werner wrote: