Good Tight Code

A programming concept that the size and efficiency of your code matters. The opposite of BloatWare.

When I started coding, 64k was optional (some thought it extravagant).

Learning to get the most out of 8k or 16k of RAM was a discipline that was highly valued in that day.

It led to deliberate (one might say compulsory) code factoring.

I believe that GoodTightCode is still a worthwhile endeavor.

-- GarryHamilton

Why?

See also: OptimizeLater

why ? Reasons why GoodTightCode is still worthwhile

Better syntax-> greater clarity, fewer lines of code. Fewer lines of code -> less writing, lower initial cost. Greater clarity-> lower maintenance cost. Lower cost -> more value.

(this text copied from JavaOldSyntax, since this text applies to more than just Java).

AreLongAndDescriptiveRelated

I agree that one can go too far in making programs "smaller". However, there are other benefits to smaller, simpler programs than making them fit into less RAM and run in a few microseconds less time. People who write ForthLanguage can give you a list of other benefits. -- DavidCary

I'm not a Forth programmer, but I can think of two benefits:

There is less code to understand, so maintenance is easier.
Other things being equal, less code means fewer bugs.

-- DonaldFisk

When someone uses a peice of software, they have some mental model of that software -- what it can do easily, what it can do with difficulty, what it can't do at all. Often, less source code leads to a simpler mental model (fewer special cases), which makes the software easier to use.

why ? Reasons that no longer make sense

At one time, hardware was more expensive than programmer time for every feasible program.

How

OnceAndOnlyOnce LanguageIdiomsEncouragingSmallMethods RefactorMercilessly

ConstCorrectness sometimes saves a few bytes

discussion

At one time it was good practice to remove all the spaces from VIC-20 BASIC programs to get them to fit in 2.5k. There's a story (probably apocryphal) that Bill Gates changed the prompt in MS BASIC from "READY" to "OK" to save 5 bytes. Do we really want to go back to that kind of mindset, except for special niches like embedded hardware controllers? Do we want to develop complex programs that solve big problems in a way that hinders maintenance and evolution? What would happen if we stopped obsessing over speed and size and started obsessing over whether or not the program solved the customer's problems. had a few bugs as humanly possible, but was open and clean enough to have a long and useful life? --StevenNewton

I'll try to address both the "why?" and "obsessing" points.

What was a context for GoodTightCode has changed.

"Tight" in today's world may have a different expression (OnceAndOnlyOnce, WellFactored), but the antonym is still SloppyCode?.

I firmly believe that it is wrong to write more code than is needed just because you can. I recognize that the greatest expense in a programming project is the cost of the programmer's time and whatever reduces that is a valid constraint -- as long as the resulting product is not the cause of expense or lost production for the customer and as long as the maintenance costs resulting from this "up-front savings" don't balloon.

I just have a real problem with the "engineering" mindset that goes "hey, don't worry, by the time we release this the hardware will be fast enough."

GoodTightCode is the "FitAndFinish?" of programming. You can hide many design flaws under a coat of paint, but performance and MTBF aren't among them.

-- GarryHamilton

I think that in the quest of doing tight code, we sacrifice some of the Software Engineering elements that are a little more important (i.e. scalability and maintainability for example). I worked on an Air Traffic Control system that had 48K (OK that was back in the late 70s but... ) where every bit counted and hardware was expensive but today hardware is cheap and labor is expensive. Should we save a few bits and then have a programmer spend an excessive amount of time modifying the program that is made more complex to comply with the GoodTightCode mind set? Of course, having unreachable code is inexcusable and GoodTightCode will help with that.

--- Barney Levie (hey I left the space in there)

You got it backwards, GoodTightCode isn't more complex, it's simpler. GoodTightCode means no fluff, no redundancy, clear abstractions. GoodTightCode is more readable than BloatWare. GoodTightCode is well factored, and makes programmers lives easier, and reduces the amount of time needed to understand it. GoodTightCode has no drawbacks, only benefits. BloatWare has many drawbacks. Tons of redundancy, tons of dead code, bad abstractions that are more complicated than need be to solve the problem, ton's on inline implementation hiding the big picture, tons of crap in the way forcing you to read and understand 10x the necessary code. GoodTightCode is what's left when nothing can be removed without breaking the program, which is usually quite a lot from looking at sourceforge.

Your "10x" comment reminds me of the "1x" discussion in ForthValues, also DevelopersWithHighProductivityTenxHundredxThousandx

> Is that the same guy who commented on SyntacticDarkChocolate? (see page and you'll see what I mean.)

you dont have to go to far because of modern hardware but code should be well factored to save develipment time you dont save bytes but you try to facter as much as posible.

Size really doesn't matter, who cares if a program is 10k lines or a million lines it's about the features and how they are packaged.

Writing code in fewer lines can be less readable than writing code in more lines (like not showing all work in math class for the teacher). In the bigger picture lines of code doesn't matter it's the units of work being performed by the lines of code which makes the program efficient.

Who cares about efficiency, just throw hardware at it, it's all about quality. Size and efficiency are negligible if the code is well organized.

Good tight code just seems like a case of premature optimization. Trying to write code that is approaching "perfection" rather than writing the code that gets todays work done without trying to play psychic and predict what the future holds.

If you are always doing the simplest thing that could possibly work then good tight code is already being accomplished.