Openedge Coding/db Standards Document?

[catch.saravana]

Do we have any progress provided coding and db standards document/checklist? The coverage should have from low level stuffs like naming conventions, use of ASSIGN, use of NO-UNDO etc. I understand it's always debatable; but do we have one from PSC or may be from our progress experts.

 

[Rob Fitzpatrick]

There isn't anything available from Progress that I'm aware of. You could look on the internet for naming conventions for DB (tables, fields, indexes, sequences), variables, classes, methods, properties, etc. It wouldn't necessarily have to be OpenEdge-specific to be useful. Probably something based on any DB or OO language could provide a decent starting point. Make sure your DB designers are at least familiar with generic concepts like normalization and the normal forms. They should have an idea of what the are, which they want to adhere to, and hold themselves accountable to that. If they are designing indexes they need to understand how the query engines work (4GL and SQL) and in particular how the rules-based 4GL engine selects indexes and brackets on them. That subject is very poorly understood, in general. Another point: don't just create a database schema and expect people to understand the intent behind it. You should start by using a third-party tool (as Progress doesn't provide any) to create a data model, complete with the necessary descriptions of the objects and their purposes, and the relations between them. Then create your schema from that. If you maintain the discipline to keep doing that you'll be ahead of a lot of folks.

In some ways conventions are a matter of taste. One person's perfect naming scheme could make another person recoil in horror. I guess if any one system could please everyone then there would only be one system, and that's not the case. I will say though that having (almost) any naming convention is better than having none at all; having been in both situations I can say that from experience.

You should also be aware that, as Tom has said, just because OpenEdge lets you do something that isn't a good enough reason to do it. You can store gigabytes of XML documents or images, that you might never query, in CLOB or BLOB columns in your database. You can create array fields. You can put validation logic in the schema. You can use ACCUMULATE statements. You can use OF syntax for joins. That doesn't mean you should. Also, be aware of the lists of deprecated and de-supported features in the Product Availability Guide. Don't introduce new code with old features that someone will soon have to fix or refactor.

Regarding NO-UNDO, you should declare all variables, temp-tables, and parameters as NO-UNDO unless you have a good reason for doing otherwise. If you do have a good reason, add a comment to the code so that the next developer doesn't just think you omitted it by mistake.

There's a lot that could be said about conventions for both DB design and ABL code but that's a start.

 

[TomBascom]

The practice of prefixing identifiers with coded gibberish that supposedly embeds information about the data type or scope or some other baloney should NEVER be used. This basically destroys all readability and turns your code into unmaintainable garbage.

People who were exposed to Microsoft coding at a certain time in their lives are in love with it (it is also sometimes referred to as "Hungarian Notation"). It spread like a virus and infected all sorts of other domains -- even Progress.

On the bright side Microsoft has admitted that it was a bad idea and no longer does it. On the not so bright side lots of people have yet to get the memo.

Instead use meaningful names -- taking time to think about the meaning of an identifier and giving it a good name is the best thing that you can do to improve code quality and maintainability. It will do more good for your code than any other step that you can take. It is much more important than choice of language, programming paradigm or any of the other religious arguments that technical people get into.

 

[Etienne Begin]

Name your variables in a way that matters to the reader, and that helps code readability and maintainability. That even may include the datatype in some cases, but not all of them

Good variable names, method names, results in less maitenance, comments and documention. Your code should be self-documenting as much as possible.

 

[TomBascom]

I will confess to a weakness for prefixing tt_ on temp-table names. Other than that I cannot think of a use case that has ever tempted me.

 

[Etienne Begin]

It's difficult to draw the line. Currently I have no good IDE (not my choice), and everyone relies upon "grepping" in UNIX to find information. This forces us to be consistent, and makes you think about a scheme and patterns that are very easy to find. Programs need to be easily diffable by eye and without tools besides a regular Diff command or free tool. This work environment makes me think twice.

Before doing any standard, I need to know what development tools I have. Working in a complex model design with 100s of classes in notepad is tricky!

Good development tools, focusing on readability/maintainability in your code. That's a good place to start, don't try to define everything up front. Learn to work with what you have and try to acquire better tools and coding methods.

 

[Marco Mendoza]

So, the short answer is: no

 

[ForEachInvoiceDelete]

Hey Tom...

We have some legacy variables prefixed with v so you know they are variables. EG vEmployeeNumber

Do you like that?



But in all seriousness

ttTable.Field = Temp-Table.

bTable.Field = Buffer of "Site".

Table.Field = Table.

Doing something like the above is fine by me.