Should OpenEdge "enforce" a coding style

Ah. I guess you want us to impose my coding style on all you people then?

Do you actually write ABL?

There is a big difference between adopting a shop standard and having one enforced by PSC.  The former is clearly desirable; the latter sends shivers up my spine.

Ah. I guess you want us to impose my coding style on all you people then?

Not sure, I've ever seen you doing ABL code....

Why wait for PSC? Head over to GitHub and start it up yourself, and make it a collaborative process.  There's a well-referenced repo for Ruby for some ideas.  There is already GitHub-flavored Markdown syntax highlighting support for ABL, as well:

```abl
MESSAGE "foo bar".
```

Then what was it you wanted? I believed the title of your post.

+1

Then what was it you wanted? I believed the title of your post.

Frist, I started the thread and not the Dr.

Second, I didn't think you (as Gus) are equal to OpenEdge.

Third, yes, I follow the article that the Tool vendor should propose ONE programming style.

I have definitively no interest to have that on GitHub or whatever the cool open-source hosting platform of the month is.

mikefe wrote:
Just fell accross this article here yesterday: http://www.drdobbs.com/architecture-and-design/the-need-for-one-true-coding-style/240004664
Looks like I'm not the only one thinking that PSC should at least success a single coding style.

It's an interesting idea. The design meetings for those standards would also be .... entertaining, to say the least. ABL suffers from a backwards-compatibility standard 'problem', in the sense that the first rule is 'first do no harm', which would imply to me that this kind of behaviour would be non-default behaviour, and so there would need to be some kind of carrot to entice people to move to the new standard.

Now what might be interesting is a public or shared set of prolint rules that would be used for documentation, samples etc.

-- peter

Now what might be interesting is a public or shared set of prolint rules that would be used for documentation, samples etc.

Yes.

Now what might be interesting is a public or shared set of prolint rules

that would be used for documentation, samples etc.

Yes.

And also some in-the-box way of applying them? (like a keyword forget list-ish thing?)

-- peter

mikefe wrote:
I have definitively no interest to have that on GitHub or whatever the cool open-source hosting platform of the month is.

I only proposed it because it makes collaboration really easy.  It's too bad that you have no interest in it, because git adoption will only keep skyrocketing, and GitHub is far from being new or temporal, especially after its recent $100M VC funding.  But I guess if you want PSC to come up with the standard for you then collaboration is irrelevant.

>  But I guess if you want PSC to come up with the standard for you then collaboration is irrelevant.

Believe me, working with a large number of Progress customers in Europe I am convinced that the definition of the standard cannot become a community/democratic approach. There are too many opinions.

This needs to be dictated. And the only authority for this CAN be PSC.

Something is still rattling around in my head , and I know I mentioned it a couple of times to a couple of people.

theoretically, using a version control system, you should be able to intercept checkin and convert the abl code into a stream of tokens using prolint. This stream is then converted to a company standard format and checked in.

when a user checks out the code, then prolint is applied and the code restructured and formatted to the users preferred code style

at the moment

def var a as char no-undo.

is different to

define variable a as character no-undo.

is different to

DEF VAR a AS CHAR NO-UNDO.

but, tokenised, they are all the same.

so, if I checked out the code, I would get

def var a as char no-undo.

and Mike would get

DEF VAR a AS CHAR NO-UNDO.

the real advantages of this are

1) the user sees what the user wants, despite other people wanting a different format. You could even strip out spaces between tokens so that

for each customer no-lock do:
end.

and

for each customer no-lock 
do:
end.

are considered the same

2) stupid formatting / case changes won't pollute the version control history.

yeah. I know. there be dragons ahead.

still ....

And also some in-the-box way of applying them? (like a keyword forget list-ish thing?)

OpenEdge Architect: Source -> Reformat

(like in the XML editor)

Yes, I know you started the thread. And I thought that you were proposing

that PSC should enforce a coding style. At least that is what the title

implied to me. Apologies if that is not what you intended.

No, I am not equal to OpenEdge, but if PSC has to pick a coding style to

enforce, everyone will hate it, so it might as well be mine.

I agree that using a consistent coding style can be helpful. Each shop is

free to choose one as they wish. Or not.

So since we are a Tool vendor, what style should we recommend? That

question is probably unanswereable.

theoretically, using a version control system, you should be able to intercept checkin and convert the abl code into a stream of tokens using prolint. This stream is then converted to a company standard format and checked in.

That would completely defeat the purpose (and would only work with a few predefined standards as someone needs to tell the tools what to generate, would not work with the anarchy we have today).

And that still wouldn't solve the issue with the documentation being not in YOUR style (because you're not following the ONLY style). That still wouldn't help with code on forums etc.

and Mike would get

I'd get used to lower case code when that would be THE standard. And I'd also apply harmful keyword abbreviations like in your sample when that would be THE standard.

and Mike would get

And by the way, I'd give up using include files when we have

- Enums

- Generic types

- Itarators

In the language. But that's going off topic.

And also some in-the-box way of applying them? (like a keyword forget

list-ish thing?)

OpenEdge Architect: Source -> Reformat

(like in the XML editor)

Tooling integration is one application.

But I was thinking/wondering more about compiler-enforced rules:

prowin32 -p compile.p -LintRules c:/lint/rules.json -LintLevel strict

-- peter

At least that is what the title implied to me. 

A single coding style implied by the vendor is my intention. So yes, the title of the thread is what I mean.

No, I am not equal to OpenEdge, but if PSC has to pick a coding style to enforce, everyone will hate it, so it might as well be mine.

Well, the fact that there is no coding style - and obviously little interest in a coding style - explains why the coding support in the OpenEdge Architect (including the templates provided) is that poor. So there is certainly a relation between a vendor defined coding style and the quality of the IDE. What shall those "poor" tooling developers follow? - they probably don't even know the ABL, they need a spec to make the editor behave reasonable. And that spec should be derived from a coding style. Modern developers don't want to use vi for coding. The IDE needs to support coding. And that will certainly work better when the tool builder knows the style. Or adopts the style from one of the larger VAR's. ProAlpha has published their style a way back. Use that (as a starting point).

I've also met too many young developers that were getting confused (which is the opposite of being productive) by the difference in coding style in the different publications from the language vendor and the coding style applied at their work place in the different decades. You cannot change all old code. But when PSC is aiming for growth in the developer base, there is a sufficient enough chance for adoption of an new vendor defined coding style.

Each shop is free to choose one as they wish.  Or not.

Not each shop has the resources (time, manpower and the insight into the IDE) to make the tool support that one coding style.

So since we are a Tool vendor, what style should we recommend? That question is probably unanswereable.

Pick one. No matter which one. Just stay consistent in all your publications and in supporting that style from the tool. Enough people will be starting new development projects around N-Tier and OO so that they will be open to follow those standards.

While I think there is good intention here, I have reservations on several grounds.

1. What most people deal with is the mass of existing code.  A tool that would easily and reliably "beautify" existing code would be a boon, but is only likely that people would use it at all if it were configurable to local standards of "beauty".

2. While PSC would the logical organization to promulgate such a standard, it may also be among the least qualified to develop such a standard.  PSC-originated code is hardly a model for much of anything, except sometimes what not to do.  In a way, this is not surprising since PSC isn't, with some exceptions, writing ABL code.  That's us, out here.

3. If such a standard were advanced and were to contain specifications which the community didn't like, chances are it would be simply ignored.  Given the diversity of opinion in the community, that is almost guaranteed.

I think Julian's proposal has merit in two ways, although it could be used in different ways by different shops.

As he notes, tokenizing the code before check-in would dramatically reduce the incidence of false differences, i.e., differences which were only due to formatting.

The ability to format in any still when regenerating the code implies a formatter with a high degree of configurability.  Whether that was used as he proposes, i.e., idiosyncratically by each developer, or if it was used to apply a shop standard to all code, the configurability would greatly increase the likelihood of it being used.

mikefe wrote:
I'd get used to lower case code when that would be THE standard. And I'd also apply harmful keyword abbreviations like in your sample when that would be THE standard.

Huh, guess I did started with lower case only keywords in Zamolxis but remember someone was very keen on having the option to use only caps ...

Truth is, however, that was no coding style imposed by PSC

I agree with Peter on that, a 'strict' option on compiler that will enforce not only coding style but also language constructs that have been 'deprecated' for long time already will at least give someone starting fresh an option to adhere to the coding style and avoid using deprecated syntax.

Although I might not like the outcome (at first), I'm very much in favour of such a coding style. Too many hours have been wasted on this subject and still are.