Good programming practice suggestions

February 4, 2004 5:53 AM

Inside, I've posted a question about computer programming, regarding organizing class libraries and packages -- and also regarding good programming practices.

I've been programming in Actionscript (Flash's programming language) for a few years. Now, Macromedia has released Actionscript 2.0, which, for the first time, allows you to set up class libraries (and packages). I've never programmed before in a language with this feature, and I'm looking for tips about library structure. In other words, what is a good way to organize folders and subfolders (i.e. a graphics folder, a math folder, etc.) for classes. Once you set up a structure, it's hard to modify it in the future, so I want to get off to a good start.

Also, I know there are great books about good programming practices (comment your code, use descriptive variable names, etc.), but can anyone recommend a website with a succinct list of tips about code structure, clarity and organization?

If there isn't a site (though I'm sure there must be), maybe people could share their favorite tips here. In addition to my own programming, I also teach Flash to designers. My classes involve some Actionscript, and I'd like to get my students off to a good start. Most of them won't read a book, but if I can give them some power-tips, they will use them and write code that's at least passable.

posted by grumblebee to technology (6 comments total)

IMO, the best book in the world with regard to good programming practice is "Code Complete" by Steve McConnell. You'll find this from any number of sources. (Side Note: Version 2 of this book is coming out soon - See here for more info.) His Class chapter can also be found here.
posted by seanyboy at 6:02 AM on February 4, 2004

I'll second seanyboy's recommendation; McConnell's book is great, and everyone who's serious about writing good code should re-read their copy every couple of years.

I don't know anything about Actionscript or Flash, but in C++ I try to organize each module around one primary class. The module usually contains other classes which support the main class, but the main class is generally the only one other parts of the program interact with. Sometimes these support classes grow up and turn into important structures in their own right, in which case I break them off into new modules of their own.

For example, a year or two ago I wrote a debugger. It started out as one module, centered around the debugger window itself. The primary class was the DebuggerWindow, but the file also contained a StackViewList control, a VariablesList control, a SourceViewPane, and so on. Eventually we added an ObjectViewer window, which got its own sub-module under the Debugger section. This window also called the VariablesList, so we moved the VariablesList out into its own sub-module too. Now there's a "Debugger" directory containing the main debugger module, the ScopeViewList module, the ObjectViewerWindow module, and so on.

I guess my advice is not to stress about it too much up front. Keep each folder you create focused on one concept; if it gets too large, break it down into subfolders. Let the structure arise out of the implementation instead of deciding what the structure should be up front and fitting your code into it. This is kind of a refactoring-oriented style, but I've found it works and leaves you with project structures that may not look as pretty as you'd like, but actually *work* nonetheless.
posted by Mars Saxman at 8:55 AM on February 4, 2004

+1 for Code Complete. Great book regardless of your language of choice.
posted by trillion at 9:10 AM on February 4, 2004

For designing things in an object oriented environment, I have to recommend design patterns. Good software always comes back to good design.
posted by chrisroberts at 9:26 AM on February 4, 2004

If you want to quickly learn what OO programming you might as well learn a very clean OO language at the same time.

I'd say pick up _Programming Ruby: A Pragmatic Programmer's Guide_ and go through it. Learn OO principles and Ruby and when you come out the other side you will know how to think about your issues.

OO programming is something that you will benefit from diving into and really obsessing about for a few weeks. Just dipping your toe into it makes it seem complex.... the OO way of doing things is actually much simpler in that it is very well organized.
posted by n9 at 2:42 PM on February 4, 2004

If you want to quickly learn what OO programming you might as well learn a very clean OO language at the same time.

I'd disagree with this. I really got the feel for OO programming while learning to do it in C from Roger Sessions Class Construction in C and C++. Yes, you really can do OO development in plain ol' C... and learning this way taught me not only to be very grateful for language features that make it easier but also to impose the discipline of OO (and other good) design tactics on myself.

But grumblebee, your question doesn't have an easy answer. Learning elegant design comes only with experience -- trying and refining your own ideas, and diving into other peoples. Looking for books on design patterns is probably worthwhile, though.
posted by weston at 8:47 PM on February 4, 2004