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

joe joeedh at gmail.com
Thu Oct 29 21:47:05 CET 2009


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
>


More information about the Bf-committers mailing list