Coding styles.

Cecil

19+ years progress programming and still learning.
When I started to learn progress 4GL in 1998 I was trained to write code like this:

if chStringValue <> "" and chStringValue <> ? then ...

But, in the last 10 years I have now simplified the code to look like this:

if logical( length( chStringValue ) ) then ...

It produces the same result and coding style looks prettier ( i think it does ). I was inspired by some PHP code.

However, I've had some backlash that it's inefficient and it's harder to read. What do you think?

Code:
def var chStringValue as character no-undo.

assign
    chStringValue = ?. // For this test, set character variable to a null/unknown value.

// Fails on a null values.
if chStringValue ne "" then
  message "Test 1: chStringValue is not blank".

// Handles null values but requires an extra 'and' condition.
if (chStringValue ne "" and chStringValue ne ?) then
  message "Test 2: chStringValue is not blank".

// Handles null value and non-empty string values
if logical( length( chStringValue )  ) then
  message "Test 3: chStringValue is not blank".
 
I wouldn't worry too much about the efficiency aspect - that is immaterial unless that code is in a tight loop that repeats a LOT.

To me, it is a bit awkward and not entirely obvious to read. I'm not sure if I could get used to it or not. To some degree I think it depends on how you handle the cases where it is FALSE. Do you then have to check if it is ? or "" separately? Or do they stay lumped together?
 
This kind of stuff is a perfect use-case for static methods.

Progress has , in OpenEdge.Core.String,
C#:
    /* Indicates whether a string is null or empty: empty having no
       non-whitespace characters
      
       @param longchar The value being checked
       @return logical TRUE if the string is null or empty */
    method static public logical IsNullOrEmpty(input pcValue as longchar):

Consultingwerk has a similar IsNullOrEmpty() AND a IsNotNullOrEmpty() method.

Both make the calling code clear:
Code:
// Handles null value and non-empty string values
if CharacterType:IsNotNullOrEmpty( chStringValue ) then
  message "Test 3: chStringValue is not blank".

What is does on the inside matters not. It could read the individual bytes compare them to 32 or 11 or 9 or whatever ...
 
Thank Peter. I tweaked the code to now use the static IsNullOrEmpty() method. It would be nice to have a IsNotNullOrEmpty() method as-well.

I whished there where more examples and better descriptions on the online documentation. OpenEdge API Code Documentation

I'm now reviewing the consultingwerk github repos to to get a better understanding on what each the methods are doing.
 
Last edited:
Thank Peter. I tweaked the code to now use the static IsNullOrEmpty() method. It would be nice to have a IsNotNullOrEmpty() method as-well.

I whished there where more examples and better descriptions on the online documentation. OpenEdge API Code Documentation

I'm not reviewing the consultingwerk github repos to to get a better understanding on what each the methods are doing.

I thought at the time that IF NOT String:IsNullOrEmpty("foo") THEN . was adequate for both cases. But "not" methods are definitely good. Some of this is API design style, some is "we only needed a positive check at that time".

The Consultingwerk stuff is not typically publicly visible; I mentioned it as an example.

Doc ... yeah, that is always a challenge. Especially API/coding doc, in the larger sense of "how do I do this", rather than "what does this method do". Given that the Progress doc tends more to the latter approach, I would suggest asking about the latter. Someone will have an answer, one way or the other ...
 
Code:
if chStringValue > '' then ...
Ha! Looking at it now it so obvious.

Code:
def var chVal as character no-undo.

chVal = ?.

if chVal gt chr(0) then 
    message "chVal:" chVal.
else
    message "null value!".
 
Ha! Looking at it now it so obvious.

I ask myself whether >"" includes ? every single time I see it. There are so many functions and statements that return ? when ? is just in the same neighborhood. Clearly my brain does not accept this as valid :D
 
Last edited:
Back
Top