Coding Standards

[JamesBowen]

HI All.

In my job there are three developers and we have all our own coding style, methodology and best practice. But we don't have a in house Coding Standards and I would like to write one.

If any body has already written one, which I could use a base template that world be great.

I am not a code Nazi, it just sometimes a spend hours looking a someone else code only to be more confused and not being very productive.

One thing I do preach is variable naming. For example variables should have and meaningful name like for "Transaction Number" would become iTransactionNumber. Where other developers would use vtranum.

I like to use prefixes for variables depending on there datatype/prarmeter/global. Example:

c character/longchar
i integer/int64
d decimal
m memptr
rd raw
r rowid
da date
dt datetime
dz datetime-tz

s stream

If it's a input parameter prefix it with 'p' Example:

define input parameter pcUserName as character no-undo.

Also if it and output or input/ouput parameter prefix it with 'op' Example:

define output parameter opcUserName as character no-undo.
define input-output parameter opcUserName2 as character no-undo.

Anyway you hopefully you get my point.

Many Thanks.

 

[tamhas]

Check here http://www.oehive.org/taxonomy/term/133 and you will find some input.

 

[TomBascom]

Hungarian notation, as commonly implemented, is the work of the devil.

Why spoil a perfectly meaningful and quite readable name by pre-pending gibberish characters? If it is really necessary to know that it is an integer (or whatever) before you even know its name then you are doing something very, very wrong.

 

[joey.jeremiah]

Hungarian notation, as commonly implemented, is the work of the devil.

Why spoil a perfectly meaningful and quite readable name by pre-pending gibberish characters? If it is really necessary to know that it is an integer (or whatever) before you even know its name then you are doing something very, very wrong.

yes. but they also allow you to use simple names, for example, define var tDate as date no-undo.

thats a big reason why they've worked better then other schemes for me, personally.

another thing that not everyone seems to agree on is with capital letters word separators (forgot the term) and acronyms, for example, function readXml or function readXML( )

i think, it should be the first because the purpose of capitals in this case is as word separators, not gramar

 

[TomBascom]

yes. but they also allow you to use simple names, for example, define var tDate as date no-undo.

Is a "tDate" a "tempDate"?

another thing that not everyone seems to agree on is with capital letters word separators (forgot the term) and acronyms, for example, function readXml or function readXML( )

i think, it should be the first because the purpose of capitals in this case is as word separators, not grammar

Camel-case.

I generally agree. But the temptation to keep short terminal acronyms in caps is strong

 

[jongpau]

Yes, I have been young and foolish once and tried to write and set coding standards, and pretty quickly gave up on the implementation (you may actually have to become a very unpopular code nazi to make coding standards work)...

Oh and don't forget that once you have written your little document (which can quickly turn into a 50+ page guide to programmer's hell) you will also have to keep it up to date every time you start using a new Progress/OpenEdge version. For instance with 10.X you'd have to start adding chapters on Object Oriented programming, classes and all the other nice new stuff. And you *may* start using the OpenEdge Architect, which does everything just that little bit different to what the AppBuilder used to do.

I believe that just about as many coding standards that have been (attempted to be) set have been broken as well. Especially when you are working with different contractors a lot, sticking to your standards will not be easy and can be an expensive job.... "Here you go mate, there's your desk and PC and oh, here's our coding standards, so do forget all you have ever done before old chap. Please read this document for the next couple of hours and then when you start working, write your programs and go back to check what you did conforms with our standard"

Different people have different ways of doing things and Progress/OpenEdge, as flexible as it is, allows you to do 'm all, provided the syntax is OK and the end result gets through the compiler OK. Over the past years I have only once asked someone to redo some of the code he did; which was just about running on arm-long pre-processor names and had variable names that were so long that when you got to the last letter of the name you'd forgotten the first :roll: Mind you, his explanation was that the code had to be self explanatory, but that one did not go down very well.

Anyway, that's my two cents worth. You may disagree and that too is your devine right when using Progress/OpenEdge!

Paul

 

[JamesBowen]

Thanks Guys thanks for all your input. I never realized that I have been implementing 'Hungarian Notation' all these years. (http://en.wikipedia.org/wiki/Hungarian_notation)

It just seamed logical to do it that way. I was introduced to this style of programming when I was working closely with 'Progress Professional Services' in the UK and I just adopted it. It was very useful because any the Progress KB 'How to....' where written the same way. Don't correct me the the Progress's Sample Code is perfect it's not.

Also I understand if I was trying to maintain a living document, I could spend most of my time updating it and correcting my code to fit into the 'CODING STANDARDS' and not acutely cutting code.

Also just to put a 'cat amongst the pigeons' what is the preferred method of code block?

I like to code in this fashion:

IF NOT lSucceeded THEN 
DO:

    blar...
    blar..
    blar.

END.
ELSE
DO:
    blar...
    blar..
    blar.

END.

But others code like this because they say it's more readable. How is this easier to read???

IF       NOT lSucceeded 
THEN  DO:

         blar...
         blar..
         blar.

         END.
         ELSE  DO:
                  blar...
                  blar..
                  blar.

                  END.

Anyway I've got to get back to work. Thanks all.

 

[TomBascom]

Your first block structure is tolerable.

My comments regarding the second are unfit for publication on The Internet.

My own style goes like this:

if condition then
  do:
    something.
    something more.
  end.
 else
  do:
    something else.
    something else more.
  end.