Local Variables Declaration
Declare local variables in the beginning (on the top) of the function, before
the first executable line. This will:
Make it easier to detect all the variables used in the function and to follow
them Keep as little stuff as possible in executable code fragments, where
programmers should concentrate on business logic.
The declaration of a local variable is not an executable command in
PowerBuilder. The memory is allocated on the stack exactly at the moment when
the function is called together with the parameters. It doesn't make sense to
declare a variable inside an "if" construction hoping to improve performance
- the declaration will occur anyway.
Over-Indenting Is Enemy Number One
Indent code fragments with as few tabs as possible.
Don't be carried away by extra indenting. In most cases, an indentation of
three tabs says that the code coul... (more)
To pass errors from functions outward, throw exceptions instead of returning
an error code like -1. That's implemented by filling the "Throws:" field in
the function's header (signature) with the class Exception or its descendant.
When the exceptions mechanism is used, calls to functions look very simple:
As you see, there is no terrible code impurities like
if uf_do_something() = -1 then return -1
li_rc = uf_do_something()
if li_rc = -1 then return -1
The tradition of returning a success/failure code come from ancient times
when exception throw... (more)
Functions Must Be Short
Create a separate function for each logical sub-task, i.e., divide one long
program into a number of short subprograms. The idea is named "Separation of
concerns." Do that not only if the code will be re-used (i.e., called from
more than one place) but even if it will only be called once. It's not a
problem to have a lot of functions belonging to one task or business flow,
even tens - a developer can always bring into focus only one of them. On the
other hand, it's very difficult to understand how one intricate
toilet-paper-long script works. Adherence to ... (more)
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" informa... (more)
Law of Demeter (or Principle of Least Knowledge)
A given object should assume as little as possible about the structure or
properties of anything else (including its subcomponents).
In simpler words: if you want to get data from an object, referenced by a
variable, then use a public function declared in the referenced object
itself, but not variables and functions of its nested object(s).
The law is dictated by real life. Imagine you are paying in a store, and the
cashier asks you to give your credit card. You take your wallet from your
pocket, take the card from the wallet and han... (more)