I'm going to be doing a presentation on ABL Best Practice Programming. Needless to say, I have my own ideas about what should be in such a presentation, but I would be interested in hearing, publicly or privately, what other people would include. I am sure that there is not a consensus on many points and I would like to acknowledge the diversity of opinion, even when I have my own preference.
Note that this is specific to programming, not DBA related issues.
tamhas wrote:
I'm going to be doing a presentation on ABL Best Practice Programming. Needless to say, I have my own ideas about what should be in such a presentation, but I would be interested in hearing, publicly or privately, what other people would include. I am sure that there is not a consensus on many points and I would like to acknowledge the diversity of opinion, even when I have my own preference.
Note that this is specific to programming, not DBA related issues.
What level are you looking for? Lines-of-code (eg always use ASSIGN, say) or design/architectural (eg follow the .NET event handler design with sender + EventArgs)?
-- peter
There is room for both. I'm not very interested in low level formatting standards except to note that it is good to have one. I am more interested in things which directly impact maintainability or quality. I expect some points to require a bit of elucidation and others to be just a quick list ... among the latter might be some common misconceptions, i.e., standards which we know are out there which shouldn't be.
This is a very large topic. Have you considered narrowing it? Even if you restricted yourself to something like API design, it would still be a substantial topic area.
It does not matter whther there is concensus. In fact if there were concensus you would be rehashing something everyone knows.
I know it is a large topic and I am unlikely to include everything. However, one of the things which I have been impressed by over the years is the degree to which many of the same issues come up one forums over and over and over again. Obviously, there is now a pool of people who know better who can respond to these issues, but just as clearly there is a seemingly inexhaustible pool of people who don't know better and who ask the questions or post code which shows that they don't understand. Could be, after I do a first version, I will expand it to more. Could be it will have to end up being a sort of whirlwind tour that does little more than make one aware of things one should look at more closely like my analysis talk.
Well I can certainly see value in a "Survey of 4GL Programming Best
Practices" that goes for beadth rather than depth.
I would surmise there's a plethoria of books on the topic for other languages, so it'd be a matter of finding them and cribbing the parts that apply to ABL code.
Not necessarily ... some, certainly, but there are also some things that are very ABLish.
Well, I would start with scoping. Transaction scope, record scope, variable scope, etc. In ABL you get away with sloppy programming on these subjects but does havoc to both performance and maintainability.
PS. Only now I see I'm rather late with this reply. Traffic on PSDN is rather low these days.
Not too late! Anyone should feel free to keep chiming in.
Out of curiousity, what's the advantage of forcing event handlers to take an EventArgs object over a progress.lang.object? If I remember correctly, EventArgs doesn't have anything useful in it.
If you use (or inherit from) System.EventArgs in your event signature the event shows up in the Visual Designer, if of course the event is part of a control.