General Coding Opinions

[KDavie]

First off, I would like to say that I am extremely grateful for all of those who contribute to this forum. I have been programming in VFP for about a year now and would not have the skillset I have today if not for all the helpful people in this community; so thank you all.

As I mentioned before, I have been working with VFP for about a year now. Having only worked with MS Access and VBA prior to VFP, my programming experience was very minimal. So basically, not only have I been learning the VFP language but I have also been learning how to program.

I've been working on the same application for the past year. Quit often I find better ways of doing things than I knew of when I first started, so I find myself going back and changing a lot of code around. Which brings me to my question; it seems to me now to be easier to write a .prg with numerous functions for every form and to call them from the methods and events of the form rather than coding in the form itself. Is this good practice? Also, can anyone recommend a good book or tutorial that will help me better understand programming theory, or do you think brushing up on OOP will provide the necessary foundation to build from?

Thanks again for your help.

-Kevin

 

[Mike Gagnon]

Your next logical step to follow the OOP way, is rather that creating a .prg to hold your functions, is to create a custom class that will hold you functions, and instanciate it at the beginning of the load of your program. At least that is the technique I use.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[KDavie]

Mike,

I'm not sure I understand. Are you saying you create a custom class for each form and write the code in the respective event or method of the custom class? If so, what is the benefit of doing that over just coding the form itself? (If this reads facetiously, it's not meant to.)


Thanks,

-Kevin

 

[jimstarr]

Hi Kevin,

One of the main disadvantages of using a .prg is that it's more difficult to reference objects on the calling form. Also, you can't use convenient syntax such as THIS, THISFORM, etc.

I'm sure Mike wasn't suggesting that you create a custom class for each form, but rather have just one for the entire application. I like and use this approach too, but only for methods which are used by more than one form. For methods used only by one form I personally prefer to embed them in the form itself.

Jim

 

[bobmpalmer]

I prefer to collect common code as functions in a set of PROCEDURE Prg's which I can then use in various projects.
You only write common stuff once.
you issue
SET PROCEDURE TO formprocs, generalprocs, menuprocs, etc in yr main prg.

I, like Jim, only embed in a form, specific code for that form or processes that are peculiar to that form.

Everyone to there own, hope it helps.



Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Mike Gagnon]

KDavie

I'm not sure I understand. Are you saying you create a custom class for each form and write the code in the respective event or method of the custom class?

First off, the use of a prg to store yoir procedures is "old style" progamming and does not "follow" the object oriented way of doing thing since a prg is not an object, but a class can be. My suggestion is that you create a custom class in you main library (if you have one) and create in this custom class all the methods you would use during a session.
I can only show you by code in this type of website setting, but lets take TABLEUPDATE() for example. If you are using table buffering in your application, you will need to issue a tableupdate() everytime you need to save a record. So you can write a global function that you will re-use everytime (OOP), the only parameter you need is the table name. So this is only a coded example:

DEFINE CLASS myfunctions AS custom
	Name = "myfunctions"
	PROCEDURE updatetable
		LPARAMETERS lcTable
		lRetVal = TABLEUPDATE(.t.,.t.,lcTable)
		RETURN lRetVal
	ENDPROC
ENDDEFINE

Now you have created a custom class that could handle all your tableupdates. All you have to do is instanciate it in you main program, and the function will but available all the time.

PUBLIC oGlobalClass
       IF !"ALLMYFUNCTION.VCX" $ SET("CLASSLIB")
            SET CLASSLIB TO  ALLMYFUNCTION.VCX ADDITIVE
        ENDIF
        oGlobalClass = createobject("myfunctions")

This custom class will stay usable all throughout you session and in this case all you have to do to save a record is.

oGlobalclass.upDatetable('myTable')

The concept is difficult to explain in writing, but once you understand it, you'll never look back. For one, it is much easier to maintain the code, since all functions are separated.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[MarciaAkins]

Hello Kevin.

can anyone recommend a good book or tutorial that will help me better understand programming theory

With respect to VFP, one of the best introductory books that I have ever seen is Fundamentals: Building Visual Studio Applications on a Visual FoxPro 6.0 Foundation. Check it out at

http://www.hentzenwerke.com/catalog/fund6.htm

As far as OOP principles go, this one is one of the best:

Object Orientation in Visual FoxPro
by Savannah Brentnall






Marcia G. Akins

http://www.TightlineComputers.com

 

[bobmpalmer]

Mike

I'm intrigued to know other than -
<<"old style" progamming and does not "follow" the object oriented way of doing things>> What advantages has a class over a prg PROCEDURE file. Being that the individual functions and methods in a proc file are organised the same way.
Is there some memory advantage or perhaps speed of implimentation?

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Mike Gagnon]

bobmpalmer

What advantages has a class over a prg PROCEDURE file. Being that the individual functions and methods in a proc file are organised the same way.

None really any, other than a prg is limited in size, and when it comes to OOP if you are programmer that is hired to work on a team and the other members work in a OOP fashion and you write procedures in a prg and you write your reports using @1,1 say... just because you can't grasp the OOP concept, thank MS for maintaining the backwards compatibily (which might be a disadvange for this very reason).


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[baltman]

None really any, other than a prg is limited in size

Mike,

Not true (other than perhaps a 2 gig limit). A procedure is limited to 64K in size, but a prg file is not limited as to how many procedures it can hold.

Brian

 

[Mike Gagnon]

Brian

Not true (other than perhaps a 2 gig limit). A procedure is limited to 64K in size, but a prg file is not limited as to how many procedures it can hold.

I will not debate this issue as I cannot duplicate a situation that happen to me a few years ago, where I too had procedures stored in a prg and it was maybe the version of VFP (VFP3 I believe), I don't know, but I was unable to compile the prg, VFP threw an error, something about prg contained too may lines. But as I said it happenned once and I can no longer recreate the instance.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[bobmpalmer]

thank MS for maintaining the backwards compatibily (which might be a disadvange for this very reason).

And would have involved some VERY expensive re-writes if they had'nt!

just because you can't grasp the OOP concept

just because I asked the question does'nt mean I don't understand the concept, I was genuinely interested in any advantages it offered. I personaly use Class objects for global controls such as user permissions, form management, toolbar management etc but a general procedure file for udf's and the like that are called by more than one form.

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Mike Gagnon]

just because I asked the question does'nt mean I don't understand the concept,

Sorry, I didn't mean YOU, but a more general "them". I have seen over the years many programmers defending an "older techniques", because they have not taking the time to understand newer one or call it "fad programming". XML seems to also fall into that category as well.

but a general procedure file for udf's

That is a programming style, rather than having an advantage, I would think. I would question why you have so neatly "classified" all your other functions and choose to leave general procedure in a prg.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[GriffMG]

Hi all,

Here's my pennyworth...

The really nice thing about VFP is you, the programmer, get to choose whether and how much you use OOP or continue as you are.

I have the luxury of not working in a team, generally, and I don't use OOP or classes (except for the built-in ones) and generally just store all my UDFs in a single .prg file.

I've not come across the limitations that Mike mentions, but do remember reading something on them once... probably VFP 3?

Where I have to access form info, in a UDF, I either pass a reference to it in the UDF parameters or take the value(s) of the object(s) and pass that/them to the UDF instead (choice depends on number/complexity).

I have an IDEA, and I can't verify it at all (because I've never done a comparision) that the OOP route would result in a bigger final executable - but that could easily be wrong.

I firmly believe that the 'trick' to successful, maintainable, code in applications is to use sensible naming conventions, have one entry (no choice) and one exit point from all functions and procedures (your choice), don't jump around like the 'goto spaggetti' of yesteryear, maintain a change log in your systems, try not to write anything longer than a couple of pages - most things can be broken down into sub-sections - and most of all make the INTENT of your code clear, you might be looking at it again in ten years!

Comments are the main rub in all this, they help if they're done well and maintained, they don't if they're not. I keep mine to a minimum - just to make intent clear usually - because VFP is not a 'write-only' language like some (to me anyway - I'm thinging of perl! which is way to cryptic for me to warm to, although I do work in it!) and if it's well written almost anyone should be able to read it.

So, what I'm saying is that the choice is yours, there is no penalty in working OOP or not OOP if you program well - but neither will help if you don't program for the future!

Martin



Regards

Griff
Keep [Smile]ing

 

[bobmpalmer]

I have to admit to laziness Mike. The generalprocs in our system have not changed much, though added too, since our first release in 1992 (Mainly because the functions do the job and if it aint broke etc) When we moved to VFP, like many soneage coders, we retrained and learnt the new craft built a whole new fromt end, hence the neatly classified bits, but then concentrated our time on developing the product with new features and left what we believed were less important areas that "worked" Hence the reason for asking the question was there any advantage, meaning performance related rather than anything else. Many thanks for your response.

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[KDavie]

Thanks everyone for all your input!

GriffMG,

try not to write anything longer than a couple of pages

This is something I've often wondered about. I have a .prg linked to a textbox on the form. The textbox allows the user to enter an option from the menu (1-30). Also, the textbox allows for quick navigation to other objects ("/1"-"/20"). I copied the .prg to a word doc and with all functions and it's over 60 pages long. Although there doesn't seem to be any hiccups when running the .exe, I've always wondered if this was overkill for one .prg

-Kevin

 

[GriffMG]

Its not overkill by any means, my comment was directed at trying to make code look like pseudo code - if you follow me.

By breaking code into individual functions you are doing exactly what I was describing.

Most of the time code can be as long as you like, from a programming or performance perspective it is ALMOST irrelevent.

BUT, look at a piece of code you (or someone else) wrote two or five years ago - with a view of maintaining it - and if each segment is a page or two long, it's much easier to follow the intent. Try following a loop full of case statements and IFs and breaks that covers twenty pages of 8pt when printed out and you'll know exactly what I mean!

Sixty pages full of 30 functions is no problem, 1 sixty page function would probably be hard to maintain...

HTH



Regards

Griff
Keep [Smile]ing

 

[KDavie]

Griff,

Ah, I see what you mean now. Thanks for the information, both posts were helpful.

-Kevin