 wistex wrote:
I remember when the strategy was to write tight code that executed fast.
|
I think we need to define what we mean by tight code. to me, tight code is high-performance(fast) code - not necessarily clear code, and not necessarily concise code.
I've been coding since the 60's when it was all machine op codes and you had to phyically toggle in a boot address for a machine - none of that fancy "push-a-button" to start a computer stuff. Going to assembler was a major breakthrough but I spent years working towards tight (high performance) code.
At one time however, it was pointed out to me that machines had gotten bigger, faster, cheaper. An hour of my time spent tightening code wouldn't pay for itself in a hundred years of code execution.
Coding doesn't provide the majority of my income but even when it did,
time spent improving performance for something that worked was time
spent not generating revenue. Time spent 3 or 5 years down the road
trying to figure out what I did in the code was not time spent making
money.
The only code that needs to be tight (tight=performance) is the kernal and device I/O. Everything else needs to concentrate on being clear and concise - e.g. readily maintainable. Tightness and clarity are often at odds with one another.
Please note though that non-tight code does not equate to poor programming practices for the language involved. Nor is it sn sbsolute rule - there are always instances where you need to tweak performance - usually in the data handling area.
Avoiding poor programming practies means staying away from the known problems with the language - not necessailty tweaking for performance although by doing so, you may inprove performance. In ASP for example, there's 10 or 12 things to avoid. Some of them keep your app from crashing - like closing and releasing objects, keeping db connections out of global.asa, etc. But some of them are to avoid performance hits - like a select Case statement is many times faster than multiple If's.
Good code in my estimation is clear, well formatted/structured, and follows the language conventions of the programming language you're using (e.g. Option Explicit, Select Case, prefixing variables so you know what data types they contain, etc.). Good code is not always the fastest code, but is the most maintainable code.
Topic Options
Post Options
Thanks(0)
