Class naming conventions

this may not apply to the non-ABL OO world, but how do you name your

classes ?

"may not apply" ?

I'm having some "problems" when trying to use the USING statement and

refering to a static method in a class

This is a known issue, and exists largely because tables came before classes.

I tend to (or rather, try to) name my classes more descriptively than 'Customer'. That'd be the first place to look ... CustomerData[Transport]Object; CustomerModel; CustoemrCRUD ....

If it still persists, then I fully-qualify (which I sometime have to do anyway if I am calling static methods on a type that exists in multiple packages and I'm USING one of the alternates.

-- peter

I was putting suffixes on the end of mine because  the "class name can't match a table name" problem.

Yeah. What sort of suffixes (or is it suffixii ? )

Customer$

Customer_

Customer%

Customer#

CustomerModel

(I can hear the screams of anguish from a certain Doctor over the pond !)

Yeah. What sort of suffixes (or is it suffixii ? )

Customer$

Customer_

Customer%

Customer#

(I can hear the screams of anguish from a certain Doctor over the

pond !)

Can non-Doctors chime in on the Screaming?

CustomerModel

MUCH better ...

Weirdly enough I was just looking on Stackoverflow earlier today for help naming a class; found some interesting stuff .

http://stackoverflow.com/questions/38019/whats-the-best-approach-to-naming-classes

http://stackoverflow.com/questions/421965/anyone-else-find-naming-classes-and-methods-one-of-the-most-difficult-part-in-pro (like the ContextVerbHow advice here)

http://caseysoftware.com/blog/useful-naming-conventions has a good rule of thumb ("verbAdjectiveNounStructure - with Structure and Adjective as optional parts")

http://drupal.star.bnl.gov/STAR/comp/sofi/soft-n-libs/standards/NamingAdvice

-- peter

PS if anyone has a suggestion for a class name for an external API to a Business Entity, I'm in the market. API does CRUD and navigation.

First, I use CamelCase like in .NET. Why? Because I cannot change the .NET classes and they simply appear over and over in the code. Second, OpenEdge Architect's "Open Resource Dialog" (CTRL-SHIFT-R) works great with CamelCase.

Second I suffix a class name with the name of the most relevant base name or interface name.

So your Customer would probably be named CustomerEntity or CustomerDataAccess or the like depending on it's nature. This typically resolves issues with ambiguity with database table names. A typical data entry Form for Customer might be called CustomerForm or CustomerLookupForm or CustomerReportForm.

For the CTRL-SHIFt-R, that's CE, CDA, CF, CLF or CRF.

It is 20 years too late to scream ... been enduring that sort of thing for over 20 years in ABL (Varnet anyone!).

I think there are two general principles to consider here.  One will cause groans from some quarters, but this sort of problem is exactly one of the benefits of using some flavor of Hungarian prefixing.  If one calls things tbCustomer or ttCustomer one is never going to have keyword conflicts or ambiguities with other names.  And, of course inCustNo and chCustNo tells you immediately what form the customer number is in to boot.  One can include or skip other parts of the prefixing, but type information is invaluable for avoiding issues like this.

The other principle is that names, particularly of classes, should identify what the class is.  A customer class in a UI package is not a customer class and so it shouldn't have a name which one would confuse with actual customers.  What is the point of having USING if the fully qualified name is needed to tell you what something is?  Give it a name that tells you clearly what the class is without the path.

Naming things well is time put to good use.

You should be glad you don't have to use a certain (not Progress based) ERP system wherein all tables have names of the form ed1234 and column names of the form df4567

>

Can non-Doctors chime in on the Screaming?

>

Yup.

>> CustomerModel

>

MUCH better ...

>

Ha. See, give some unpalatable options, and the first one that is

bearable wins !

Weirdly enough I was just looking on Stackoverflow earlier today for help naming a class; found some interesting stuff .

>

http://stackoverflow.com/questions/38019/whats-the-best-approach-to-naming-classes

http://stackoverflow.com/questions/421965/anyone-else-find-naming-classes-and-methods-one-of-the-most-difficult-part-in-pro (like the ContextVerbHow advice here)

http://caseysoftware.com/blog/useful-naming-conventions has a good rule of thumb ("verbAdjectiveNounStructure - with Structure and Adjective as optional parts")

http://drupal.star.bnl.gov/STAR/comp/sofi/soft-n-libs/standards/NamingAdvice

>

thanks for the links

You should be glad you don't have to use a certain (not Progress based) ERP system wherein all tables have names of the form ed1234 and column names of the form df4567

You've never seen Progress based ERP systems with table and field names like that? Lucky man you are!