justamistere
Programmer
Simetimes I have up to 8 screenfulls of code between the WITH THISFORM... ...ENDWITH. Is this common among any other programmers? Is there a penalty in speed or anything not good about coding that way.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How much code between WITH..ENDWITH
- Thread starter justamistere
- Start date
- Status
IMO, it's too much from a code management/maintenance point of view. A method should one thing and only one thing. You should look into refactoring the code.
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
In general this is not a good idea...anything that takes up that much room should have some redundancy that can be put into sub-routines. I have taken over legacy apps where the original programmer has 2000 lines of code between and IF..ENDIF statement. Gets really hard to follow, especially if there are nested IF's.
Mike Pastore
Hats off to (Roy) Harper
Mike Pastore
Hats off to (Roy) Harper
craigsboyd
IS-IT--Management
I have not seen the code, your screen resolution, or the font size you use in the VFP IDE. That having been said, I would still say that I agree with the statements made by craigber and mpastore. Craig makes a very good point about a single method/procedure/function per task. I follow this as much as possible and it saves me many headaches and much time in the long run. Yes, there are still times when I am in a rush to get something out that I just forego this rule, but for the most part I am better off if I follow it.
As to your With Endwith, the code will not necessarily run any faster if you refactor it. you may find that it in fact runs a little slower (most likely talking nanoseconds here). So there is no performance hit. However, in refactoring it you may find a number of ways that the code can be optomized as you notice the patterns/tasks of each part.
Also, given that the With Endwith of which you speak seems to be dealing with the form you may consider moving a good deal of it to Form Methods. Here again, you won't necessarily see any performance increase, but you will have a much higher level of organization and be more inline with the standards of OOP.
Slighthaze = NULL
craig1442@mchsi.com
As to your With Endwith, the code will not necessarily run any faster if you refactor it. you may find that it in fact runs a little slower (most likely talking nanoseconds here). So there is no performance hit. However, in refactoring it you may find a number of ways that the code can be optomized as you notice the patterns/tasks of each part.
Also, given that the With Endwith of which you speak seems to be dealing with the form you may consider moving a good deal of it to Form Methods. Here again, you won't necessarily see any performance increase, but you will have a much higher level of organization and be more inline with the standards of OOP.
Slighthaze = NULL
craig1442@mchsi.com
"Whom computers would destroy, they must first drive mad." - Anon
If I had 8 screenfuls of code with a lot of THISFORM's in it I'd certainly sandwich it between WITH... ...ENDWITH.
That being said, I think what everyone's picking up on here is that such an amount of code could very likely be made simpler and easier to read by being broken into smaller segments.
Jim
That being said, I think what everyone's picking up on here is that such an amount of code could very likely be made simpler and easier to read by being broken into smaller segments.
Jim
- Thread starter
- #6
justamistere
Programmer
I suppose from the interpreter's standpoint there could be as many lines of code between the "WITH... ...ENDWITH" as I have seen in html tags like "<html>... ...</html>".
The 8 screenfuls, the biggest I have, was just a quick-n-dirty set of CASE statements processing six different report choices with selection criteria. Yes, I could just put just the "DO CASE..." navigator on the Button.Click event and have each call a _Report_nn form method.
Thanks for the suggestions. I am well aware of making my programming modules granular as possible, always keeping in mind the "Golden Rules" of programming. (a good topic for an FAQ)
In creating .scx forms I always code with the style in mind that some of these Forms can and will be turned into reusable classes.
The 8 screenfuls, the biggest I have, was just a quick-n-dirty set of CASE statements processing six different report choices with selection criteria. Yes, I could just put just the "DO CASE..." navigator on the Button.Click event and have each call a _Report_nn form method.
Thanks for the suggestions. I am well aware of making my programming modules granular as possible, always keeping in mind the "Golden Rules" of programming. (a good topic for an FAQ)
In creating .scx forms I always code with the style in mind that some of these Forms can and will be turned into reusable classes.
Since you brought up "Golden Rules" of programming...The button click is probably not the proper place for the CASE statement either. How to process a report is not the job of the button.
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
- Thread starter
- #8
justamistere
Programmer
Okay, I put my foot in my mouth this time. This is not my usual practice, no excuse. Usually I call Form Methods and continue or abort processing based on returned values. Then I display via messagbox(), the results to the user.
I have some systems where even messaging is "centrally" located or channelled through a class-object, and sometimes database-driven.
I hope not to veer too far off the subject of this thread. Please let me know what you think should only happen in a command1.Click Event, Thanks.
I have some systems where even messaging is "centrally" located or channelled through a class-object, and sometimes database-driven.
I hope not to veer too far off the subject of this thread. Please let me know what you think should only happen in a command1.Click Event, Thanks.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question