Answered Short-hand syntax (::) for dynamic references

[jmac13]

Hi All,

I'm using open edge 10.2b and I've seen things about short-hand syntax. The only instance I've seen of this is: hb:BUFFER-FIELD("myfield"):BUFFER-VALUE would then become hb::myfield does anyone know what else this was used in? and how i find out the short-hand?

thanks

 

[oli]

Check out the Reference Help file.
Search the ": (colon) punctuation" keyword, and in the "See also" section, you'll find a link to ":: Punctuation".

 

[jmac13]

Thanks just didn't know where to look I'll have a look and see how I get on thanks

 

[GregTomkins]

Here are a few other shortcuts that I know of. People seem to have various degrees of emotional reactions as to whether they're a good idea.

1. Most keywords can be abbreviated eg. 'DEFINE VARIABLE' -> 'DEF VAR', 'DECIMAL' -> 'DEC' etc.
2. You can omit INPUT eg. 'RUN foo.p(INPUT "BAR")' -> 'RUN foo.p("BAR").
3. You can lookup records in single-field indices eg. 'FIND foo WHERE bar = "baz"' -> 'FIND foo "baz"'.
4. You can omit the 'END' on a block, as long as you do it consistently (this one is particularly helpful for lowering the bar of code readability, unless you come from Python, in which case it's obviously good).

 

[Rob Fitzpatrick]

Here are a few other shortcuts that I know of. People seem to have various degrees of emotional reactions as to whether they're a good idea.

1. Most keywords can be abbreviated eg. 'DEFINE VARIABLE' -> 'DEF VAR', 'DECIMAL' -> 'DEC' etc.
2. You can omit INPUT eg. 'RUN foo.p(INPUT "BAR")' -> 'RUN foo.p("BAR").
3. You can lookup records in single-field indices eg. 'FIND foo WHERE bar = "baz"' -> 'FIND foo "baz"'.
4. You can omit the 'END' on a block, as long as you do it consistently (this one is particularly helpful for lowering the bar of code readability, unless you come from Python, in which case it's obviously good).

This discussion could quickly go off into the weeds. However...

1. I've seen both, I've done both. I don't get too bothered about this one. But I just write little snippets for my own use to automate DB tasks, not commercial code. "def var i as i" isn't exactly the height of readability.
2. & 3. I would say they both decrease readability, especially for newbies. You can choose how you write your code, but you typically don't get to choose who will maintain it later, and they're the ones who suffer. There's a lot of "the compiler just works it out implicitly" syntactic sugar in the language that can obscure the function of the code to people who are new to ABL. I'd throw "FOR EACH table1 OF table2..." syntax into the same category.
4. I think this is a horrible practice. To each his own, I guess.

 

[GregTomkins]

I forgot about 'EQ' -> '='. I almost never see 'EQ', but there is a quasi-valid argument for it (it allows assignment and comparison to be differentiated, which Java etc. does by using = and ==).

 

[RealHeavyDude]

Rob, +1.

Ever had to wade through code where a developer didn't care about naming conventions, readability - not even speaking about leaving comments as to why he coded his crap the way she/he did? IMHO, a real pro should do everything she/he can to make her/his code as consistent, readable and well structured as possible. And to me that includes not using possible shortcuts for saving herself/himself from typing a few characters. Reasonably recent development enviroment support things like code completion and the like ...

Heavy Regards, RealHeavyDude.

 

[GregTomkins]

Who said anything about not caring about naming, readability, or comments?

I'd say it's highly a matter of opinion whether 'hb:BUFFER-FIELD("myfield"):BUFFER-VALUE' is more or less readable than 'hb::myfield'. If you come from a C background, the former seems impossibly verbose.

It's hard to argue against consistency (within a project), though.

 

[RealHeavyDude]

Greg I didn't want to upset you.

Heavy Regards, RealHeavyDude.