>>>In my book, the less code... the less errors, the less problems reading the code thus the less problems in resolving errors.
>>>
>>>Which book did you write? I would love to get a copy :)
>>
>>You first have to read Dutch :)
>>Its really simple. A 20 line routine can contain less errors than a 100 line piece of code. It can be written, read, analyzed and corrected faster.
>>
>>Seriously, Code Complete written by Steve McConnel would be a good book to start with. Especially the chapters that deal with the code itself (rather than architecture and the process of development), leave clear hints about length of code.
>>
>>Walter,
>
>A yes and no.
>
>As stated earlier in this thread. 100 lines of simple code could be much easier to maintain then 10 lines of rather complex stuff.
>
>A line coud be very tricky :)
>
>To the example this all starts with. If you do all in C and just call it from from VFP. You have two lines VFP. Is this easier to maintan? Only if there is no problem in the C code ....
>
>:)

As I stated readability goes first. If its too complex to read, then you have to make it readable at the expense of writing more code.

As for your C example. I'd assume we all start from a universal common command set.. thus whatever VFP and perhaps FoxTools provides us and has been proven to be "bug-free".

VFP has a rich set of powerfull functions and commands, so its wise to use them to reduce code complexity. Commands like SQL - SELECT, Calculate, the array functions, string functions, could all be used to reduce the amount of code in your (and even my) projects if one just takes the time to make it simple.

In each and every medium to large projects you can easily identify routines that were written quick and dirty that really need refactoring. More often than not the refactoring will result in cleaner, but also shorter and more efficient code with less hidden bugs.

Deep nested IF ELSE structures are difficult to read and most of the time can be made a lot more maintainable in DO CASE structures.

20 years ago, I constructed my SQL statements with literals + IIF() over several lines, until I discovered TEXT ENDTEXT with TEXMERGE. I read lines into arrays manually until I discovered ALINES(). I did use

IF USED("Orders")
   SELECT orders
   USE
ENDIF

In stead of

USE IN SELECT("Orders")

I guess, I'm trying to say. Avoid tedious low-level programming, as you write much more code than necessary, more complex, with a lot more potential for bugs and other problems. Use high level commands as much as possible as they eliminate much of that work.

Walter,