MAMEWorld Forums - Programming - Top Ten of Programming Advice NOT to Follow

I have to say I wholeheartedly disagree with most of what he says. I've had to deal with "software engineers" who think like him, and the effects they have on products. Just briefly:

10. An exception is a hidden goto that may only be hit under very specific circumstances. You don't know when it might happen, and it's easy not to catch an exception you didn't think of. It's far simpler to properly check error codes than properly catch exceptions.

9. There are perfectly good reasons for using unsigned integers, and indicating to the person reading the code that the value should never be negative is one of them. Another good use is dealing with a quantity value which can never be negative by definition. Signed integers don't protect you from anything. They can still overflow or underflow with bad consequences and you need to be wary of this.

8. I agree with most of what he says here. Designing classes around physical objects causes lots of trouble.

7. Whether you can read anyone's code or not, it's grating to be working on a module where the code doesn't look uniform. I don't mind different styles in different modules, but within a module, it's far easier to read if everything looks the same. Where I work, the rule is you follow the coding style of the person who started work on the module.

6. Sure, code should be self-documenting, and if code is confusing, you should rethink it. But while self-documenting code explains the "how", comments explain the "why", and that's what you're probably going to have trouble understanding later, anyway. If you find yourself having to explain the "how" in comments, you probably have a problem, but if you don't explain the "why", you're making trouble for yourself later.

5. Mixed feelings on this one. I believe properties are evil in general, as it's a hidden method call - you should be able to tell from the language syntax whether a line of code accesses a field or calls a method. But I do think accessors are better than public fields, because they give you the freedom to change the underlying implementation while preserving the interface.

4. There are some things that should be global to a process or a thread. It's a fact of life. Things like the file system (process global), run loop (thread global), window server connection (process global), etc. You should use singletons to implement these things, or you'll just be digging a hole for yourself.

3. This is one where you can have your cake and eat it too. Your debug build should be horribly strict on input. Check that everything's perfect every time. This is what assertions are for. Do lots of testing with your debug build. Then in your production build, have more tolerance for borderline input. This way, you can be reasonably sure you aren't abusing your functions, but still have a contingency plan for unexpected cases.

2. No strong opinion here.

1. Designing something properly to begin with saves endless pain later. If a system isn't designed to scale from the beginning, it's very hard to make it scale later, etc. Avoiding upfront design may seem easier at first, but it will hurt you. I'm not saying you have to follow some formal design process, or produce a set of "design specifications", I'm just saying that the design phase gives you a great opportunity to think about ideas and how they might or might not work before you spend a whole lot of time building what may be a flawed solution.