[Tutor] Python Best Practice/Style Guide question

Alan Gauld alan.gauld at btinternet.com
Wed Apr 30 09:32:49 CEST 2008

"Arthur" <pylinuxian at gmail.com> wrote

>i like to write variable the kamelWay (i learned it from some 
> book some time ago)

Camel case is fine. I thionk it actually originated in smalltalk 74
so its been around a long time.

> but i never use spaces even in between :
> variableName=variableValue.

But that's plain hard to read! And in a long program liable
to lead to errors and make debugging much harder. Especially if
its not you doing the debugging! :-)

> i guess i like compact code with fewer lines ... always thought 
> shorter
> programs run faster...

There is a grain of truth in that but not much.
In particular the speed at which the parser parses your code
into byte code before executing it will be virtually unaltered
by putting spaces in. For faster programs its shorter byte
code that counts not shorter source code.

> shortest smartest and fastest way ... since nobody can
> make it happen with less code that yours ... ;)

Well... they could replace all variable/function names with single
characters... But they can easily shorten the byte code by using
smarter instructions and better algorithms. The length of the source
code(*) really doesn't bear much relation to the speed of the code.
If you weant to write fast code aim to lay it out so the structure
is crystal clear, that way you will spot how to improve your
algorithm much more easily and that will make your code fly.

(*) It can make a small difference in JavaScript however, not
because it executes faster but because it will download faster!
And in very old line by line BASIC interpreters it made avery
small difference because they didn't produce byte code per
se but just executed each line in turn.

Removing spaces is the coding equivalent to an Olympic swimmer
shaving his head rather than wearing a rubber hat to cut down drag.
The difference is minimal to non existent.

Style is of course a personal choice, but if you ever intend to
share your code or work on bigger projects it is something
that needs careful thought. Aim for beautiful code before fast code.
Fast is easier to build starting from beautiful foundations.


Alan Gauld
Author of the Learn to Program web site

More information about the Tutor mailing list