Article: Why Code Readability Matters

[Ñuño Martínez]

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:

  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.

(...) and if it is a class variable it is prefixed with an underscore _chrDelimiter or _blnRunning

it just helps me to know what to expect the value should be. after all, it is all preference if you are working on your project "el solo" The compiler doesn't care as long as you haven't made a grave mistake and called the wrong function or have declared something in local scope that overrides global scope and have forgotten to reference the global scope with Self.VarName

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.