Nice article. It has a lot of good advices.
I'm sorry but I use capitals for keywords and data types (not defined by user, just the ones defined by the language). I found it's easer to read for me even if I'm using syntax highlighting. You can locate almost any language structure at a glance. For everything else (variables, classes, procedures, etc) I use CamelCase. Often I use upper-case for constants too.
About spaces, I put one before "(" always, and also after ",". See:
Code:ThisProcedureHasSomeParameters(Parameter1, Parameter2, LastOne); ThisProcedureHasSomeParameters (Parameter1, Parameter2, LastOne);
Also, I separate procedure implementations by three empty lines. This way is easer to find where it starts and ends. I use indentation, of course (2 spaces each level, 1 TAB for 8 spaces).
And I never, never, NEVER use hungarian notation. That's true annoying. What if you change the type of a largely used variable? BTW, the proposal of the variable itself should be enough to know the type it is (i.e. a variable named "FileName" will never be of type "INTEGER", will it?)
And use long names (very long sometimes) for everything except few short ones as "Ndx", "Cnt" and few more (never one leter though), and a lot of comments.
In this case I use the "Borland convention" and use "f" (i.e. SELF.fVarName), but only in variables not in properties. I read it in a paper published by Borland itself.
Bookmarks