req: Software Carpentry / coding standards
Hi, everyone. We're a month away from final submissions in the Software Carpentry design competition, which means we're two months away from announcing winners and starting implementation effort, and we're wondering whether there are generally-accepted coding standards, naming conventions, or other guidelines that we should adopt. If so, URLs would be welcome... Also, it appears that there are two implementations of the xUnit testing framework in Python: Steve Purcell: http://sourceforge.net/project/?group_id=3912 Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip We'd be grateful for comments on either. Thanks, Greg Wilson Software Carpentry Project Coordinator
[Greg Wilson]
Hi, everyone. We're a month away from final submissions in the Software Carpentry design competition, which means we're two months away from announcing winners and starting implementation effort,
Yay! This is a wonderful competition, and if nobody yet has bothered to thank you for spearheading it, let me know & I'll find someone who will <wink>.
and we're wondering whether there are generally-accepted coding standards, naming conventions, or other guidelines that we should adopt. If so, URLs would be welcome...
When you can't fight about where to put curly braces, there's not much left to argue. The only serious attempt at a Python style guide I've seen is Guido's: http://www.python.org/doc/essays/styleguide.html Two from there large numbers of people will still argue about, but to no avail: + No hard tabs. Indents are 4 spaces, period. + Keep lines strictly less than 80 characters wide (I happen to keep them under 77, to allow for one level of "> " mail quoting). These rules ensure that code is readable as intended across all platforms.
Also, it appears that there are two implementations of the xUnit testing framework in Python:
Steve Purcell: http://sourceforge.net/project/?group_id=3912 Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip
We'd be grateful for comments on either.
Sorry, unfamiliar with these.
On Tue, 6 Jun 2000, Tim Peters wrote:
Yay! This is a wonderful competition, and if nobody yet has bothered to thank you for spearheading it, let me know & I'll find someone who will <wink>.
Yeah, what he said. :)
The only serious attempt at a Python style guide I've seen is Guido's:
I love this style guide. I know it's a strange reaction to have to a style guide, but i agree with basically everything in it, which is probably pretty rare for these sorts of things.
+ No hard tabs. Indents are 4 spaces, period.
Tab characters are the work of the devil. -- ?!ng "China is a big country, inhabited by many Chinese." -- Former French President Charles de Gaulle
Ka-Ping Yee <pingster@ilm.com>:
The only serious attempt at a Python style guide I've seen is Guido's:
I love this style guide. I know it's a strange reaction to have to a style guide, but i agree with basically everything in it, which is probably pretty rare for these sorts of things.
Likewise. I never read this before, but it's spooky how closely the style I evolved myself tracks it. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> If a thousand men were not to pay their tax-bills this year, that would ... [be] the definition of a peaceable revolution, if any such is possible. -- Henry David Thoreau
On Tue, 6 Jun 2000, Ka-Ping Yee wrote:
The only serious attempt at a Python style guide I've seen is Guido's:
I love this style guide. I know it's a strange reaction to have to a style guide, but i agree with basically everything in it, which is probably pretty rare for these sorts of things.
Me too! (Or three, or four by now...) Ken klm@digicool.com
Tim Peters wrote: When you can't fight about where to put curly braces, there's not much left to argue. The only serious attempt at a Python style guide I've seen is Guido's: http://www.python.org/doc/essays/styleguide.html
Yes, I've seen this. I was wondering (a) whether it's up to date (i.e. whether common practice has moved on), and (b) whether there is now a consensus about module structure --- we're expecting several packages that will be shared between tools, plus multiple modules within tools. I've been tracking the occasional message about re-organizing the standard Python library, and would like whatever we do to be in line with wherever Python itself is going. Thanks, Greg
Greg Wilson wrote:
Tim Peters wrote: [Guido's style guide]
Yes, I've seen this. I was wondering ... whether there is now a consensus about module structure ...
No, there's not. And if you ask me, (which you didn't) there's some very bad precedents getting set in the misguided pursuit of "ease of use". Time to call out the PSU before things get out of hand... - Gordon
Tim Peters [tim_one@email.msn.com] wrote:
When you can't fight about where to put curly braces, there's not much left to argue. The only serious attempt at a Python style guide I've seen is Guido's:
The only thing that might be added (I haven't looked in a while, but didn't see it last time I did), is some naming convention issues. I follow pretty standard Smalltalk guidelines: - No '_', use camelCase for seps - Capitalize all Classes, and also global variables - Lowercase for all methods (i.e. setNewBreakpoint) This is just me, and obviously not everyone does this :-) Chris -- | Christopher Petrilli | petrilli@amber.org
Tim Peters: http://www.python.org/doc/essays/styleguide.html
On Tue, 6 Jun 2000, Christopher Petrilli wrote: The only thing that might be added (I haven't looked in a while, but didn't see it last time I did), is some naming convention issues. I follow pretty standard Smalltalk guidelines:
- No '_', use camelCase for seps
I know this is become common practice, but I've been told by two different HCI specialists that studies have shown CamelBackNotation to be harder for non-native speakers to read than underbar_separated_text, particularly when acronyms are part of the name. If anyone has a pointer to an original reference for this, I'd be grateful. Thanks, Greg
On Tue, 6 Jun 2000, Greg Wilson wrote:
Tim Peters: http://www.python.org/doc/essays/styleguide.html
On Tue, 6 Jun 2000, Christopher Petrilli wrote: The only thing that might be added (I haven't looked in a while, but didn't see it last time I did), is some naming convention issues. I follow pretty standard Smalltalk guidelines:
- No '_', use camelCase for seps
I know this is become common practice, but I've been told by two different HCI specialists that studies have shown CamelBackNotation to be harder for non-native speakers to read than underbar_separated_text, particularly when acronyms are part of the name. If anyone has a pointer to an original reference for this, I'd be grateful.
Actually, the "camel case" for identifiers is not a standard Python style. I've seen three forms: - no separator or case usage (e.g. getattr()) - mixed case - lower case with underscores Chris' other points: upper-case-initial classes and lower-case-initial methods are *definitely* standard. Globals are a bit different. I don't think it is standard to capitalize them as Chris mentioned (they might look like classes in that case). There isn't much of a standard there. Definitely another point is the use of "_" for the initial character to signify "private -- don't touch" Cheers, -g -- Greg Stein, http://www.lyra.org/
Hi, Greg Wilson:
Tim Peters: http://www.python.org/doc/essays/styleguide.html
On Tue, 6 Jun 2000, Christopher Petrilli wrote: The only thing that might be added (I haven't looked in a while, but didn't see it last time I did), is some naming convention issues. I follow pretty standard Smalltalk guidelines:
- No '_', use camelCase for seps
I know this is become common practice, but I've been told by two different HCI specialists that studies have shown CamelBackNotation to be harder for non-native speakers to read than underbar_separated_text, particularly when acronyms are part of the name. If anyone has a pointer to an original reference for this, I'd be grateful.
This would be indeed very interesting. But my own experiences support this POV: This naming style issue is similar in Python and one of its early anchestors Modula-2. In 1985 we started our company programming in Modula-2. At that time we decided to code conforming to the original Modula-2 language definition as published by N.Wirth in March, 1980: underscores were not allowed in identifiers! German: '_' verboten! ;-) The software is in use until today and several of our employees still have to use Modula-2 for maintainance. The code base is currently about 1 Mio. LOC. We tried to use english identifiers, although all programmers are native german speakers. We too adopted a style using first char lowercase or uppercase to distinguish identifier classes (modules and procedure names uppercase and all other identifiers lowercase) and later we ran into the problems described above. A few years ago we allowed the use of '_' in identifiers, because the compiler support was available. This has improved the situation somewhat. All our programmers like the possibility to occasionally use '_' in identifiers, especially if idents contain acronyms. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
participants (9)
-
Christopher Petrilli -
Eric S. Raymond -
Gordon McMillan -
Greg Stein -
Greg Wilson -
Ka-Ping Yee -
Ken Manheimer -
pf＠artcom-gmbh.de -
Tim Peters