Skip to Content
Author's profile photo Patrice Domange

PB DO & DON’T : Variables Declaration

As a consultant, I often have to deal with bad habit concerning variables declarations inside PowerBuilder Application I have to maintain.

Here, I will not enter in the endless discussion about naming convention as if my client use one, I will have to stuck on it anyway regardless of its quality;

but I will focus on some kind of common sense rules.


Some developers, often with a 2GL background like C,C++ or even Java, prefer to place the local variables declarations to the nearest corresponding code, and if possible only when it is needed, so often inside IF block, claiming it optimize both memory consumption and code readability.

The problem is that with PowerBuilder it is useless as all the variables will be handled by the compiler at the beginning and instantiated in any case.

The code readability reason is also discutable because it is always easier to look at the top of the code to find a particular variable declaration than looking for it inside the code furthermore than PowerBuilder do not have a “Go to Definition” functionality.


Again a 2GL background bad habit where variables of the same data type are stuck on very long line separated by commas.

Not only it does make very difficult to find specific variables declaration but it also make refactoring/clean up of the code a nightmare.


Very often, people add the variables they need at the end of the last variable declaration as it comes.

At the end, the variables declarations block is a total mess.


That way no need to search in other place than the top of the script for a particular variable.


This will make code refactoring and cleanup easier.

Will also facilitate third party tools source code parsing and avoid related issues.


A good habit will be, at least to :

  • Group variables declaration by data type
  • Sort each group by data type ascending and variable name ascending. (user Excel like tool or advanced text editor)

or when possible or wanted:

  • Group also variables declaration by functionality surrounded by a good comment


Following these few common senses rules will greatly enhance your productivity while maintaining existing or developing new solutions.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      You forgot one:

      Don't name a global, instance, and local variable the same. (yes I have seen code like this...)

      Author's profile photo David Peace
      David Peace

      For me the most important is to have some meaningful prefix that identifies the location & datatype.

      The most common definition for Strings

      Local: ls_value

      Instance: is_value

      Global: gs_value

      I'm currently working on a system that does none of these, makes life hell!

      Author's profile photo Ricardo Jasso
      Ricardo Jasso

      There was an excellent product called PB Code Analyzer that checked for non conforming variable and object nomenclature. Also for unused variables. If it's still on the market it is worth giving it a try.

      Author's profile photo Nathan Mitton
      Nathan Mitton

      Good points.
      Another thing is not to initialise a variable in the declaration using a value based on current conditions, for example date/time/datetime variables using functions such as Now()/Today() etc.

      The variable’s value is set when the script is compiled (not at runtime), so when this is built into an executable, the variable will be set to the date etc the build was created, not the current date. I got burnt by this many years ago!

      In summary -

      date    ldt_date

      ldt_date = Today()    = Good 🙂

      date    ldt_date = Today()  = Bad 🙁

      Author's profile photo Former Member
      Former Member

      You can take advantage of setting the variable with the declaration:

      datetime idt_compileDate = datetime ( today ( ) ,now ( )  )
      Author's profile photo Former Member
      Former Member

      /* very out of date info - ignore this

      Nathan: It is NOT set at compile time, the compiler doesn't execute the functions as it compiles. It is however only set once in the running script, so if it's in a loop it will not be set with every iteration.

      For static, or first time only, info (quoted string, literal number), assigning with the declaration is fine, but if the value needs to be set every time in a loop, you *must* make the assignment separate from the declaration.


      Author's profile photo Former Member
      Former Member

      As Lars pointed out, the compiler does indeed run the functions and assign the result as the default value. I'm not sure if it works for locals but it certainly does for instance and global variables.

      This is how a program can display 'compiled date' on its About window.

      Author's profile photo Former Member
      Former Member

      That one is news to me. We've been getting the date/time the app was built (for about box) by using api functions. Never knew compiler actually executed anything during compile.

      Any idea when this became the norm? (I'm pretty sure back in the early days of PB, this isn't how it worked - and I've never thought to try to use it this way since)

      Thanks Roland. Always something new to learn.

      Author's profile photo Former Member
      Former Member

      I am pretty sure, if not for ever then certain that PB 6.5 compiled this way...

      Mind you, I think that if you don't touch the object and don't do full builds when creating your exe and pbds then it is perfectly possible to have an "out of date" compile time...

      Author's profile photo Former Member
      Former Member

      I just tested it with PB4 and it works.

      Author's profile photo Nathan Mitton
      Nathan Mitton

      It's worked like that since at least PB 8, because (IIRC) that was the version I was using when I got caught out.

      What I wrote was based on a quote from SyBooks Online - PowerBuilder 12.5 > PowerScript Reference > Declarations >Declaring variables > Syntax of a variable declaration:

      Because the expression’s value is set to the variable when the script is compiled (not at runtime) make sure the expression is not one whose value is based on current conditions. If you want to specify an expression whose value will be different when the application is executed, do not initialize the variable in the declaration. For such values, declare the variable and assign the value in separate statements.

      Author's profile photo Patrice Domange
      Patrice Domange
      Blog Post Author

      Just go to where you will find a tip from Ken


      I have used it long time ago, I think it was with PB 6.5 or 7.0, for one of my customer that would like to have an automated build number it the About of every application, and it did work !

      I have retried it with PB 12.5.2 and Nathan is right: IT DOES NOT WORK ANYMORE !

      Try it with the PB versions you still have, and see what happen.

      I will try with PB 12.6 and see what happen with this version.

      Maybe it would worth to try with every PB version we still have, starting from the older to the latest one, and see what happen...

      Author's profile photo Patrice Domange
      Patrice Domange
      Blog Post Author

      I have to make an ERRATUM with my previous post because, indeed IT STILL WORKS FINE both in PB 12.5.2 and PB 12.6 !!!

      Indeed, it will work if you DO NOT CHECK the AUTOINSTANTIATE property and access the instance variables as static ones, SO WITHOUT CREATING ANY INSTANCE of the incrirminated NVO.