>Hi Peter,
>
>>>I believe that procedures, methods and functions should be compact. If you end up writing methods of several hundred lines of code, you should seriously wonder if that is correct. I know this behavious is just an inheritance from the JSP times and widely used in clipper and foxbase programs, but this is really a bad habit.
>
>>Don't get me wrong, I propagate the writing of subroutines. However, there's no gain in writing a subroutine that's called only once, solely for the purpose of preventing long procedures/functions. I prefer one big 300-lines procedure with 4 40-lines functions over 100 small 10-lines functions. The latter kind of code I call macaroni code!
>
>I guess it really depends on the situation. However, I do want to propagate writing procedures for the sake of abstraction. If I need to calculate the number of working days between to dates and I only use it ones in my application, I'd still write a function because it abstracts the routine complexity of the algorithm and takes away the need in the calling program to comment what the GetNumberOfWorkingDays does do.
>
>BTW isn't it called spagethi code ?

Hi Walter,

(I try replying on another message you wrote, but I constantly get the error that the server cannot be found. Hopefully, this reply does reach you/UT.)

Nope, I call it macaroni code. Spaghetti is reserved for goto-code. We don't have such a command. Macaroni code is code that is characterized by a very large number of tiny functions. And each function/procedure is characterized by a lot of calls of other tiny functions. In the extreme:

DoAppend(.t.)
RETURN

FUNCTION DoAppend
   lparameter tlBlank
   if tlBlank
      DoAppendBlank()
   else
      append
   endif
   RETURN

FUNCTION DoAppendBlank
   append blank
   RETURN

Your example of a function that returns the number of working days is okay with me. As I said, I don't oppose the writing of routines at all. But I don't want people to exagerate. The programmer must always be able to tell the reason.