On Fri, Nov 11, 2011 at 3:59 AM, Nick Treleaven nick.treleaven@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@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