Skip to Content

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.

DON’T DISSEMINATE LOCAL VARIABLES DECLARATIONS ANYWHERE IN YOUR CODE !

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.


DON’T STUCK VARIABLES DECLARATIONS ON THE SAME LINE


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.



DON’T ADD NEW VARIABLE DECLARATION HAPHAZARDLY


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.



DO PLACE VARIABLES DECLARATIONS AT THE TOP OF THE SCRIPT


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


DO DECLARE ONLY ONE VARIABLE BY LINE


This will make code refactoring and cleanup easier.

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


DO SORT & GROUP VARIABLES DEFINITIONS LOGICALLY


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

CONCLUSION

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


To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. 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!

    (0) 
  2. 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.

    (0) 
  3. 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 🙁

    (0) 
    1. Brad Mettee

      /* 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.

      */

      (0) 
      1. Roland Smith

        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.

        (0) 
        1. Brad Mettee

          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.

          (0) 
          1. Lars Mosegaard

            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…

            (0) 
          2. 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.

            (0) 
            1. Patrice Domange Post author

              Just go to http://www.pbdr.com/pbtips/ex/autorev.htm where you will find a tip from Ken

              Howe.


              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…

              (0) 
  4. Patrice Domange 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.

    (0) 

Leave a Reply