Elegant Programming: The Art of Naming (Part 1)

Give all entities mentioned in the code (DB tables, DB tables' fields, variables, classes, functions, etc.) meaningful, descriptive names that make the code easily understood. The names should be so self-explanatory that it eliminates the need for comments in most cases.

Use the words per and by as often as possible - they really simplify a developer's life. A variable's name li_cows_per_farm is better than li_total_cows, and a function name uf_retrieve_city_by_country tells us more than uf_retrieve_city, especially if it doesn't have parameters that supply the "by what" information.

Don't use abstract words like "actual" and "total' in variables names as they will madden you, forcing to spend extra time trying to understand what is "actual," what is "not actual" and which grouping level is "total" for. Is li_total_cows field total per barn? per farm? per village? per province? per country? per the Universe? If, for example, per farm, then how will you name the total per village? It's also "total"! So, don't write simply "total" - write total PER WHAT! Use only exact definitions that produce no (or minimum) questions, even if that results in longer variables names.

When you use values retrieved from database tables, try to name the corresponding variables exactly by the DB fields (of course, adding naming convention prefixes where needed). But you can use local variables' names more freely, especially when the coded logic is complicated while the tables fields are not informative enough (see the previous rule).

Long, Descriptive NamesThe common, obvious practice is to give variables and functions short names. But, sometimes, there are situations when it makes sense to break that rule and use long, "real-English" names that will clearly describe what they are for.

For example, it can be done when a variable is in a rare use (like an instance var, which is referenced only a couple of times), but not a local var which is mentioned in the code many times. Anyway, don't be afraid to give long names any time you feel it will simplify working with the code. See the difference between:

As you can see, names of variables can tell the whole story. Even if it makes a line too long, there is no problem breaking it into two lines - it's better than looking at a variable and having no idea what is stored in it (or to search its declaration in hopes that a clarifying comment exists). But remember - names of that style should be an exception, not a rule.

Exact Action TimingNames describing actions must express if the action should be done in the future or was done in the past.

Giving names to variables, don't force readers to guess an action timing. A good example of a bad variable name is lb_is_calculation. How must the condition "if lb_is_calculation then..." be understood? As you can see, there is no problem exists understanding what it means if the variable is named lb_is_calculation_done (lb_is_calculated) or in the imperative form - lb_do_calculation (or simply lb_calculate).

The common advice is to use words do..., ...to_do, perform..., execute..., ...to_apply, etc., for stuff that should take place in the future, and ...done, ...performed, ...executed, ...occurred, ...passed, ...applied, etc., for things that have taken place in the past.

ConstantsConstants for [Meaningless] Application CodesDon't hard code numbers if they are not apparent - use constants instead.

Okay, it's still possible to understand what "if li_inv_year > 2011..." or "if li_month = 4..." is but what do you want to say to a programmer who has written "if li_window_mode = 3..." or "if li_inv_status = 8..."?

Local and Instance Constants ManagementGiving names to local and instance constants, divide the family prefix from the mnemonic description by two underscores.

Now let's discuss local and instance-scope constants. Their names must consist of two parts:

Group (or "family") - like "ORDER_STATUS" or "INVOICE_STATUS". A few constants of the same family can co-exist in the scope (for example, an order can have many statuses). In fact, it's a prefix before the main descriptive part.

Description (or mnemonic part) - like "OPEN" or "CLOSED". There can be many constants with the same description (for example, both - an order and an invoice - can have the status "OPEN").

Using two underscores (instead of one) to connect both parts will allow code readers to easily distinguish between them, especially when each part consists of a number of words. For example:

Global Constants ManagementConstants, used globally (in different parts of the application), must be declared in not-autoinstantiated NVOs - one NVO per each constants group (or "family") - and accessed via the automatically created global reference variable with the same name, without declaring additional variables and creating instances.

For example, you can have an NVO named n_color for color constants, n_order_status for order statuses constants, etc. It's a good idea to keep them all in one PBL so developers can easily check if the NVO for the group they need already exists or must be created. The constants are declared in the instance variables declaration section in a very straightforward way. Here is a possible set for n_order_status:

If you open any not-autoinstantiated class in the "View Source" mode, you can see that PowerBuilder automatically creates a global variable of that object's type with the same name as the class (PB doesn't know that we add "g" to global vars! :-D ). For example, if you create n_order_status class (not-autoinstantiated, remember?) and look at its source, you'll see the following line:

global n_order_status n_order_status

That's exactly the mentioned declaration of the global var. You don't need to declare a variable of the object each time you need to use a constant in your script - you already have a variable ready for use. That's how you mention a constant in the code:

n_order_status.OPEN

Looking pretty similar to enum of C# but, unfortunately, it's not an enumerated type; you cannot declare a function argument of type n_order_status and pass to that function one of the statuses (which is of type string) defined in the type - you can only pass a reference to n_order_status object, which doesn't solve the problem of passing type-safe arguments. You can make the argument of type string to pass a particular status, but this approach doesn't supply type safety - nothing prevents you from passing an invoice status or even the name of your cat...

Pay attention that PowerBuilder only declares a global variable; it doesn't create an object referenced by that variable. Practically it means that we can use only constants because they belong to a type (not an instance) definition (something similar to static data in C#). If you try to access an instance variable or a function of that global var, then you will get the "Null object reference" error. As opposed to C#, which will happen even if the function doesn't access instance data, so there is nothing like C#'s "static function" behavior in PowerBuilder.

For standalone constants (not belonging to any family) create one common NVO named, let's say, n_const.

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.