how many lines per function

[Rudi Hammad]

Hello again,

I am trying to improve my coding, to make clean and easy for others to read as I posted in other threads.

This time I wonder about how many lines per function/method I shoud do. I read that recently on stack overflow

It's not about lines of code. As Steve Mcconnel and Bob Martin say (two pretty good references on coding best practices), 

a method should do one thing and only one thing. However many lines of code it takes to do that one thing is how many lines it should have. 

If that "one thing" can be broken into smaller things, each of those should have a method.

Good clues your method is doing more than one thing:

• -->More than one level of indention in a method (indicates too many logic branches to only be doing one thing)
• -->"Paragraph Breaks" - whitespace between logical groups of code indicate the method is doing more than one thing

Just to name a few. Bob Martin also says to keep it around 10. Personally I usually try to shoot for 10. If it starts getting close to 20

Really 10 or 20?

I just wrote a method with 80 lines... I can´t post it because it from work, but what this method does basically is navigate through a treewidget, and depending

on the kind of item below or above, it compares that item to the selected one, and as a result it will behave diferently. But anyway, generally speaking,

do try to keep you methods around 10/20 lines, I find it hard to do.

Also, I recently studied at rigging dojo a C++ course, and the tutor, Marco Giodiano who in my opinion is amazing, did quite long functions I believe.

Is C++ another world from Python regarding all this conventions?

thanks

R

[Marcus Ottosson]

Putting a number on something as abstract as this is hard.

How about we make it into a fun little exercise, why don't you post a long function or method, and we'll see whether it can be shortened and if doing so makes any sense.

Odds are you'll find that the number of lines you chose is what's right for the circumstance, and that splitting it up comes with a greater cost than keeping it together. On the other hand, maybe there really is value to splitting it and if so you might find it interesting to see what others can come up with.

[Rudi Hammad]

Ok, I´ll try to find some function that is relatively long and post it to see how different people deal with it.

[zeth willie]

I actually made a video about refactoring python for maya basics a little while ago where I talk about some of that exact stuff! Never got around to uploading it, I'll do that soon, maybe there will be something helpful in it (depending on your coding prowess). 

To echo Marcus, it's hard to be really specific, but once you have a little bit of an eye for it, it can become more clear what the threshold is for extracting stuff. The example I think I used was: say you're codifying your day and you have a function called "waking up". It may seem totally reasonable to put all the steps for making and drinking coffee in that "waking up" function. Related process and you do it almost every morning. But what happens if you want to make a cup of coffee after dinner? It's not "wrong" to include coffee-making in the wake-up function, but it can be objectively better to extract it into its own function so that you can use it later in a different way or in a different script. Turns out it's easier to inspect, test and revise later also. 

I LOVE Marco's work, his tutorials and all that are awesome. So I don't want to sound like I'm contradicting what he did. But it's also often the case that when writing something, one can't be bothered to break everything up into the most perfectly efficient chunks. That's why there's a word for refactoring:) Sometimes you have to see how things work in the wild and how other might use it. Overthinking this stuff can lead to wasting time by designing for use-cases that never happen. . . again, that's why we refactor.

In the case you mention, it might be worth looking into ways to dissect the comparison and filtering process, maybe the traversal process too. Loads of levels of indents, etc can indicate that maybe you're trying to do too much in one method or function and some of that sorting can be broken out.  

Hope that helps!

[Rudi Hammad]

Hi Zeth,
I am trying to look for a long function I wrote to post it, but I am realizing that I only get this long functions when it comes to UI programming. And I can´t find an example to post that is not work confidential.
It is like the example you said.So I guess that with more experience you start to see better how to organize your code in a logical way.
And yes, I guess that when Marco is improvising the tutorials, he doesn´t have time to organize it perfectly.

[Andres Weber]

Just to add onto this topic: you'll find that many ways that you're thinking about doing things have been codified already into design patterns that might be more effective or efficient at getting the job done while maximizing reusable code that isn't brittle or hard to recycle/monolithic.

It might be worth checking out the book: Head First: Design Patterns.  It's not written in Python but the ideas are very easily abstracted...I'm not sure about a Python specific one that I've read first hand, however I'm sure someone else can give a good suggestion.  This might get you out of the habit of possibly making too monolithic code and help you start abstracting.  I'm just assuming you might find that certain patterns pop up throughout your code and could hopefully lead to refactoring that can minimize the code.

However if you're talking UI code...I haven't personally figured out many ways to minimize that code in a few scenarios. Sometimes it's not a great use of your time as I see many people prototyping/finalizing UI's in qt designer and leaving the files as is instead of trying to find a way to minimize the lines within (which if you've seen are seriously monolithic), but who knows...I'm assuming that's a pretty debatable one.

[Michael Boon]

I think it's important to note that Python is a scripting language. A lot of the time when you're "scripting", you're writing a function that does a series of different, one-off things. If you try to break it up into reusable components you might make everything far more complicated. Creating a UI is often a good example of this.

I don't want to discourage you from making short, reusable functions in general, but just point out that it's not always the right thing to do.

Making your code readable and easy to debug, on the other hand, is always important! If splitting your code up makes it more readable, testable or easily debugged, then go for it.

[Michael Boon]

Sorry Andres, I basically just repeated what you said :)

[colas]

Hi,

There is some automatic tools to check the code complexity.

http://radon.readthedocs.io/en/latest/

At work we are trying to keep the cyclomatic complexity under 11.

Cheers,

Colas