Good practice: always define buffers? - Forum - OpenEdge Development - Progress Community

Good practice: always define buffers?

 Forum

Good practice: always define buffers?

This question is not answered

Hello,

What code do you like the most, left or right? See screenshot in link below:

https://drive.google.com/a/tvh.com/file/d/0B1P8s6ZKpj7wSnVTLVNONW1laVU/view?usp=drivesdk

Please elaborate why? I'm very interested in the answers.

All Replies
  • See my previous response where I stated that I am sure there are optimizations in the code.  That perfect scenario you are talking about is most likely one of them but I am talking about the code that does not have that perfect scenario.

  • Tom,

    Is this a better code snip?

    The code snip for illustrating "our" preferred coding practices. I'm aware that the data type prefixes are not done according "clean code" (the book :-) ).  And we also made CompanyCode a unique index.

  • Tom,

    my goal is to define good naming conventions. What names will you use for your buffers in this case?

  • Yes, a unique find will try to avoid an ambiguous check. If an unique index is used and it can guarantee uniqueness, there is no check unless unknown values and/or BEGINS is involved. Otherwise, a check is performed.

  • Unique indexes are not always unique -  if one or more key fields are ?.

  • Code that does not have the perfect scenario is an even worse problem... Because there really can be more than one record in that case using FIRST is almost certainly a bug waiting to happen.  

    --
    Tom Bascom
    tom@wss.com

  • If I spot "find first" in code without "find next" I always wonder what's wrong with the second, third, ... record.

    Why didn't they use find last ?

    If the index is unique, and find first is used,  I assume the developer does not know the database schema (s)he is coding against.

    Just my 0,02€

  • Even if there was an infinitesimal performance gain, I would argue against this practice as it confuses the next programmer to work on the code.  The appearance is of non-unique records of which one is getting the first one.  It that were actually done, it would be a violation of normal form.  If the find is actually unique, one is confusing the programmer, who may not have advance knowledge of the related schema.

    But, I also oppose define buffer customer for customer.  By using unique names you make it immediately clear where the scope of that buffer is.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • In my code I like to use a buffer named the same as the table for all no-lock read access.  I create a buffer prefixed with "upd" for buffers that I intend to update (which includes CREATE statements).

    --
    Tom Bascom
    tom@wss.com

  • Maybe we should also discuss the correct way to indent IF statements?  ;)

    --
    Tom Bascom
    tom@wss.com

  • No indentation.  Ever.  Left aligning all code at column 1 is the only way to go.  There are only so many columns so we need to economize.  <smile & laugh>

  • Now that that's been sorted...

    --
    Tom Bascom
    tom@wss.com

  • I assume that it is also common knowledge that you have a small performance gain if you do not indent. That is because spaces end up in the object file and then the ABL engine has to skip them before it reaches an executable statement. Although small, it /is/ a performance gain. The same is true for short versus long variable names. Short names execute faster.

    We stopped indenting and use one-letter variable names only and our code is blazingly fast!

  • about the correct way of indenting, I'm really interested.

    These kind of best practice style rules, is this documented somewhere? My friend Google couldn't help me.

  • Patrick, you forget the cost of CRLF's .... ONE line for all code runs at ludicrous speed.