On Jul 17, 2:35 am, Thorsten Kampe <thors...@thorstenkampe.de> wrote: > * rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT)) > > > 3) Tabs create freedom in the form of user controlled indention. > > > Indention width should be a choice of the reader NOT the author. We > > should never "code in" indention width; but that is EXACTLY what we > > are doing with spaces! No, the reader should be able to choose the > > indention width without ANY formatting required or without any > > collateral damage to the source code. Tabs offer freedom, spaces offer > > oppression. > > Why are you so obsessed with indentation length? Indentation length is > just /one/ of the formatting choices that the author makes for the > reader - and probably the /least/ significant one.
I am not OBSESSED with it, i am just PERTURBED that we are not using tabs; since tabs offer freedom to view the source at ANY indentation level you choose REGARDLESS of what the author "thought" was appropriate. It is a wise choice to only allow tabs in a language that has FORCED indention. This is one way we can actually promote freedom whist maintaining unity. > There is for instance maximum line length, I like to keep lines at 80. Sometimes i go over if the code is not something you would need to read often. If the code was to go into the stdlib i would make sure it was 110% style guide compliant. > the number of empty lines, I hate vertical white-space. I follow Python style guide suggestions, and then some! I hate when people insert spaces into code blocks and function/method bodies. If you feel a space must be inserted then that is a good clue you should be using a comment there instead. Vertical breaks should only happen before and after classes, methods, functions, groups of GLOBALS, groups of import statements. Think of func/method bodies as paragraphs and classes as sections of a book. Two vertical spaces between classes and one vertical space between func/methods. > the author's method of alignment, spaces between the equals sign and so > on. I believe non-compliant spacing in args should throw an syntax error. I hate this: >>> func( arg1 = 1, arg2 = 3 ) It should be... >>> func(arg1=1, arg2=3) Much easier to read when formatted into logical groups. > These are all much more "dominant" in the source code and none of > this is left for the reader's disposition. It should be MANDATED. And these @holes who refuse to format their code in a community standard will suffer the plague of syntax errors. Who do these people think they are? Do they believe the rules do not apply to them? I'll tell you who they are, they are F'ING format criminals. > Compare for instance > > variable = 11 > anothervariable = 22 > > def whatever (prettylong = 1, > alsoprettylong = 22, > anotherone = 33): > pass > > to > > variable=11 > anothervariable=22 > def whatever (prettylong=1, alsoprettylong=22, anotherone=33): > pass Both examples show non-compliance to the Python style guide.Except for this... ------------------ FUNCTIONS/METHODS ------------------ def whatever( prettylong=1, alsoprettylong=22, anotherone=33): OR def whatever(prettylong=1, alsoprettylong=22, anotherone=33): I think the second is more readable for block openers. Note the closing bracket and colon on last line! ------------------ CONTAINER TYPES ------------------ d = { 1:1, 2:2, 3:3, 4:4, } Note closing bracket on newline; and all alone! For hand stitching containers you should put the "closer" on a newline that matches the "opener's" indention level. ------------------ VARIABLES ------------------ variable = 11 anothervariable = 22 Stop trying to be an individual in a community. When you write code for just you then write it any way you like. Go ahead and use that Joker font and 10 space indention. Go ahead an use foolish spacing and whatever. However when you are writing code in public or for the stdlib you should always be Style Guide compliant. You guys should feel lucky i am not the BDFL, because i would cast plagues of exceptions on your lazy butts! -- http://mail.python.org/mailman/listinfo/python-list