Coding conventions

Coding
,
#21

resurrecting a dead thread…

any of you guys use this?

#22

I do :slight_smile:

Since it’s resurrected I’ll add my 0.02!

instead of doing alot of nested ifs and loops, try aborting early! Same goes for loops!

BAD:


if blabla
   some code
   .....
   if blablabla
      more code
      .....
      if blablabla
         for blabla in blablablabla
              if blablabla
                  more code...

GOOD:


if not blabla
    return

.....

if not blablabla
    return

.....

if not blablabla
    return

for blabla in balblabla
     if not blabla continue
     ...

Same result and easier to read imo in more complex scenarios, though it all depends on the situation and context. This is the way I prefer, doesn’t mean everyone agrees :slight_smile:

#23

+1 to that…

That’s more than a nice style, it’s better for maintenance. Implicitly failures or exits should happen as early as possible so that there’s no need to traverse the entire scope to find out what happens:


if is_the_right_thing (val):
    ''' yes, i know you don't want to write a single function that returns None, False or a List.... unless you work for Autodesk....''''
    other = do_something ( val) 
    if other: 
       successes = []

       for item in other:
           if iterate_item(item):
                print ("I did something to ", item)
                successes.append(item)
           else: 
                print ("skipped ", item)
       
       return successes
   else:
         return False
else:
    return None

# vs:

if  not is_the_right_thing (val):
    return None

other = do_something ( val) 
if not other: 
    return False

successes = []
    for item in other:
        if iterate_item(item):
                print ("I did something to ", item)
                successes.append(item)
           else: 
                print ("skipped ", item)
return successes

And OP: yes, I mandate PEP-8. I’m not actually that fond of it but (a) most people have seen it and (b) most people will have to read it sometime.

#24

[QUOTE=UncCheezy;18703]resurrecting a dead thread…

any of you guys use this?[/QUOTE]

I use a mix of PEP 8 and the Google Python Style Guide. The google guide has some really cool suggestions for things like formatting docstrings and other housekeeping type things that I really like.

#25

What in PEP-8 are you not fond of, Theo? The only thing I break with any regularity is the 80 character line limit (though I try to stick to that generally), and even then I always keep it under 100.

#26

I’m not fond of the irregular use of casing, mostly – i find that I always need to stop and think about it when you run into things like modules that expose a single classs. Using single_underscore for both methods and fields is also a bit irritating, since most fields are not multi-word names so they tend to fade into the background noise of the scripts ( especially if they get initialized in the init)

#27

What do you mean by the irregular use of casing? Like capitalization or something different?

Somewhat tangentially, we don’t have any full-time developers here and it’s hard to get people to stick to the same conventions. I just want some consistency :frowning: Especially when people break style while editing an existing script.

#28

Oh, I just feel like

[QUOTE]
b (single lowercase letter)
B (single uppercase letter)
lowercase
lower_case_with_underscores
UPPERCASE
UPPER_CASE_WITH_UNDERSCORES
CapitalizedWords (or CapWords, or CamelCase – so named because of the bumpy look of its letters [3]). This is also sometimes known as StudlyCaps.
mixedCase (differs from CapitalizedWords by initial lowercase character!)
Capitalized_Words_With_Underscores (ugly!)

[QUOTE]

is overloading too much subtety onto mere typography, especially when it’s distinctions like between CamelCalse and mixedCase. It’s not obvious to noobs, and then the noobs mess it up and it’s no longer obvious to oldster’s either.

I have never tried using the Pep8 module – has anyone here used it? Is it helpful or just nitpicky?

#29

Am using PyLint along with the built in code style checker in Aptana (PyDev). I really like it. It gives direct feedback on a per-line basis and allows autofixing a lot of formatting (as in spaces around operators, commas etc etc etc).

#30

I think it helps that everyone uses the same style, if your a single programmer, might not be worth it, but for huge libraries and multiple programmers, you can spend a lot of time reading code and I think it makes reading others code easier. I actually hate a few things about pep8, such as the underscores, because I think it looks ugly, but after a week of it, I’m getting used to it. also, the 80 line limit kinda kills me, I normally hit the 100 chars per line.

#31

We can say one thing for sure; noone follows pep8 verbatim, we all have our styles and preferences :slight_smile: