True, Mike.
Someone once likened DBase to a piano.
Because it's so accessible, Arthur Rubenstein could do magic with it playing Chopin, or some schlub like me could make your ears hurt with it


>Hmmm. You could do structured programming in dBASE but you could also violate it willy nilly. When you combine that with dBASE's accessibility, allowing someone not trained in software development to get something done with it, it's no wonder there was so much spaghetti code.
>
>>Actually, Viv, it's also us ex-COBOL'ers.
>>
>>Structured Programming came along during the 1970's when COBOL code was dominant.
>>In order to stem the flow of horrible code being produced, some savants got together and enunciated some principles under the heading of Structured Programming.
>>
>>Here's what Wikipedia says about it:
>>
>>"Structured programming is a programming paradigm aimed on improving the clarity, quality, and development time of a computer program by making extensive use of subroutines, block structures and for and while loops – in contrast to using simple tests and jumps such as the goto statement which could lead to "spaghetti code" which is both difficult to follow and to maintain."
>>
>>One of its basic tenets is that a module should have one entry point and one exit point.
>>That did wonders for the maintainability of COBOL and as an IT manager at the time it solved many problems for me, so I probably have a bit of an excessive attachment to it.
>>
>>The fact that DBase followed most of the rules of Structured Programming was one of its many appeals to me.
>>
>>
>>
>>
>>
>>>>Also agree about the exit point. You are using return as a way of breaking out of a process when you hit a certain point. Not a good idea. Much better to set variables at each stage ( if you are checking for bad conditions there may be more than one. Even in testing it would be good to find out about all of them on one pass)
>>>
>>>I must say that I find this 'one exit point' mantra seems to be confined to ex-VFPers :-}
>>>
>>>Here's what 'Code Complete' (which is pretty much language agnostic) has to say on the subject:
>>>
>>>"Use a return when it enchances readablility.
>>>In certain routines, once you know the answer, you want to return it to the calling routine immediately. If the routine is defined in such a way that it doesn't require any further cleanup once it detects an error, not returning immediately means that you have to write more code"
>>>
>>>The accompanying example has three return statements in a method with five lines of code...