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:

  -- 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


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.

EditText of this page (last edited March 5, 2010) or FindPage with title or text search