This has always been a picky subject for me! Having had little or
no formal programming instruction, I had to learn for myself what works best
for myself and my needs. Looking at the code of others helped somewhat, but
in the end as they were not specifically doing the same as I, I ended up
having to change much of it anyway.
I've always taken exception to those who constantly preach about not
using global variables, goto's, and the like, just as a matter of principle
because if it solves a problem, works, and doesn't cause problems, who
should say that it is wrong to use simply because they don't like it, or
even if the method might actually be more prone to adding problems to one's
code. It's a matter of choice and whether or not you can ensure that it
works as wanted without causing problems!
While some might consider it truer to the foundations of OOP to
re-write code that a component already has just to separate it...which again
I believe is up to the programmer's personal choices...I try not to add
redundant code to a project for any reason. I believe that if the component
works as it should, then I should make use of it as its design allows. The
concept of separation is relative and can be employed in many different
ways, so I don't presume to tell another that his or her methods are wrong
either, just because they don't match my own!
Luckily though I don't have to worry much about coding for others,
so I can get away with a lot more than perhaps you or others can, but I
often wonder what it would be like and if I could fit my methods into a team
situation. It's an interesting topic.
from Robert Meek dba "Tangentals Design"
e-mail: [EMAIL PROTECTED]
Freelance Windows Programming for XP and Vista
Also proud to be a Moderator of the "Delphi-List" at elists.org
"Reality cannot be explained...only enjoyed or endured as your current
perspective allows!"
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of zayin
Sent: Monday, December 17, 2007 8:34 PM
To: 'Borland's Delphi Discussion List'
Subject: RE: Avoiding form loops?
Hi,
Some people code for code development speed or ability for others to read or
maintenance or ad infinitum.
With that, for me it depends. For example, I have and use all the time:
procedure AddItemsToTCheckListEdit(aCombo:TCheckListEdit; items:array of
string);
var
i:integer;
begin
for i:= low(items) to high(items) do
aCombo.items.Add(items[i]);
end;
That function is contained in a unit I maintain for this kind of stuff. This
unit only has functions.
Some people like to extract data manipulation code from the UI portion of
the code.
I hear of people who have main forms of 10,000+ lines. For me, I would have
taken a different approach to the data.
Some people code as if Delphi is procedure Pascal and not OOP.
As for the timers, it depends. I have one program with several DMs and they
each have two timers. The DM's do not know about each other and maintenance
or adding new features to one does not cause changes in the other.
In this program I also have a thread that runs but does not interface with
the main program. (It monitors a directory for printing.)
I hear people all the time rage against this or that programming practice. I
get a chuckle out of the NO GOTO EVER ON THE PAIN OF DEATH crowd.
I refrain from criticizing others coding practice. Short story; a company I
worked for sent the source code I wrote out to a third party for
"professional" evaluation. The program worked and had no known bugs. The
critique came back and one of the complaints was that I used only one space
between the left side and the start of the source text. HA! The only
compliant I found of value was that it did not have enough comments.
And after all that it comes back to -- it depends.
Just my2c.
Ciao,
Mark
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of [EMAIL PROTECTED]
Sent: Monday, December 17, 2007 4:59 AM
To: [email protected]
Subject: Avoiding form loops?
I have taken over some of my colleagues applications, as he has left.
Unfortunately, he and I obviously have not had the same ideas about writing
code.
I have found lots of procedures in sub-units that access components,
procedures and variables on/in the main form/unit directly.
So far all that has been removed by moving the variables and procedures to
either the unit in question or a new unit, Global.pas, used by all others.
Instead of accessing components directly, I now send messages to the main
form, and let that handle whatever was supposed to happen.
Also in one case, where two sub-units were talking to each others form.
At least compile time has now been reduced by something like a factor of 5.
But is the above 'structure' the propper way of doing it ?
Are there other ways, that are more efficient at run-time ?
Only one thread is in use, but loads of timer events etc.
_______________________________________________
Delphi mailing list -> [email protected]
http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
