Thursday, January 04, 2007

Think ahead and start right

Let me back off a bit and offer some general opinions that may save some time in the end. When I first started playing around with python, it was primarily porting old programs from other languages or mapping utilities from Vr's predecessor. It became almost a game to discover how few lines I could accomplish a task in, and how many basic utilities I could port. After the dust settled a little I realized that I was hooked and would be doing most (if not all) my future programming in python. At this point organization became much more important, but I also had some catching up to do. Here are a few things that helped that I would recommend, pardon as I randomly throw thoughts around.

First, develop a coding style that is consistent. One of the things I like about Python is the ease of use, as a result I am constantly passing code around and encouraging people to use, modify, and learn it. As things get passed around, or when you come back to it months later, a consistent style really helps. It has even made it possible to write a program that parses a script looking for certain cues and then writes an html documentation file for it. As examples of coding style the following aren't necessarily the best way to do things but at least I try to do them consistently and they seem to help.

  • Keep small reusable code snippets in a module for that purpose. For example I mentioned a Python incarnation of a C-like printf function, I keep that in my personal util module.
  • When importing and calling a module, I always use the full module name, for example if my printf function is in my dsutil module, I import dsutil then call dsutil.printf() rather than doing a from dsutil import * then just calling printf(). This is a small thing but even for standard modules it always shows where something is coming from.
  • Have some rudimentary version control. I have a function that prints the program name and last date modified at run time. Very basic, but at least if there is a problem I can ask the user what copy they are running.
  • I always put a small block of text at the beginning of a script to make notes in, import all necessary modules next, then declare and initialize what I call "variables of interest" that either need to have a particular starting value or which a user may look for at a later date. If there are more generic variables that are just needed to hold values at run-time I generally let those get created in situ. A good example of this would be something like x,y,z=Sym.GetCoord() where there is no need to initialize the coordinates, just let the function create and set them.
Second, document everything. As mentioned above it doesn't have to be fancy but it is amazing how quickly I forget what I was trying to accomplish with a perfectly functional piece of code like.
A little reminder goes a long way next year when something similar is necessary.

Maintain a simple database of programs written. Just a simple delimited file that contains things like name, function, misc notes, state of completion. With that available I wrote another fairly simple script that parses that file and creates an html document with everything in a table, and links to the files created by the self documented files. In the end if everything goes correct, one program writes the documentation for the script, and another creates the index file from which it can be referenced all based on the information inside the program, or entered in the database.

And just so we don't go too long without a little VrPython code, here are several (though not nearly all) ways to do the old "hello world" program from within Vr. Yes this should have been the very first post, oh well, copy and paste into pyedi and watch the fun begin.

Gui = PyVrGui()

print 'hello world' # to console
Gui.DspMsg0('hello 1') # top Vr status box
Gui.DspMsg('hello 2') # bottom Vr status box
Gui.DspShortMsg(0,'hello 3') # top small status box
Gui.DspShortMsg(1,'hello 4') # bottom small status box
Gui.MsgBox ('hello 5','window title') # dialog popup

No comments:

For anyone interested in trying VrPython for the first time or if you are early in the game, I suggest going to the earliest posts and working forward. I use VrPython every day for many wonderful things, needless to say it will change and could potentially damage a file. Any risk associated with using VrPython or any code or scripts mentioned here lies solely with the end user.

The "Personal VrPython page" in the link section will contain many code examples and an organized table of contents to this blog in a fairly un-attractive (for now) form.