Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
GLGDW 2006 - April 21-24, Milwaukee
Message
From
12/01/2006 09:49:24
 
 
To
11/01/2006 12:14:32
General information
Forum:
Visual FoxPro
Category:
Conferences & events
Miscellaneous
Thread ID:
01078694
Message ID:
01086048
Views:
26
>It took some time, but I've come to learn in this business that "beauty is in the eye of the beholder" applies especially strongly when it comes to code and it is immediately ugly if it ain't written the way the current beholder does their code.
>Of course I prefer my own style too. But I am not going to re-write working code, and often business-critical, just because my style is different.

I'm not talking about style issues. I'm talking about things like using public variables all over the place, or repeating the same (or nearly the same) logic in many places, or code in one routine that makes changes to the environment and doesn't set things back, or code that has 6 different ways to do the same thing. In these situations, changing the code is horribly risky and I do my best to minimize the changes I need to make.

I have sometimes run into code that wasn't the way I would have done, but worked, was documented and was internally consistent. That code is a lot easier to work with, even if I have to get my head around someone else's style. In this case, I know that once I do, I can safely make changes without worrying about what else they will affect.

>Some people believe writing minimal code is "good code" and they take pride in writing on 1 line what I believe is clearer in even 5 or 10 lines.
>Some people hate (with a capital H) nesting of IFs simply because they can't stand the indenting. I don't worry about how much indenting is done.

I agree. These are style issues and they're not what I'm talking about.

>Some people (likely to keep their typing down) rely totally on VFP (for example) to do it's default behaviour and so save additional line by letting VFP do it for them. My preference is to (virtually) always code things like "ALL" after SCAN or "USE IN..." for tables/cursors regardless, SELECT after a CREATE CURSOR, etc. I use "m." where it should be used and some people detest that.

I disagree with your belt and suspenders approach here (not on m., but the other stuff), but I wouldn't change your code that did it.

Tamar
Previous
Reply
Map
View

Click here to load this message in the networking platform