[Tutorial] Organization: naming conventions

by David Workman
Data Mosaic, Inc.

Not since the days when 80% of the world's code resided in COBOL has there been a better tool for writing spaghetti code than Servoy. What?!? How can this happen with an advanced development tool such as Servoy?

If you are like me, developing your first Servoy solution was a struggle of organization. Where did I put that method? What did I name that method? What does this method supposed to do? How much of the code in this method can I copy to paste into my new method? Do I make this a global method or a form method? How do I pass parameters again? Oops, I want to rename 302 forms to be consistent, now what?

Organization is the key to Servoy happiness. In this series of mini-tutorials, I'll let you in on the things that I have learned to do over the past couple of years to be happy in Servoy land. To kick us off, a few thoughts on....

Naming conventions

I use the underscore naming convention for methods, field names, forms, objects, value lists, relationships, etc. Typical method names are "REC_delete", "NAV_next" and "PRINT_report_a". Typical form names are "lvl0_invoice", "lvl1_invoice_form", "lvl1_invoice_list" and "lvl2_invoice_items". Typical object names on a form are "btn_shipping", "fld_shipping" and "bn_chart". Field names in the database backend follow a similar pattern. I don't do anything special with relationship names -- I find the default names do the job nicely.

For variables in methods I use the lower-upper case naming system. "formName", "elementName" and "fieldTrigger" are examples. One addition I like to use is denoting array types in the naming convention like this:

var formNamesARY = new Array;

The advantage to using the two naming systems is that it is easy to tell what is a local variable and what is a named object or field in methods:

name_value = "David Workman"; //value assigned to a field
nameValue = "David Workman"; //value assigned to a local variable

The trick with naming is to use the most generic word of the name first and get successively more specific with the following words. This groups similar items in the various lists (method editor, forms list, value list list, etc).

With forms, I denote the "level" at which the form resides with the first word. "lvl0_invoice" means that this is a parent form based on the table "invoice" and can contain many sub forms. It cannot be a sub form to another form. "lvl1_invoice_list" would be a form that is a list based on the invoice table and located on a tab panel of form "lvl0_invoice". If you use a lot of tab panels (and tab panels within tab panels), this will save your life once your solution reaches forms numbering in the hundreds.

Make sure to start with a naming convention because changing your system mid-stride is not much fun since all the code in your methods is name dependent. However, it can be done using the global search and replace that the method editor has had for a while now. Back in 1.0 days, once you named something, that was it!

The root of organizing your Servoy solution lies in how well you implement your naming conventions so definitely get this area figured out. If you don't, you are bound for a world of hurt.

[Please share your thoughts and ideas in the comment section on this subject. I still haven't made it out of the experimentation stage with naming conventions.]