From: "Andrew P. Lentvorski, Jr." <[EMAIL PROTECTED]> On Mar 13, 2005, at 7:50 PM, Stewart Stremler wrote:
1) Don't hard-code data. Constants aren't. Besides, it's hard to know why the magic value of 6.28 works. Paths to dependent programs may change. You never know when something on the system will be moved, and your program should still work if everything is moved around.
This is probably more an artifact of programming. I hardcode a lot of things as I am building up a prototype. Overgeneralization kills projects, too. As I need more flexibility, I start building it in.
It takes about 5 seconds more effort to define a constant and use that constant than it does to put magic numbers everywhere. The end result is more readable and more easily changed. You gain time by this, not lose it.
If you're developing good abstractions, this pretty much occurs anyway. You end up with a few files full of UI and IO code, and a lot more files of application logic. If you're mixing app logic and the other calls without abstraction, you're going to get in big trouble sooner or later anyway. It becomes very hard to figure out what logic is effecting your output when its spread across 9 files, vs when its all done by calls into 1 interface.
2) Don't spread out your platform-dependent code. Put it all one file. That way you can rewrite just one file for each system, and porting involves selecting the appropriate machine-specific file to link in to the rest of the system.
Who cares? Everything is x86 running Windows.
While that sentiment is a bit harsh, it is pretty much true. As a software developer, there is *zero* reason for me to acknowledge the existence of anything else.
3) Comment. Explain your intent. "Self-documenting code" is a myth promulgated by the lazy and/or illiterate. It's better to have well-documented but non-working code than to have undocumented but working code -- because then someone else can fix your code instead of having to rewrite it. 80% of the lifetime of a program is spent in maintenance mode.
Disagree. *Strongly*. All comments eventually become obsolete.
As a consequence, I have to disregard comments *anyway*. Don't waste the time putting them in as I don't believe you anyhow.
Never done maintenance coding, have you? My most common thought when looking at some of the 10 year old code I work with on a daily basis is "What the fuck were they doing that for?" If they put in a comment, I *know* why they did it. If they didn't, its going to take me a few hours figuring it out. If I'm lucky and the guy who wrote it still works there. If not, it can take longer.
Comments don't become obsolete if you *gasp* update them. If you don't, you're a piss poor engineer to begin with. Coding is only half our job, on a good day. Keeping code documented and easily understood is the more important half.
By the way, my latest what did they do that for- they added 100 microseconds to the interrupt length due to signal noise on a 3 year old asic. Please tell me how the hell I'm supposed to figure that out without a comment.
Maybe. But I think the bigger meme is going to be that PC's need to go away. Most users would rather have a closed box that is the responsibility of someone else and would likely pay for the privilege.Corps, maybe. People, no. People are cheap. They want to pay for something once, and have it just work from then on. Thats why software subscriptions like MS has wanted to move to for the past 10 years haven't caught on. They'd love to have someone else deal with the hassels, so long as it doesn't cost them.
Gabe
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
