Scilab Bag Of Tricks: The Scilab-2.5.x IAQ (Infrequently Asked Questions) | ||
---|---|---|
Prev | Chapter 3. Programming Style | Next |
There is a rule of thumb for the length of a C-function:
Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well. |
||
-- Linus Torvalds |
In older versions of sci-BOT the reader found the following paragraph:
It is also true for Scilab functions with the exception that high level functions, or functions that are called from the command line directly should be harnessed, see Section 5.1.5. Therefore, they are usually much longer than just two screenful. Yet, their structure decomposes quite naturally into two parts: the argument checking, and the computation. What remains true is that a Scilab function too should do only one thing and do that well.
Meanwhile, the authors have slightly changed their minds, opting for short functions throughout. All functions should be short, no matter how much argument checking is done. If the argument checking code bloats a function definition, the checking code must go into a separate function or even separate functions in the case the things checked are unrelated. We follow one of the prophets of concise programming, Martin Fowler, and recommend his book "Refactoring" [Refactoring:1999] . Of particular interest in connection with this section are the refactorings "Decompose Conditional" (238), "Consolidate Conditional Expression" (240), and "Replace Nested Conditional with Guard Clauses" (250).
For more information about programming style consult "The practice of programming" [Kernighan:1999] which is centered around C-like languages, but offers extremely valuable advice throughout. "Programming Perl", also known as "The Camel", [Wall:1996] has a section called "Efficiency" in chapter 8. It is as insightful as it is fun to read for the authors discuss the various optimization directions. They do not hesitate to put up contradictory suggestions along the different paths.
Conclusion of this section: Whatever makes the code's workings more obvious to the reader is good. In other words: "If it makes ya high, or saves you taxes, then – by any means – do it!"