Hi All
Again me and again the same subject
( We means "writing style" no "design style for program logic" by the term "Coding Style" )
Coding, naming, conventions, style ... all of them are for only one goal : readability; that is easy to understand.
So, building a coding style is very simple: when one of your friend ( student, co-worker, or anyone else ) bring/send to you a program file for read ( for search an error, say only your opinion etc ); how it been wrote you want , your coding style must be is that style
I couldn't say "the best style is ..." and posing some rules. I can only say you my own style ( in short as soon as possible
):
- Indentation is very important. It must be reflect hierarchy. The rule is simple : every statement block enclosed by a block statement will be intended.
Example :
Code: Select all
SELE DETY
WHILE .NOT. EOF()
...
WHILE cDetCode == cMastCode
IF cDetCode == "abcxyz"
...
FOR nTransaction := 1 TO nTransCount
...
DO CASE
CASE cTransCode == "A"
...
CASE cTransCode == "B"
...
CASE cTransCode == "C"
...
CASE cTransCode == "D"
...
END CASE // cTransCode
...
NEXT // nTransaction
...
ENDIF cDetCode == "abcxyz"
ENDDO // cDetCode == cMastCode
...
ENDDO // .NOT. EOF( DETY )
...
or
Code: Select all
PROC Main()
IF SetUpFiles()
...
DEFINE WINDOW frm... ;
...
DEFINE MAIN MENU
...
POPUP "File"
POPUP "New"
ITEM ...
ITEM ...
SEPARATOR
ITEM ...
END POPUP // New
ITEM "Quit" ...
END POPUP // File
POPUP "Help"
ITEM "?" ...
...
END POPUP // Help
END MENU // MAIN
END WINDOW // frm...
ENDIF // SetUpFiles()
RETU // Main()
- I'm continuing abbreviate keywords up to four character (fe FUNC, PROC, RETU...). This is an very old habit come very early dBase days
While that time we have only one program editor embedded in dBase and it had 4 KB ( yes 4096 bytes only
) capacity. This abbreviation is totally meaningless for now ; but it's very difficult quitting old habits. Perhaps this abbreviation like me more readable
- Instead of building and using long program file, long modules (procedure of function), I'm taking care of taking it short as soon as possible ( divide and conquer
).
- We talked much on prefixing variable names. Naming conventions doesn't only prefixing, beside prefix, name itself is important and not only for variables, for all identifiers, including modules ( procedures and functions) too.
I'm using upper letters for keywords and module names of system ( Habour or HMG). I don't understand, someones so to say hates upper letters
For me, everything that serve readability is useful.
My conventions for names of identifiers (including module names) is:
- Every name must reflect and/or remind its function.
- Name may consist with one or more word. Words may abbreviated, but this abbreviation must reflect, remind the word without losing the meaning.
- Every word ( abbreviated or not ) in the name begin with upper letter and continue lower ones.
- Though possible, don't begin names one with or more "_" (underscore); this way used by system.
Examples :
cABC : cFirstAttempt
nXYZ : nUnDefinedItem
nIndex : nFieldIndx
cName : cCoustmrName
dDate : dBirthDate
lTrue : lSaved
cNATB Name of author of this book) : cAuthName
( I haven't any comment for single letter names
)
And at last
commenting !
Comments are comments and at point of view of readability, they are valuable as soon as how they are so much .
That is all, folks
Please forgive long speaking and please remind me if any point left missing.
Regards
--
Esgici