| Re: Comments on Coding Style [message #70750 is a reply to message #70698] |
Fri, 30 April 2010 06:07   |
David Gell
Messages: 29 Registered: January 2009
|
Junior Member |
|
|
On Apr 29, 1:26 am, Aram Panasenco <panasencoa...@gmail.com> wrote:
> Hey again people,
>
> I have recently switched to a different coding style. I am currently in
> the first steps of writing a relatively big (for me at least) solar
> software project. I want to keep the source code readable and modifiable
> for other programmers, and I also want to use a consistent convention
> that other people would want to uphold. I have written a small part of a
> standard class that my program will use in a convention that I plan to
> keep for all classes.
>
> I want your comments on the programming conventions I use and how I can
> change them to make the code more clear and desirable for other
> programmers to improve. Some things to consider:
>
> - Should I use comments or is the code (so far) pretty self-explanatory?
> - Is the non-standard capitalization annoying you? Should I switch to
> the classic IDL capitalization (All-caps for IDL keywords, capitalized
> function and procedure names)?
> - Is there anything wrong with the way I handle the IDL class? The
> routines?
> - Anything wrong at all? I'd rather fix it now than thousands of lines
> of code later.
>
> Here's the class itself (finally :P)http://pastebin.com/DXZUsL30
>
> Thank you for your criticism,
> ~Aram Panasenco
I've found using a "Hungarian Notation" where variable names are
prefixed with an code indicating their intended type is useful. IDL is
a flexibly typed language where the type of variable can be
inadvertently changed, so encoding the intended type of the variable
in its name is helpful for debugging. We use the following
type prefix example
string s sName
number n nBigNumber
Boolean b bFlag5
structs x xStructs
widget event we weEvent
widget identifier wi wiOption
widget user data wu wuWState
array a-- axStructs
pointer p-- pPointer1
I don't distinguish between different numerical types. Variable name
capitalization is "camel case" with words capitalized. Variable names
should be descriptive.
As far as comments go, there is no such thing as self-documenting
code. Anyone can figure out what a statement does, but not why. Make
sure you document intent. Remember that you've two audiences when you
write code, the computer, and the poor sod who has to maintain the
code maybe years later. Write code like you write an essay, in
paragraphs. Each paragraph has an intent, document it, then follow
with the code that performs that action.
|
|
|
|