Hi Peter

As there are "a few" object types and not clear, wether you want a naming convention for object that could uses in all your projects or separated in each project, it's not easy to answer
What we did is the following

All tables does have the pattern
"T"+<group>+<number>+<extention>
where
<group> is one letter to put the table into a logical group like "P" for person-data, "S" for system-data,...
<number> is a serial* four digit long number. *) It still does have a logic, so "1000" is for the main table, "1100" for example are sublines to the main table, "1010" could be classification info to the main-table and so on
<extention> are used if there is a need for functional subtype, let say "_LCK" is for locking a row, "_PRV" could stand for "previous entries" and so on
If you uses views, then the first letter become a "V"
So "TP1000" stand for person (including legal partnerships&co) main data, "TP1100" stand for members of a partnership. "TP1000_PRV" as functional subtype is then the "predecessor" of a person.

Programs are using the same pattern
"P"+<group>+<number>+<extention>
Where <extention> here is the purpose of the program
"O" could stand for overview
"D" is then detail mask
"S" could by a select mask
"H" is a helper (background) program
...

If there are more then one program for a purpose, just add a serial numer

Why we dont use "talking names"?
Sometimes it's not easy to find THE name
Second: it's not easy to group when using takling names
Third: The risk of missinterpretation of names: Contains an "address" the name too or only an "address"
Fourth: There is no need to translate a name into other languages

For (global) procedures we use a simple pattern
"LP_<name>"  for program local procedures
"LF_<name>"  for program local function
"GP_<name>"  for general global procedures
"GF_<name>"  for general global function
"SP<objtype>_name" for specialized global procedures
"SF<objtype>_name"for specialized global functions
   where <objtype> is a one letter discription where this proc will used
   "C"=componet level
   "E"=entity level
   "F"=field level
   "T" = transaction lebel  (database)
   "X"=special, system near procedures
  ...

So "SPF_FMT" could stand for the globale procedure which will by default called when a field get formatted.
If a globale procedure defined local procedures of its own, the are not called "LP" but "LLP" resp. "LLF"
When debugging through proccode it's the clear if we still in a global proc are back in a component
For the name itself, use one or more three letter abbreviations if possible.
So "GF_GET_DEF_COL" could be read as "get the default colour for something defined in a parameter"

Hope this help a little bit
Ingo

Hi Peter,

naming convention is usually defined to easily and uniquely identify objects during development or at runtime.

If your question is related to development a solution like the one proposed from Ingo could be easily defined and used; if you are looking for a unique identification of your developed objects at runtime, in whichever Uniface development environment will eventually be used, well...things are a little more tricky (IMHO).

From what I've understood from your request you are asking about this second case.

When I develop something, which could be later on imported/used in other Uniface environment I adopt following rules:
my work is from a long time splitted in modules and each module is identified by a short nick 3 chr long ( as [MOD] hereinafter );
- Models: GSX_[MOD]_name
- StartupShells & Components: GSX_[MOD]_name; name could be a structured one, like: XXXXNNYY where XXXX is the internal main object, NN is a number from 00 to 99 and YY is the scope of the component (G for manage, I for Index, P for printing while the last character is often NOT used.
- Libraries: GSX_[MOD] or SYSTEM_LIBRARY (in one case)
- Global proc: GSX_[MOD]_name, excluding UserDefinedFunctions which are defined as being part of SYSTEM_LIBRARY with a name strictly related to what the UDF should resolve, without any prefix examples: endOfMonth(date) or firstCap(string).
- All other central objects: GSX_[MOD]_name plus language when applicable

I know my decision to use SYSTEM_LIBRARY with ENDOFMONTH(date) could be criticized but I really hated my code when I started initially to use GSX_UTL_ENDOFMON(date) !!!

Regards,
Gianni

Hi Gianni and Ingo,

Thank you for your contribution! 

Interesting analysis on the two principles of a naming convention. 
As you know, in the past I have suggested developing products from a community that are made available as open source. 
With the Standarized deployment of Uniface, this is quite possible. Main Development Objects are then called from an application, but do not need to be in the same repository as such. Or not be in the repository at all.
Naming is therefore very important. The naming of components, for example, is bound to a limit of 16 characters, while they should be uniquely and recognizably identifiable.