[Tutor] How (not!) lengthy should functions be?

[Mark Lawrence]

On 16/04/2015 17:47, boB Stepp wrote:
> As I go through my current coding project(s) I find myself breaking
> functions down into other functions, especially when I see see
> (unnecessarily) duplicated code fragments. I understand this to be
> regarded as good practice. However, I am wondering if I am carrying
> things too far? For instance I have a collection of functions that do
> simple units conversions such as:
>
> def percent2Gy(dose_percent, target_dose_cGy):
>     """
>     Convert a dose given as a percent of target dose into Gy (Gray).
>     """
>     dose_Gy = cGy2Gy((dose_percent / 100.0) * target_dose_cGy)
>     return dose_Gy

Slight aside, I'd not bother with the dose_Gy, simply:-

return cGy2Gy((dose_percent / 100.0) * target_dose_cGy)

but see also my comment at the end about aliases.

>
> This function calls another units conversion function, cGy2Gy(), in
> doing its work. Generally speaking, I have units conversions functions
> for every conversion I currently need to do plus some that I am not
> using yet because I can easily see the need for them in the future.
>
> My current understanding of function length best practice is that: 1)
> Each function should have preferably ONE clearly defined purpose. 2) I
> have seen varying recommendations as to number of lines of code per
> function, but I have seem multiple recommendations that a function
> generally should fit into one screen on one's monitor. Of course, some
> people have HUGE monitors! And I assume that any guidance applies
> equally well to methods.
>
> Am I on-track or am I getting carried away?
>

I'd say pretty much spot on, especially if you take Alan's advice and 
use aliases instead of the one line functions.  I can only assume that 
you've seen this quote "Always code as if the person who ends up 
maintaining your code is a violent psychopath who knows where you live."

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence