Michael Zuskin

Subscribe to Michael Zuskin: eMailAlertsEmail Alerts
Get Michael Zuskin via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Top Stories by Michael Zuskin

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: uf_do_something() As you see, there is no terrible code impurities like if uf_do_something() = -1 then return -1 or even li_rc = uf_do_something() if li_rc = -1 then return -1 anymore! The tradition of returning a success/failure code come from ancient times when exception throwing mechanism didn't exist yet in PowerBuilder, but there's no need to use horses in the automobile era. We still check code returned by built-in PB functions, as well as in legacy application code, but be a modern person and write new code. The Art of Exceptions Propagation The rule of usin... (more)

Elegant Programming: Code Writing Style | Part 2

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 variabl... (more)

Elegant Programming: Managing Functions | Part 3

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)

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" informa... (more)

Elegant Programming | Part 4

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)