Comment Fun Friday File Function

Okay, continuing with this theme. Which one of these is your preference for DO / END styles (ignoring the Upper Case keywords and the EQ operator):

Option 1:
Code: 
IF foobar EQ 0 THEN
DO:

    /** DO SOMETHING HERE.... **/

END.

Or Option 2:

Code: 
IF foobar EQ 0 THEN DO:

    /** DO SOMETHING HERE.... **/

END.

Oh yeah, 4 spaces for tab indents.:)
 
Us poor ABL developers. Really - I mean it.

Doing Java development in Eclipse too I can only tell this: Apart from naming conventions you just don't care because you can set all of this in the editor preferences. You want a blank before an opening bracket and a blank before the closing bracket and this other miserable developer didn't code to that standard. Or, you want to have the curly open and curly end brackets in method declarations to appear in their own distinctive line and you guess what ...

Just open the code with your preferences and - bam - there you go! Needless to say that I love it.

IMHO a lot of this discussion only exists because of lacking functionality in the IDE. Having said that, when it comes to such features the OpenEdge editor in the Progress Developer Studio ( Eclipse ) still has a lot of potential for aggressive improvement compared to what is there for Java developers.

Please don't get me wrong: I love the ABL, I really do. IMHO OOABL beats the hell out of all this C#s and Javas of this world - just not toolwise.

Heavy Regards, RealHeavyDude.
 
Cecil said:
Okay, continuing with this theme. Which one of these is your preference for DO / END styles (ignoring the Upper Case keywords and the EQ operator):

Option 1:
Code: 
IF foobar EQ 0 THEN
DO:

    /** DO SOMETHING HERE.... **/

END.

Or Option 2:

Code: 
IF foobar EQ 0 THEN DO:

    /** DO SOMETHING HERE.... **/

END.

Oh yeah, 4 spaces for tab indents.:)
Click to expand...

Option 2, the first disgusts me - but obviously with 3 spaces - and since I'm a visual person = instead of EQ.

Another one is always indent once - if you can't start the block on a new line, and no tagging of statement ends on to the end of the last line of a block, so no:

Code: 
ASSIGN cfoo = "foo"
       cbar = "bar".

But:

Code: 
ASSIGN
   cfoo = "foo"
   cbar = "bar"
   .

And I have to be so fully in agreement with RHD. Additionally - presentation of code does not belong in the code, this is the same as having HTML with all styling and presentation contained inline - its madness. Unfortunately this distinction has never been made.
 
The one true style:
Code: 
if someThing = someThingElse then
  do:
    assign
      a = b
      c = d
    .
  end.
 else
  do:
    assign
      b = a
      d = c
    .
  end.

Other attempts at "style" are sad and lonely.
 
TomBascom said:
The one true style:

snip - this abomination should not be spread further

Other attempts at "style" are sad and lonely.
Click to expand...

Variable indent sizes - oh dear.

Code: 
IF some_thing = some_thing_else THEN DO:
   ASSIGN
      ca = cb
      cc = cd
      .
END.
ELSE DO:
   ASSIGN
      cb = ca
      cd = cc
      .
END.

But once again - a moot discussion if presentation were taken out of the code.
 
My eyes!

UPPERCASE, underscores, color, misaligned periods, crazy placement of DO & END, raising ELSE to the level of a stand-alone statement...

I need one of those industrial eye washer things ;)
 
I could go on all day finding everybody's likes and don't likes. What about shorthand syntax?

Code: 
def var someString as char no-undo.
or
Code: 
define variable someString as character no-undo.

Do you line up all your 'AS' because of the variable lengths of your variable names. For this example I've adopted lowercase KEYWORDS to keep the peace with Tom.:D

Code: 
define variable someString       as character no-undo.
define variable otherStringThing as character no-undo.
define variable foobarString     as character no-undo.
 
Last edited:
Totally agree on the "no abbreviations". I think it's really bad that Progress allows you to abbreviate keywords. What happens if they introduce a new keyword "def"? Suddenly all your code breaks. Unfortunately (or fortunately) PSC won't do that because their philosophy is that once something is allowed it won't be broken in subsequent versions. It's still lazy development IMO.
 
Religion, politics and coding styles are things that should never be argued among friends :)

Most of these examples hurt my eyes as well, but by far the most annoying thing for me is inconsistent styles within the same code base. Especially within the same program.

Second most annoying are unclear (usually short) variable/table/column names. I worked at a place ages ago where the 4GL code was written by converted COBOL programmers... so many A1,AA1,AB1 variables.
 
TheMadDBA said:
Religion, politics and coding styles are things that should never be argued among friends :)

Most of these examples hurt my eyes as well, but by far the most annoying thing for me is inconsistent styles within the same code base. Especially within the same program.

Second most annoying are unclear (usually short) variable/table/column names. I worked at a place ages ago where the 4GL code was written by converted COBOL programmers... so many A1,AA1,AB1 variables.
Click to expand...

Ooooh, you have raised a good point about using digits in variable names. I try not to use numbers, only because if you double click on a variable name inside your IDE, the selected text only highlights up to the number. It can be so frustrating. Thinking about it, it's actually limitation of the AbbBulder IDE.
 
Cringer said:
We have variables with % at the end. Most frustrating.
Click to expand...

That could get very confusing especially if you are using WebSpeed you could potentially end up with this (if you used this style of ASP tagging):
Code: 
<span><%=conversionRate%%></span>

At one point in my code I was going to use '%' symbol but I quick adopted to using 'Pct' abbreviation instead.
 
Yep could get very confusing! Our application has been around for 20+ years and is in-house so coding standards are at a minimum.
Colleague was on a course recently where he met a guy who won't employ experienced Progress developers. He always recruits juniors and trains them himself. That way he knows they won't open all the code and change it to match their own opinion of how things should look.
 
I think being able to abbreviate table and column names (or leave out table names) is worse than abbreviating keywords. I have seen bugs resulting from this (code tries to access some variable which is not defined and the compiler finds some field in some file which is unfortunately unique at the time to it gets accessed instead). I would love to have a parameter to disable those abbreviations.
 
That parameter has been on the wish list for 25 years.

You used to be able to entertain yourself at conference "info sessions" by requesting it and watching "product managers" say things like "that's the first time we've heard that!". (I'll admit that current product management doesn't try that excuse anymore.)
 
You must log in or register to reply here.
Back
Top