All
We are in teh process of wanting to implement naming standards and other standards in general to custom report/script/etc creation. Does anyone have standards implemented that they'd be willing to share. Thanks a bunch. You can send any info to mmrobinette@yahoo.com or reply. Thanks.
System Codes
Accepted standards are to create your own system codes for custom reports - always being aware that Lawson MAY someday use those codes for their own purposes. System codes starting with X, Y & Z are presumed safe.
Indexes
When creating your own indexes on Lawson tables DO NOT name then with SET, although some have taken to starting the naming at SET99 and working backwards for custom indexes I prefer IDX instead.
Scripts
1. Give them short, functional names and store them somewhere in your path OUTSIDE the Lawson directories. That way they can be called by other environments as well without having to maintain separate copies for every environment.
2. Always code using the acknowledged Lawson variables, LAWDIR, GENDIR, etc.. Avoid hardcoding paths and IP addresses like the plague.
3. COMMENT your scripts to the point it seems excessive. Trust me, when you come back to look at it 2 years from now you will have NO MEMORY of what you were thinking when you wrote it.
I've taken a slighly different approach in the work in the past. I have used Lawson's system codes as-is in most cases. The exception would be if I was truly writing a new module. Within these system codes I use a new program prefix starting with a new netter. X, Y, and Z are common, although to me "X" denotes temporary, so I tend to stay away from that. Currently, at "Mercury Companies" they use an "M" for most of our programs. Custom HR programs are MH or MR, BN programs are MB, etc. If you have a lot of suites you'll run into conflicts (e.g. AR and HR might have the same letters). It not really important what the prefixes are - just use a different one.
I end my indexes in "USR", so a custom index over the BENEFITS table would be BENUSR1.
I can not agree with Dave more about COMMENTING!!! When I had developers reporting to me in the past I used to tell them "Write your program comments so an english major could tell me what each piece of code does". While that may be excessive, there's good reason for it. As a relatively new guy I can not tell you how long I've spent just trying to understand what people in past did, much less making chantes to their programs. I thank myself for my own internal documentation each time I have to go back and work on a program thats more than about 6 weeks old.
Also - do NOT modify base lawson tables (other than adding an index). If you need to carry additional information that won't fit elsewhere, create a "sister table" that has the same primary index. There's trouble there related to keeping the records in sync, but I've found that's better than modifying tables due to Lawson's occasional update.
Finally, adopt a standard set of tools to use. In the past here we've had people write perl, TCL, .bat, 4GL, Crystal and C-Sharp. Over time a lot of different tools can build up and turn over will eventually result in loss of ability to maintain those pieces. (Not to mention the lack of documentation!) :)
Good luck!
I'll second and third the emphasis on comments. It's critically important.
My best story about how comments "saved the day" is the time we ran into a bug, I went into the code, and there right at the place where the problem occurred was a comment I had written, to this effect:
"This may cause a problem under the following conditions .." ".. but is not being fixed at this time."
(Even though the boss had said, don't bother fixing it because it's not broken, I had noted the potential for trouble.)