|
Good Programming Practice Question submitted by (06 February 2002)  |
Return to The Archives |
 |
 |
|
| When writing a program for stabililty, what should programmers look out for? (Aside from using your memory manager!) :) Any tips you can share for making sure our code is more stable than say - Adobe Premiere? ;) Techniques/things to look out for etc... | ||
 |
 |
 |
|
|
|
This is a great question, one I'm sure will be flooded with reader's comments to
follow. However, to properly answer this question would require enough content
to fill a number of books. Fortunately, those books have already been written by people much better at this stuff than I am. Three books come immediately to mind: Code Complete (by Steve McConnell, Microsoft Press), Writing Solid Code (by Steve Maguire, Microsoft Press) and Effective C++ (by Scott Meyers, Addison Wesley). You might be asking yourself, "Books?! Is that all the wise-and-all-knowing MidNight can offer us? A list of books?!" Of course not. Rather than deluge you with every tip I can think of off of the top of my head, how about three generalized tips? Possibly the most important tips of them all. 1. Know your language (assumes C++) Did you know that a proper implementation of operator new requires an infinite loop? Or how about properly copying a list of objects includes the requirement of in-place construction with operator new and destruction of elements of the list? How can you expect to write stable and robust code if you don't know the language you're writing it in? There are a lot of hidden details in the C++ language. I learned this first-hand when I created my personal template library (lists, arrays, hashes, reservoirs, strings, etc.) Sure, you can make a list class, but can you make a proper list class? I probably only know a half-dozen people that can. C++ is a horribly complex beast with a very misleading "simpler" side. If you only learn the simpler side of the language, you're missing out on the true beauty of the language. And wrapped up in all that complexity is a lot of power. Take command of that power and learn the language you're writing your code in. It'll save a lot of headaches. Of the three books mentioned above, Effective C++ is the best book for this task. The book is organized in a series of "Items" (similar to the tips you're looking for) that can be read out of order so you can jump to the ones you're most interested in. However, I recommend going through the book very thoroughly. As a matter of fact, it's the only technical book I've actually read cover-to-cover without picking and choosing the topics I wanted to read. And I can honestly say I'm a much better programmer because of it – it had a very severe impact on how I write code and taught me a lot about the language. More importantly, it spiked my interest in learning the language to a greater degree. It also won't hurt to spend $18 and get an electronic copy of the ISO specification for C++ -- I find my copy invaluable at times. Though it may be insufferably dry at times, it can answer any non-compiler-implementation dependent question you have about the language. 2. Plan your coding So you've got this great idea for a cool program. You open up your compiler and start coding away. Two weeks down the road, you realize it would be great to add this one feature, except doing so would require a huge re-write of many sections of the code, because the program wasn't organized in a way to allow you to have access to the data where you need it. Too bad, you shoulda planned ahead! Unless you are writing a throw-away program, spend a little time up front and plan it out. At the very least, map out the primary and secondary components; how they relate and what each component is responsible for. Doing this simple task will help you see how everything fits together and where some holes might be. I find that this also helps with ideas for cool new features to add. In the end, it tells you where to put all of your code, development goes faster, and the end product tends to be much more stable. If you're going to spend a few weeks on a program and don't want to spend the time for a proper design, at least spend a few hours up front doing this. You won't regret it. 3. Be patient, practice No matter how experienced you are, every you ever write is practice for the next program. The bigger your mistakes are, the more you'll learn. If you're not making mistakes, you're not gaining any real-world experience. Response provided by Paul Nettle |
||
|
|
|
This article was originally an entry in flipCode's Ask Midnight, a Question and Answer column with Paul Nettle that's no longer active. |