On: Reducing Code Nesting

[ceol]

>if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

A single if statement in a class method would put the indentation at 3, meaning if you have something like this...

    class MyClass(object):
        ...
        def my_method(self, param):
            try:
                self.calculate(param)
            except MyException:
                if param == 100:
                    ...
                else:
                    ...

you're screwed? I don't see how you can set such a definitive measure of bad code.

[jrockway → ceol]

Linux is written in C, so every "top-level" instruction is going to be one-level deep. In Python, the "top-level" is often the body of a method, which means it's two deep. So to apply Linus' advice to Python code, you can go four levels deep:

    class Foo(object):
        def my_method(self):
            try:
                if foo is bar:
                   self.quux()
            except:
                 pass

This seems acceptable to me. Factor out the try block if you want more conditionals and use polymorphism instead of conditionals. Rather than writing:

    class X(object):
        def quux(self):
            if self.foo is self.bar:
                self.quux_foo()
            else:
                self.quux_bar()

Write:

    class X(object):
       def quux(self):
           self.quux_bar()

    class FooIsBar(X):
        def quux(self):
            self.quux_foo()

No conditionals and your intent is encoded in your class hierarchy instead of inside some random method.

[ceol → jrockway]

Thanks for the thorough reply. I think his argument fits for C, but the linked article uses three different OO languages that would require a deeper "top-level", so I don't think it's fair to copy/paste his quote without any explanation or context.

[sumeeta → jrockway]

FooIsBar doesn't need to be a subclass of X, does it? The polymorphism comes from the interface (implements `quux`), so inheritance doesn't seem relevant.

Feel free to correct me if I'm wrong. Still trying to learn the difference between inheritance and "evil" inheritance :)

[jrockway → sumeeta]

Python doesn't have traits/roles, so it's hard to give a good example. You should build classes by composing them from smaller pieces of classes. There are two good ways to do this; delegation and role-based composition. Delegation is where you pass the constructor of your class an instance of another class, and your "foo" method becomes an alias to that instance's foo method. This allows you to do the same interfaces/roles as the object you're "wrapping", but still lets you customize the behavior of each method call you choose to delegate. (The Law of Demeter protects you from other callers touching the non-delegated methods.)

Roles let you implement pieces of classes without being a full class yourself. A classic example is a "Comparable" role, that requires the consumer to implement a "cmp" function, and then provides lt, gt, and eq implemented in terms of "cmp". You mix this into your class that does cmp, and now it gets lt, gt, and eq for free. You also get the security of knowing that you're calling the right method; duck typing will treat a tree's bark and a dog's bark as the same actions, while roles will let you determine whether you have an object with a wooden outer layer, or an object that can talk like a dog.

Python's philosophy doesn't seem to push delegation or composition, so we use inheritance in the above example to stick with Python programmer's expectations. Just beware of invoking the wrong type of bark; duck typing is flexible, but it ain't safe.