"Good" Programming Practice transcends the language you are programming in!
I'm far from a proficient programmer (in Stata or anything else but)....
2009/11/19 Joachim Landström <[email protected]>:
>
> #1 Do not use either Pascal casing (MyVar) nor Camel casing (myVar) for
> variables and parameters, just stick to small caps.
This is matter of personal choice. When I write things I find it
quicker and easier not to have to reach for the shift button when
typing.
Lots of different approaches,
http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29 but
the beauty is you're free to choose.
> #2 Do not use meaningful and descriptive words to name variables
Again personal choice, and somewhat subjective, someone may use an
abbreviation that to them makes sense. When you read the code you may
not see why they made that choice.
> #3 Use as much of single character variables as you like and surely do not
> comment on what they are
Abbreviations save time typing.
> #4 Do not bother to use method names that dissimilar to existing functions
> (i.e., display versus Display)
> #5 Do not separate logical groups of code
Are you getting at making things object-orientated here? I'm not sure
thats possible as Ado-files are interpreted sequentially so you
generally have to have things in sequential order (or split things off
into separate ado-files).
> #6 There is no consensus about numbers of blank lines between different
> methods in an ado-file.
Should that matter? Surely enough to delineate is sufficient.
> #7 Do no use single spaces before and after operators and brackets.
Another personal preference, personally I do as I find it easier to
read the code, but others don't, yet I can still understand the code!
> #8 By all means use as much of abbreviations as possible
Abbreviations save time typing and are all documented!
> .
> .
> .
> Well I could continue but the more I write I feel that it rather becomes a
> list of bad programming practice.
>
> If we have a look at good programming "code of conduct" in e.g., C++ or Java
> we see extensive use of different types of casing separating classes,
> methods, variables and parameters. Variables are given descriptive words,
> commenting is sparse and largely unnecessary since descriptive words are
> used and abbreviations are avoided as are single character variables. Single
> spaces are used both before and after operators and brackets.
Whilst there may exist "code of conduct" and/or advice on good
programming practice for other languages you're dealing with humans
here! They can and will do as they please.
The rules are very useful when working collaboratively, providing
everyone adheres to them, but look through most user-written ado-files
and they are generally written, maintained and updated by one person,
so whilst its possible for others to look at, and even use others code
to develop further functionality (due credit should be given), its
most likely to be the author who knows what they wrote and why.
> I could go on on this issue but being rather fresh as a Stata user my
> empirical sample of ados may be biased and that is why I raise this
> question.
Plenty on SSC which you can sample. Check out some of the more popular programs.
> What is Good Stata Programming Practice?
As per above, no doubt the same as any other language, but getting
people to adhere to them is a completely different matter!
Neil
--
"The combination of some data and an aching desire for an answer does
not ensure that a reasonable answer can be extracted from a given body
of data." ~ John Tukey (1986), "Sunset salvo". The American
Statistician 40(1).
Email - [email protected]
Website - http://slack.ser.man.ac.uk/
Photos - http://www.flickr.com/photos/slackline/
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
