[Geany-devel] Short function factoring

[Lex Trotman]

On Fri, Nov 11, 2011 at 3:59 AM, Nick Treleaven
<nick.treleaven at btinternet.com> wrote:
> On 08/11/2011 21:21, Lex Trotman wrote:
>>
>> On Wed, Nov 9, 2011 at 3:40 AM, Nick Treleaven
>> <nick.treleaven at btinternet.com>  wrote:
>>>
>>> On 04/11/2011 00:21, Lex Trotman wrote:
>>>>
>>> * long functions cause bugs
>>
>> Rubbish, wrong functions cause bugs no matter how long, and being
>> unable to see the whole logic leads to wrong design.
>
> Long simple functions are Ok. Obscuring the logic is obviously bad.
> Sub-functions should be near the function that uses it if the sub-function
> is only used once.
>

Agree with that, but just note that breaking out a sub-function should
only happen if it is a logically separate operation.  Breaking out
something that is purely a part of a bigger operation just hides
logic.  For example if you can describe "this function furgles the
foobar" then it *may* be a candidate for separation, but "this
function does part of furgling the foobar" should not be considered
separable.  This applies to code re-use too, just because two things
have substantially the same code, don't share a function unless it has
a sensible describable purpose.

>>> * too many variables in one place cause bugs
>>
>> Thats what declarations in inner blocks are for :)
>
> That helps a bit, but the more things you have to keep track of the more
> likely you'll forget to initialize a variable that needs it or forget to
> free memory or other bugs.

Agree, initialisation should be in declarations or immediately after
if thats not possible.

>
>>> I'm sure there are statisics to back this up, it's well known in code
>>> analysis/reliability circles.
>>
>> And there are also statistics that say the opposite, that breaking it
>> up too far over complicates things and causes unreliability.
>
> Agree, I should have included some numbers in my points. It depends on
> context, but I would say a function longer than 15 lines may be too long.
> More than about 7 variables can get hard to keep track of everything.

We are both looking for the same result, more understandable and
maintainable code.

But these specifics is where we disagree :)

Much of my experience is in the defence/aerospace sector which is
mildly interested in reliability.

The coding standards used in this area tend not to be public, but a
typical one that is available is the Joint Strike Fighter Air Vehicle
coding rules http://www.research.att.com/~bs/JSF-AV-rules.pdf.  This
is for a system with rather more important reliability needs than
Geany.

Whilst this is for C++, the general parts are applicable to C, in
particular code size and complexity (3.2).  Note that it separates the
size from the complexity.

The size limit 200 logical SLOC is somewhat at the upper end of those
I have seen, but 50 to 200 is the sort of range, and this is not
required to be verified.

More important is the complexity, and this is required to be verified.
 This standard uses cyclomatic complexity as its measure, see Appendix
A, but which measure is irrelevant.

The point is that the example in Appendix A is way under the
complexity limits allowed, but I suspect would fail the Nick test as
you outlined it here :)

I believe that your recommendations (for the best of motives) err
dangerously on the too small side and would tend to decrease
maintainability and reliability.

But as I said in the beginning YMMV :)

So long as we talk about it when we think it is a problem, and don't
go unilaterally modifying code just to change this, it will be ok.

Cheers
Lex