Pattern-based development with Python

As some of you may know, Berlin et al have established some great work habits and style guides to make object-oriented programmers more efficient. I was fortunate enough to hear him live and ‘got it’. A good beginning resources is http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2001/2001_Bergin_CodingAtTheLowestLevel%20.pdf

My question is more related to Python, than to Blender Python, but, is it a good practice to write in the return statement to end a def? I know Python religiously enforces the indentation, so a return is not required for void return functions, but is for functions that return a value. So, we either want to include the return statement for functions for consistency and decoration, or want to omit it for brevity and discrimination between methods and functions.

Which should we do? example:

 def function():
    return (1)
def method():
i = function
method

see how, if you are not really paying attention, that the main program (beginning with i=function() gets rolled in to the text flow? any typing error and you could have

 def function():
    return (1)
def method():
 i = function
method

and bam! you have a logic error (just one space in front of the i, and python thinks that line is part of method(). In fact, I think I am going to return everything, so that python would throw an indentation exception if it was:

 def function():
    return (1)
def method():
    return
 i = function
method

Try code tags, they’ll help to get your point across better.

Also, methods are generally functions called on objects so for something like:


class MyClass:
    def __init__(self):
          return
    def myMethod(self):
          return

myMethod is a method of MyClass objects. init is the initializer method for MyClass objects.


def func():
     return

Is just a function, since its not associated with an object (at this level of the language).

I think you may have confused methods with void return types. Void returns still come from functions. A function can have no return statement and still be a function. Methods (sometimes called Member Functions as well) operate on objects in traditional OOP speak.

(Functions are in some ways objects. The equivalent of a function pointer in python is having some function defined as myFunc(a, b, c), then we can say callback = myFunc and later do callback(1, 2, 3) and have it execute myFunc).

In general I use return statements when they seem necessary and contribute to clarity or speed of the code like:


def early(a):
     for i in xrange(a):
          if some condition:
               return
         else:
               execute some code
     return

If it makes code seem cluttered or slow or I’m just writing some quick code, I won’t use them. Its a matter of what the situation calls for.

On another note, style (what most of that document is about, even some of the maintenance issues he brings up) is completely subjective. I’ve been asked to “identify bad style” on tests before and ultimately the questions are thrown out because they’re too subjective (since some things that some people do that are completely legal I would never do because they don’t make sense to me). While he does present good rules for the beginning programmer, you’ll learn more by reading code that already has good style and then writing programs that let you develop your own style (though Python does impose its syntax on your style to some extent).

I usually add them because that way I can write functions that dont do anything to block out the structure of code, then go and start writing the actual code.

and bam! you have a logic error (just one space in front of the i, and python thinks that line is part of method().

Only if you just use single spaces for indentation. I’d say use 2 at least, it’s hard not to notice being two spaces wrong.

sorry. yes I edited using the newly discovered code tags for the forum.