What are the top VFP Nemesis

[jimoo]

I hope to make this a fun topic, but one we can learn from, and because of that, I am asking for this to be a no-star thread.

Here it is.

What is our top VFP Nemesis?

In other words, our top enemies of VFP programming, or things we should not do. Please keep the responses to only VFP programming.

INVALID RESPONSES
COBOL, DOT NET, MAC, LINUX, Etc. - They are not VFP Programming

Valid Responses:
- Hard coding Paths
- Use of .mem files
- Etc...

I can name 10 myself, but I don't just want my thoughts, but a group effort.

I'll start it out with my 1st, but it may not even make our group top 10 (or so) list. Again, a group reply.

My #1 is:
"Hard coded paths"

Also, if they are good - please let the person know that is a good one. A reply is sufficient.


If we have good success, I'll make this into a FAQ (credit the group) for the top 10 things to avoid.

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[OhioBill]

I tend to agree with almost everything that’s been written. Clearly the voice of experience has spoken!

Given that the vast majority of time is spent modifying and maintaining existing code, please keep in mind that the poor fellow who has to maintain your application may not be as smart as you are, or may not have your experience, or may be somewhat pressed for time. I would therefore request that a programmer:

Write code that is obvious and easy to understand. Whenever I encounter legacy code, the trouble spot is invariably the result of the author reading an article entitled “Obscure Optimization Routines, Revisited” by Enigma, then applying these half-baked techniques to the application in question. The routine works most of the time, but tends to go belly up during the new moon.

When you comment your code, write comments about WHY this code was written, not about what it’s doing. I can see what is going on, I can’t understand why it’s happening. How often have you found comments such as “SUM all the amounts to Var1”. I can see that’s what is happening, but I cannot for the life of me figure out WHY you’d want to do that in the middle of a save routine.

 

[Mike Lewis]

Slighthaze and Ramani,

ZAP and PACK

Good points from both of you. I don't seriously disagree with any of them.

I would argue that, regardless of the possible dangers, these commands don't constitute a nemesis, which is what we were originally talking about -- but the points are still worth airing.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[jimoo]

I tend to agree with Mike concerning zap and pack. I think we should be cautios using them in code, and only under certain conditions, but I wouldn't call them a nemisis.

I will take all the feedback from the group, plus my own thoughts, and post a top 10 list later this enening in this same thread.

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[rjean]

I'll cheat and just point to a wiki topic ;-)

http://fox.wikis.com/wc.dll?Wiki~VFPRookieMistakes~VFP

 

[craigsboyd]

CHEATER!!!!

Oh wait a minute, all I did was refer to what I had read in a book.

<contemplates whether he is a cheater too>

Slighthaze = NULL
[sub]craig1442@mchsi.com[/sub][sup]

&quot;Whom computers would destroy, they must first drive mad.&quot; - Anon​

[/sup]

 

[IRABYY]

Very interesting thread, colleagues!

I tend to agree with Mike Lewis:

&quot;- Lack of comments. I'm always amazed how many experienced programmers haven't twigged to the idea of commenting their code.

- Over-reliance on public variables (especially creating public variables on the fly at arbitrary points in the app).&quot;

I would also add

a) Implicit memory variables' declaration. While it's still passable in procedural programming, it absolutely must be abandoned in Visual/OOP programs. (My co-worker learnt it the hard way, even though I warned him.) All variables MUST be declared explicitly.

b) PRIVATE mem.vars. Those belong to classes in OOP, and should be abandoned in procedural modules.

The only excuse for not following the two above I can imagine is when using SCATTER - SELECT <alias> - GATHER or SCATTER - INSERT command against the tables of unknown structire (that's environment I am working in, but it might be only me). In all the other imaginable cases, I can see no reason of using PRIVATE at all in procedural programming: one can always make one's mem.var. or even array LOCAL, and pass it down to another procedure by reference should this mem.var. or array be modified by that called subroutine.

And the last one - which must be the first and foremost, actually - is the 2 GB file size limit! While all those that have been metioned before reference programming technique and, thus, is mendable, this one is THE REAL NEMESIS, imposed on us by that greedy little company in Redmont, WA. TGL (&quot;Two Gig Limit&quot might become the real killer (actually - murderer) of FoxPro as we know it. The only alternative we, the FoxPro-shniks have is to use VFP as a front end for manipulating the data stored on the Sequel Server. But, then, VB is better suited for GUI design than Fox. But that's probably the topic for another thread (and we've already had one, haven't we?)

That would be my opinion.


Regards,

Ilya

 

[rtatum]

My biggest fault/problem with any language was trying to code perfection in the first go round.

This comes from being young and being around &quot;seasoned&quot; programmers. All too often I find myself trying to &quot;clean-up&quot; code too much as I go along instead of making it work, then trying to clean it up later.

Of course that is not to say that you should be sloppy either!

 

[Mike Lewis]

Rjean,

That's a good article, but I'd argue that rookie mistakes are not necessarily the same as nemesis.

IRABYY,

Good points. My only (slight) disagreement is that PRIVATE does come in useful -- albeit very occasionally.

I've used it when calling a menu program from a method. I needed the menu to pick up a value from the calling method, but I didn't want to pass a parameter because that would have meant hand-modifying the MPR file, which would have prevented me re-using it in the designer. A PRIVATE variable was the only obvious way to handle that.

I've been in a similar situation with reports. I've needed a report to pick up a variable from the calling program, and, again, you can't pass parameters to a report.

But I agree that these are exceptional. You should certainly declare all your variables as LOCAL unless you have got a very good reason for doing otherwise.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[KoenPiller]

I agree with (almost) everything all your smartfoxes mentioned here. Please read also

http://www.web-hits.org/txt/codingunmaintainable.html

by Roedy Green

Koen

 

[Mike Lewis]

Keon,

That's a good article. Thanks for posting the reference.

I especially like the section entitled Creative Missspelling

Anyone who misspells misspelling is worth reading.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[csr]

Well, I will add my main nemesis ...

Not always agreed upon by my fellow compatriots but never-the-less it is my main one ...

Do not use database containers unless you have good reason. They create additional overhead and headaches which make previously simple processes exceptionally complicated. There is nothing wrong with an application comprised of free tables only.



Don

 

[jimoo]

Don,

I don't know if that will make my top 10 nemisis because there are times when they can be used.

However, I agree with you. Avoid them if at all possible. I also agree that we may be in the minority by making this statement.

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[craigsboyd]

csr and jimoo,

Well i dunno about you being in the minority or not, but I totally disagree with you. Far from making my work simpler, the absence of a DBC usually makes way more work for me. Not having access to rules, triggers, stored procedures, etc. is a pain in the you-know-what. I can't think of any reason why a developer would wish to avoid a DBC unless they were attempting to make something backward compatible with an earlier fox app (such as Foxpro 2.6a). I would list the DBC in my top ten list of greatest improvements to Visual Foxpro.

Slighthaze = NULL
[sub]craig1442@mchsi.com[/sub][sup]

&quot;Whom computers would destroy, they must first drive mad.&quot; - Anon​

[/sup]

 

[ramani]

Hi

I also feel the same way as slighthaze.

DBCs provide for the TRANSACTION PROCESSING is an important improvement. The triggers and such facilities are great.

I have added an indirect security to my tables, by calling triggers for update/add/edit while I kept the triggers themselves outside the DBC (not as stored procedures) so that, when any normal user opening the table directly from foxpro cannot modify (simply because the triggers are not available and kept in the exe). When I do, I set procedure to a file having the triggers and then do the handling which in anyway is rare for me. Though some of my writings are not 'nemesis', I am just sharing my experience and views with others.

The point is DBCs have come to stay as great improvements as Slighthaze said.


Sorry - Simply Dont Agree With Those Who Are Negative To It. :-(



____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

When you ask VFP questions, please add VFP version.

 

[csr]

I guess it may depend upon the types of applications you generally are building. A big part of my applications is the ease at which I can make modifications to the underlying data structures and tags. I can now simply enter the changes into a table I include with my application and the first time the application is executed everything is updated. It is a completely automated as a no-brainer for me. I cannot forget anything.

That was a big problem with DBCs for me.

I also do not wish to rely on 3rd party add-on libraries to get this sort of thing done. I have experienced the demise of several of these libraries in the past and do not wish to become attached to them.

If it isn't in VFP I don't use it.

I also use the KISS theory at every opportunity. Keep it simple ... I have found that DBCs add complication which can be a nightmare to resolve and I have seen several instances of that on this site. Programmer's at their wits end begging (pleading) for help. I don't need that.


Again, that is me ... I know many do not agree and that is fine. I just know I sleep at night with my methods and if things don't work, I can usually find out quickly what is wrong.



Don

 

[jimoo]

When I am the position of needing rules, triggers, etc. I usually recommend SQL server or mySQL. The problem I have with the database container is that it is, as we all know, a vfp table and can become corrupt, and I have been pimped with that happening in the past.

I have been lucky enough so far, that when SQL-Server is not an option, I have been able to design without the dbc.



Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[foxwizard]

Let me remind everydody that even SQL server or Oracle databases can crash too. We have experience that before. The reason is that when the air conditioning system was suddenly broke not knowingly, the server automatically shutdown when it reached the allowable temperature. At that time, the database was up. So it crash the database. Its a good thing we have the backup but it takes time before we restore them.

My point actually is , any database when not properly shutdown can possibly crash.

Bren
VFP - Philippines

 

[jimoo]

Crash yes, but I have never experienced a corrupt index in SQL-server and most sql-server gurus will tell you it almost never (actually they say never) occurs.

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[foxwizard]

When your database is crashed, you can never tell that all of your tables, indexes, triggers , and stored procedures are not corrupted and in good conditions. There are things that you cannot perform anymore in your database the way you used to when database is crashed. So how can you tell that they are working properly.

 

[Mike Lewis]

I agree with Slighthaze and others about DBCs. Yes, they present additional overhead and comlications, but they also bring benefits -- not least of which is the ability to use long field names.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk