On 2012/04/14 19:12:01, Keith wrote:
Splitting the function in two doesn't make it any easier for me to
understand,
but I had figured it out before.
On 2012/03/21 18:56:08, Milimetr88 wrote: > What I was taught at the university is to write short > and simple functions that do only one thing.
We don't have a short and simple task. A function defines boundaries. It has well-defined input, processes the input using local algorithms and temporary data, and generates well-defined output. Splitting the function into two parts does not make sense since the first part has no well-defined output that can be considered reasonably independent from the requirements and workings of the algorithms in the second part. When you are redesigning the second part, you'll need to redefine the "interface" between the two parts and the first part as well. Whether or not you put an artificial function call boundary in the middle of the function, it is not composed of modular parts that could be reused in different contexts. Modularity is not a self-serving goal. In university, you will often train using toy problems in order to get anything finished at all. So one tends to overmodularize, independent of any actual reuse of functions (the toy problems usually are small enough that reuse is not an actual issue even where a subtask _could_ be sensibly modularized). http://codereview.appspot.com/5975054/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
