Naming Convention

[amcgilly]

I was recently asked by a client to put together a document detailing my suggested naming and documentation conventions for Servoy solutions.

Once written, I passed it around to a few people (Bob Cusick, Sean Devlin, John Allen) and got their input, and now I've posted it to my website. Take a look if you're interested and if you have any comments, criticisms or suggestions please post them here or PM me. Here's the link:

http://www.mcgilly.com/ServoyNamingConventions.htm

Thanks!

[grahamg]

Hi Adrian

Thanks for another very useful resource. Couple of comments:

- in order to keep field names grouped together I put the identifer as a suffix ie:
customer_name_cs - calc stored
invoice_total_net_c - unstored calc
customer_orders_agg - aggregate

Also I prefix the PK and all FK's with 'z' so that they all sort to the end of the list of field names.

When using temporary vars for debugging in Methods I also start them with a 'z' - makes it easier to tidy up later when you've long forgotten what that variable is doing

Having seen your examples I must go away and improve my puny header blocks


Thanks again

Graham Greensall
Worxinfo Ltd

[Robert Huber]

Hi Adrain, Graham

As I already mentioned earlier, I always look with scepticism to all the attempts for naming convention. Why? Because I rather would like Servoy to look at the cause so we don't need to cure the symptom. If, for example, you put a suffix to a field, what is missing? Just a grouping possibility!
For example i'ts forbidden in our company to code datatypes to attributes or variables. Why? because you never can trust if you see a group of one sort, because may be a developer changed a unstored calc to a stored calc, but forgot to change the suffix on the name. And even if he doesn't forget to rename it, the attribute is used in code etc. and you have to check many places to be sure to have consistently renamed every occurence. Just too much work and still having the uncertainty if it is changed at all. The story would continue like this ...
Of course everybody can do as wished in this respect. I just wish that Servoy improves the developer steadily to overcome most needs for naming conventions, that's what a good tool offers - a good structure for all the development information.
Of course there remain some useful naming conventions, as used in OO programming for example.

Best regards, Robert

Hi Adrian

Thanks for another very useful resource. Couple of comments:

- in order to keep field names grouped together I put the identifer as a suffix ie:
customer_name_cs - calc stored
invoice_total_net_c - unstored calc
customer_orders_agg - aggregate

Also I prefix the PK and all FK's with 'z' so that they all sort to the end of the list of field names.

When using temporary vars for debugging in Methods I also start them with a 'z' - makes it easier to tidy up later when you've long forgotten what that variable is doing

Having seen your examples I must go away and improve my puny header blocks


Thanks again

Graham Greensall
Worxinfo Ltd

[sanneke]

Thanks for posting good naming conventions.

I would like to add two comments.:

I would change first_name to name_first, in that case you would have

name_first
name_last
name_prefix

so all name fields will be ordered next to eachother


It would be easier to postfix the forms instead of prefix, so all the forms are ordered by the tablenames like this:

customer_lst
customer_tbl
customer_frm