Names names names
In the musical Cats T.S. Elliot tells us that cats have three names. That's interesting to us because every Comet program also has three names: the name of the object file, the name of the source file that created the object file and the menu name. None of these three independent names have to be related in any way. There is no requirement that the source file name connect to the name of the object. And the menu name? The menu name can be anything and occasionally is!
Most of us Comet programmers realize that to stay sane we have to name source and object files with related names. Most of us. Sadly not all of us. And related is in the mind of the namer.
In the days of the "Q" machine files did not have extensions or directories. So we followed the pattern established by the Solutions package and appended a prefix to the name of the object creating two files with related names. Want to write a Customer Maintenance program? Call the object CM and the source =CM. No prob.
Then things got exciting. We had more than one account and more than one CM program. How, how to keep track of two (or three or four) variants of CM? And so came the company code prefix convention and the extremely ugly =CO-CM format for source files. Yuck.
And here I am working on a system with three, count 'em three, source files that could be the parent of the Order Entry system: each has OE as it's root file name and each has a different and less than descriptive company prefix.
Take a minute, stare at the ceiling and think about which menu your new program will appear on. Then chose a name that fits the menu and describes the program. And name the source carefully. You'll do yourself and your successors a big favor.
Most of us Comet programmers realize that to stay sane we have to name source and object files with related names. Most of us. Sadly not all of us. And related is in the mind of the namer.
In the days of the "Q" machine files did not have extensions or directories. So we followed the pattern established by the Solutions package and appended a prefix to the name of the object creating two files with related names. Want to write a Customer Maintenance program? Call the object CM and the source =CM. No prob.
Then things got exciting. We had more than one account and more than one CM program. How, how to keep track of two (or three or four) variants of CM? And so came the company code prefix convention and the extremely ugly =CO-CM format for source files. Yuck.
And here I am working on a system with three, count 'em three, source files that could be the parent of the Order Entry system: each has OE as it's root file name and each has a different and less than descriptive company prefix.
Take a minute, stare at the ceiling and think about which menu your new program will appear on. Then chose a name that fits the menu and describes the program. And name the source carefully. You'll do yourself and your successors a big favor.
posted by Steve Auerbach at
11:38 AM
0 Comments:
Post a Comment
<< Home