[Bf-committers] (re) proposal for pep8 for blender scripts

[Joshua Leung]

-1  on tabs -> spaces. Personally, I find it a nuissance when editing code
indented with spaces, that often erasing the contents of a line of code
often requires a bit of indention tweaking afterwards - i.e. a need to judge
whether the line is now +/- 2 spaces in line with the reset of the code -
which with tabs is less of an issue since the visual size of whitespace
blocks is generally large enough to tell the difference easily. Then again,
there are still heaps of lame-duck text editors out there which cannot
properly handle tab-based indention (their options for these things are
often severely limited), which often butcher indention with a combination of
tabs+spaces. Oh well, if that applies to most of the text editors used by
people who use py, then so be it... </end rant>

-1 on a strict 80 char limit, but +1 for a "soft" 80 char limit. That is,
most lines should not exceed this length, but if the amount which it would
exceed this length is greater than about 2 words, then line breaking should
occur (or refactoring).

Other than that, the pep8 recommendations seem rather logical / standard
practice in general :)

On Fri, Oct 30, 2009 at 10:05 AM, Campbell Barton <ideasman42 at gmail.com>wrote:

> I'm not against 80 char limit per se, its just I can think of a few
> scripts I have written that use nested loops that would loose
> readability if broken into multiple functions and look very ugly if
> they were spread over multiple lines.
>
> How about we do this...
>
> Move to pep8, when a script is compatible we give it a comment in the
> header like..
> # pep8 compatible
>
> If the person who is converting the script (or the author) wants to
> enforce 80 limit a different comment can be used
> # pep8-80 compatible
>
> Then the auto script checker tool can look for these comments.
>
> typo correction: PyFlakes (wrote as PyFlages in the original mail)
>
> On Thu, Oct 29, 2009 at 9:47 PM, joe <joeedh at gmail.com> wrote:
> > I don't think we can afford to be too religious on enforcing something
> > like an 80-col limit. . .sometimes doing so requires refactoring your
> > code, and no one's going to refactor code purely to enforce a specific
> > column limit.  It may be worth doing it later, for readability, but
> > when there's so much work to be done, spending that much time purely
> > to make the code more readible is kindof wasteful.
> >
> > Joe
> >
> > On Thu, Oct 29, 2009 at 12:34 PM, GSR <gsr.b3d at infernal-iceberg.com>
> wrote:
> >> Hi,
> >> ideasman42 at gmail.com (2009-10-29 at 1453.59 +0100):
> >>> http://www.python.org/dev/peps/pep-0008/
> >>
> >> Yes, we should use that. And something similar in other parts (C,
> >> C++). ;]
> >>
> >> [...]
> >>> One exception I think we should make is the 80 width line.
> >>> Screen size is given as a reason for this however blender is graphics
> >>> software and I think its fair to assume people are not developing
> >>> blender on tiny screens,
> >>> pythons tools can be configured not to check for this.
> >>
> >> It is not about tiny screens, but about readability (human limit, not
> >> computer's). Printing has been in multiple columns for wide surfaces
> >> for a reason, long lines are hard to follow. Zebra paper for wide code
> >> listings were not a decoration, but a necesity, and even so not
> >> everyone liked 132 cols.
> >>
> >> This also applies to on screen code, and even more so to patches as it
> >> makes tracking things simpler. Or comparing different files with
> >> multiple windows or even just having multiple windows open at the same
> >> time.
> >>
> >> So go ahead, full PEP8 as much as possible.
> >>
> >> GSR
> >>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>