comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Comments on Coding Style
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Comments on Coding Style [message #70750 is a reply to message #70698] Fri, 30 April 2010 06:07 Go to previous messageGo to previous message
David Gell is currently offline  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.
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: SSW Coordinate Conversions
Next Topic: How to read field attributes in HDF-EOS

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Tue Dec 02 05:18:28 PST 2025

Total time taken to generate the page: 2.00351 seconds