Naming convention

Classic Servoy
1

We will be migrating a large FileMaker solution to Servoy in the coming years and have decided to build the servoy solution from scratch.
In preparation, we are cleaning up the ERD, table names and field names as these carry some historic mistakes and we have the opportunity now to clean that up.

While not very fluent yet in Servoy, some consequences of name covention decisions are not fully grasped and we may regret them in the future. I could not find the definite whitepaper on naming conventions so I would like to base the decisions on the servoy developer experience

Primary and foreign keys
The convention we used in the FM solution was __kp_Contact and _kf_Contact. This was useful as these fields sorted on top when making connections in the ERD and selecting fields in the script manager. As there is no ERD in Servoy, the double and single underscores may become a nuisance when typing in JavaScript and the key fields should be changed to e.g. contact_id
Is it useful to make a distinction between the primary and foreign key as the underlyng table is always visible in JS ?

CamelCase vs underscores
are there still SQL databases that ONLY allow lowercase field names or are CamelCase now widely accepted ?

I realize there are no fixed standards here (the servoy sample for instance mixes plurals and singulars) so I’m more interested in best practices from the Type Ahead point of view as this will have a lasting effect for years to come.
TIA,
Peter

2

Hi Peter,

wonderfull news that you are making the step to Servoy! :)

maybe this will link will help you out: http://www.mcgilly.com/ServoyNamingConventions.htm

3

Hi Peter,

First off a naming convention has very much to do with your own preference.
Of course there are some things in the way Servoy works (modules, etc) that makes that you should using a convention on certain things.

I discussed this on the servoyforge wiki a while ago.
http://wiki.servoyforge.net/index.php/S … /Chapter_3
This page also shows a full (example) naming convention (in fact one that I use myself).

psijmons:
Primary and foreign keys
The convention we used in the FM solution was __kp_Contact and _kf_Contact. This was useful as these fields sorted on top when making connections in the ERD and selecting fields in the script manager. As there is no ERD in Servoy, the double and single underscores may become a nuisance when typing in JavaScript and the key fields should be changed to e.g. contact_id
Is it useful to make a distinction between the primary and foreign key as the underlyng table is always visible in JS ?

I think using a naming convention on these special columns is mostly useful so that you know what you meant it to be 6 months from now. Or what someone else meant it be 1 year ago.

psijmons:
CamelCase vs underscores
are there still SQL databases that ONLY allow lowercase field names or are CamelCase now widely accepted ?

The SQL standard is actually that all database object names are uppercase. PostgreSQL uses all lowercase however and simply cast your query to lowercase when no quoted.
But I believe in all cases a database can handle multi-case names as long as you put double quotes around it like so:

SELECT "myCamelCasedColumn",allupperorlowercasecolumn,ThisWillBeCastToUpperOrLowerCaseByBackEnd FROM table

So if you use mixed casing in your database then your custom queries will require you to quote those objects, which can be a pain.
Using underscores would be easier and still readable.

Hope this helps.

4

Hello Peter, welcome to Servoy world :-)

psijmons:
We will be migrating a large FileMaker solution to Servoy in the coming years and have decided to build the servoy solution from scratch.
In preparation, we are cleaning up the ERD, table names and field names as these carry some historic mistakes and we have the opportunity now to clean that up.

While not very fluent yet in Servoy, some consequences of name covention decisions are not fully grasped and we may regret them in the future. I could not find the definite whitepaper on naming conventions so I would like to base the decisions on the servoy developer experience

Some guys on this forum already know my opinion to naming conventions and some have already given reference. So I only would like to say that keep in mind that naming convention are mainly used because of the Developmont Tools shortcoming, very often because grouping possibilities are missing. So they may be necessary in certain cases, but ususally they can confuse as much as help. I strongly would advice not to put type information and such into the naming convention because if they change, very often one forgets to also change the naming or it may be a real burden to do that. In short, one has to think about how a naming convention is intended to help (others, oneself, …) and does it fullfill this requirements. Often one can find lot’s of more or less consistently applied naming conventions in code, and I think that’s more a hindering than a advantage. But of course you decide for yourself - good look in finding a useful solution! As said, that is may opinion only and can be way off others. Our rule is use only when really needed and an obvious advantage results from it’s use. Because in the end, you also have to manage ALL your pre- and postfixes …

psijmons:
Primary and foreign keys
The convention we used in the FM solution was __kp_Contact and _kf_Contact. This was useful as these fields sorted on top when making connections in the ERD and selecting fields in the script manager. As there is no ERD in Servoy, the double and single underscores may become a nuisance when typing in JavaScript and the key fields should be changed to e.g. contact_id
Is it useful to make a distinction between the primary and foreign key as the underlyng table is always visible in JS ?

We don’t use any prefix for a pk, as it’s alway clearly visible in either a Datamodelling tool (Design time) or in Servoy (Implementation). For an artificial key (with a sequence), we always use the attribute/column name “id”. Concatenated keys are just built up from their “native” names, like for a (school) class this could be level, sign, schoolYear, fractionName as attribute names and level, sign, school_year, fraction_name as column names.
The only convention we use is for foreign keys. They are built up like: _.
For example you have a 1:m relationship form orders to order_positions (where the pd of table orders is id), the foreign key in table order_positions would be order_id (always use the (singular) entity name for the prefix, not the plural).
Or, as a second exampel, for (school) classes having 1:m class_members, where class is having the above mentioned pk’s, the foreign keys would be class_level, class_sign, class_school_year, class_fraction_name.
This is approach also guarantees uniqueness for the foreign key namings.
Entities should be named singular (as they are Entity Sets), and tables plural. In Entities you may use camel case (recommended), whereas in tables use underlines (for compatibility).

psijmons:
CamelCase vs underscores
are there still SQL databases that ONLY allow lowercase field names or are CamelCase now widely accepted ?

I realize there are no fixed standards here (the servoy sample for instance mixes plurals and singulars) so I’m more interested in best practices from the Type Ahead point of view as this will have a lasting effect for years to come.
TIA,
Peter

See above, Servoy itself does not in any case support camel case, like for calculations, when using camel case and want to make it a stored column means problems .-o

Best regards, Robert

5

Thank you all for the feedback,
dilemma’s dilemma’s… but I think I can distill some conventions from them that we can live with.
The grouping options (for fields, script sets, layout sets, etc) I am used to in FileMaker will be sorely missed (feature request for Servoy?).

I agree on using as few pre- and post fixes as possible as just a mouse over may already give you the info you need or the field definition is just one click away.
Also just using id for a primary key is appealing.
I may keep a routine from FM that I often use for debugging purposes; each table will have a unique auto-enter 3 letter acronym field and a calculated concatenated field (e.g. ORD17625) so when in doubt I display this field in portals etc and I can trace abarrant behaviour when looping through complex scripts or when I made an accidental wrong connection in relationships.

No doubt I’ll be back with more questions when I travel the servoy road, bear wih me when some appear ignorant.
Peter

6

Hi Peter

psijmons:
… so when in doubt I display this field in portals

May be you should carefully look at usîng portals at all. I think they are a relict from Servoy beginning and don’t think it’s a good idea to use them nowadays - may be users of portals can comment. We have quite big apps and never used them at all.

Regards, Robert

7

Robert, this may be just symantics because I am used to the term portals in FM,
a layout would be based on a particular base table (e.g. companies), on that layout you have a frm_order displaying the orders. In my view this would constitute a portal, or would that have a different terminology?
So far I have only been playing around with the sample solution that comes with Servoy 5, or is this a relict from the past that is never updated to reflect new standards?

8

Hi Peter

Thanks, and yes it can be looked as semantic, but I just wanted to make you aware of that in Servoy There are 2 ways to display a classic 1:m relationship in Servoy. Either done with a Portal (this is the yellow table like looking symbol in the toolbar list in Servoy) OR the (tabless) TabPanel (the grey tab like looking symbol).
My suggestion was to go with (tabless) TabPanel. Because you are familiar with FileMaker, just because of the familiar name you wouldn’t early on recognice the situation and may be starting with using Portals.
Of course you can use portals, nothing wrong with that, but you may search in the forum for the differences and as I said, I think the TabPanel has many advanteges.

Hope my explanations help.

Have a good start, Robert

psijmons:
Robert, this may be just symantics because I am used to the term portals in FM,
a layout would be based on a particular base table (e.g. companies), on that layout you have a frm_order displaying the orders. In my view this would constitute a portal, or would that have a different terminology?
So far I have only been playing around with the sample solution that comes with Servoy 5, or is this a relict from the past that is never updated to reflect new standards?

9

psijmons:
While not very fluent yet in Servoy, some consequences of name covention decisions are not fully grasped and we may regret them in the future. I could not find the definite whitepaper on naming conventions so I would like to base the decisions on the servoy developer experience

We have fairly specific naming conventions developed over years that we use for our frameworks. Posted here is some considerations for how we arrived at our current naming convention spot and a few screenshots to drive the point home.

The complete details are only really worth reading if you if use our frameworks. It’s currently in closed beta for Servoy 5. Feel free to drop me a line if you want to check it out. Could save you a lot of time if you’re starting from scratch. Like maybe a year or two… :)

==============================
DATA SUTRA NAMING CONVENTION
==============================

What's inside:

	1 10 things to consider in a naming convention
	2 Data Sutra style overview
		1 Uppercase
		2 lowercase
		3 under_score
		4 camelCase
		5 cUs3om
	3 Naming conventions by Servoy object
		1 Modules
		2 Database connections
		3 Databases, tables and columns
		4 Forms
		5 Form objects
		6 Relations
		7 Calculations
		8 Value lists
		9 Methods
		10 Globals and form variables
		11 Variables
	4 Appendix 1: Data Sutra naming conventions chart
	5 Appendix 2: References
	

1 10 things to consider in a naming convention

Consideration 1: Tons of Servoy objects of many different types
You create and name a ton of objects when developing solutions with Servoy. Your solution...modules...database connections...databases, tables and columns...forms...form objects...relations...calculations...value lists...methods...globals and form variables...and finally variables in methods.

Consideration 2: Names must be unique within their object scope
Since you need to be able to find objects in the Solution Explorer

Consideration 3: Be descriptive
In solutions with a number of modules and lots of objects, it's easy to get lost within the object scope. If your names are descriptive within a scope, that can really help.

Consideration 4: Be consistent
Because renaming can be a big chore and confusion is always a headache. 

Consideration 5: Know the Servoy naming quirks
Uppercase, lowercase, camelCase, underscores -- not every style works with Servoy objects. Relations and calculations will convert your uppercase letters to lowercase, most special characters are not valid, etc. A useful quirk is that form events and properties automatically match to a method of the same name. Another Servoy quirk is how to name methods for JUnit testing. Then there is JavaDoc to learn....

Consideration 6: Know your SQL vendor naming restrictions	
It's not just Servoy that you have to worry about, SQL vendors may have their own unique naming restrictions. It helps then to match up your Servoy naming conventions to your SQL vendor.

Consideration 7: Size matters, but not to Servoy
Servoy doesn't have any length restrictions but quite often SQL vendors do.

Consideration 8: Use what naming style is comfortable to you and your team	
As programmers, we have all used many different naming styles over the years. Some are more comfortable to us than others.

Consideration 9: Employing different naming styles for different types of objects can help your frame of reference
Since there are so many types of objects, using different naming styles can be a useful to delineator. For example, we use underscore style for most things but use camelCase for method variable names.

Consideration 10: Module and form names benefit greatly from very descriptive names that add additional layers of organization	
This last consideration is consideration #3 on steroids. There are a couple of Servoy objects (specifically: modules and forms) where being VERY descriptive can go a long ways in organizing your solution and workflow. For example, our module names sandbox modules into several categories and contain a unique identifier that is used as a prefix for many of the named object in the module. And our forms are named so that "formsets" are grouped together in the Solution Explorer. 


2 Data Sutra style overview

1 Uppercase
We only use uppercase for one object -- the top level module "_DATASUTRA_". And even here we've corrupted it with underscores.

With Data Sutra based solutions easily reaching 20+ modules, this highlights this "head" module by making it stand out and alphabetically putting it first in the list of module names.

This is the only module you can rename without having to refactor your solution. Renaming this module to something more representative of your specific solution is often done.

2 lowercase
The only time this style happens is when using camelCase for variables and not needing a second "word" in the name. Sometimes you'll see a form object with just a single lowercase name but that is mistake/laziness where we forgot to add the type prefix to the form object name.

3 under_score
This style is used so commonly it can be practically considered our default style. If we're not using one of the other styles, we're using the under_score style.

4 camelCase
We use this for method variable names.

5 cUs3om (custom)
We use very specific and customized naming styles for two objects -- modules and forms -- to add important layers of organization.

Modules are grouped into three main functional areas (Data Sutra, addons, business); can be split further into types (head, resource); and contain a unique identifier that is used as a prefix for naming objects within the module.

Forms are named by a formula that groups all forms used in a formset together into a hierarchical "bundle". This models how we develop our screens -- some of our screen design patterns comprise of 20+ forms. Having them together in one block with the "head" form at the top saves us loads of time and frustration.
10

Thank you David, a very instructive post ! This clarified a number of issues.
You’re located too far away to give you a hand with digging snow, but I owe you one.