Is there any merit to fighting code bloat in today's PC age?

[KevinMU1]

OK, so one of my tenets as a developer has been keeping software trim, being minimalistic, and trying to keep code sizes down with various optimizations and rogue programming techniques. I guess it comes from my old days on the Commodore.

Here's my question: does anyone care anymore about code bloat and multi-meg programs that seem to be able to do far less than the size that they take up would imply? Is there any merit to writing tight code and keeping file sizes down? It seems anymore that in the age of huge hard drives, broadband, and fast processors, that compact, efficient code just isn't worth the time anymore.

Am I fighting a losing battle with no merit, or does anyone out there still hold on to these old virtues with me?

 

[Howard]

Here's a piece of code I saw in my friend's app (nothing really important):

int x = 1;
for (int i = 0, i < 3; i++)
x = 2;

 

[ElFenix]

i like tight code

 

[gopunk]

it isn't really an issue if you are writing small programs, but i guess it would help you practice for a situation in which you would need to write a program for which it matters.

 

[Sir Fredrick]

I think the first thing that programmers should worry about is speed. If the file size must be slightly larger, so be it, the code should be fast.
The code should also be readable. You should not have to spend 20 minutes reading through pages and pages of code just to figure out what one small portion is doing; it should be obvious to a moderate programmer.

The program should be usable and straightforward. The interface should not be cluttered and the program should do everything the user needs. The program should "remember" the user's settings as well as handle errors appropriately.

With those things in mind, bloat should be eliminated when it is possible to do so without jeopardizing the above objectives.

 

[Legendary]

Originally posted by: Howard
Here's a piece of code I saw in my friend's app (nothing really important):

int x = 1;
for (int i = 0, i < 3; i++)
x = 2;

Hahahaha
Personally when I code anything I like to make it as short, sweet and efficient as possible
I don't know whether we're fighting a lost cause or not but that's just how I like it.

 

[KingNothing]

Originally posted by: Sir Fredrick
I think the first thing that programmers should worry about is speed. If the file size must be slightly larger, so be it, the code should be fast.
The code should also be readable. You should not have to spend 20 minutes reading through pages and pages of code just to figure out what one small portion is doing; it should be obvious to a moderate programmer.

The program should be usable and straightforward. The interface should not be cluttered and the program should do everything the user needs. The program should "remember" the user's settings as well as handle errors appropriately.

With those things in mind, bloat should be eliminated when it is possible to do so without jeopardizing the above objectives.

My programming teacher always says, get it working first, optimize it later. Your work environment will dictate how much time you can spend optimizing.

 

[aswedc]

Yeah it is very important...

Example of poor coding: the Mozilla project. Go to http://archive.mozilla.org and download one of the releases from around .95 or before. Even on todays fastest computers, its surprising how slow they are. As a result, they've spent something like 5 years cleaning the code and are only now starting to match the speed of other browsers.

Example of good coding: the Konqueror project. Much less time, much less manpower, not yet quite as polished as Mozilla, but much faster. You only have to look open source upset in which Apple chose Konqueror instead of Mozilla for Safari as proof, especially with two prominant Mozilla developers on the Safari team.

 

[gopunk]

Originally posted by: KingNothing

Originally posted by: Sir Fredrick
I think the first thing that programmers should worry about is speed. If the file size must be slightly larger, so be it, the code should be fast.
The code should also be readable. You should not have to spend 20 minutes reading through pages and pages of code just to figure out what one small portion is doing; it should be obvious to a moderate programmer.

The program should be usable and straightforward. The interface should not be cluttered and the program should do everything the user needs. The program should "remember" the user's settings as well as handle errors appropriately.

With those things in mind, bloat should be eliminated when it is possible to do so without jeopardizing the above objectives.

My programming teacher always says, get it working first, optimize it later. Your work environment will dictate how much time you can spend optimizing.

my programming prof always said to look at the situation before deciding what your priorities are... for desktop computing, yea speed is probably most important. but that might not always be the case. there might be a situation where you have an extremely limited amount of memory but running time is not as important. you have to look at each situation individually.

 

[McPhreak]

Originally posted by: ElFenix
i like tight code

me too....







oh wait. Nevermind. I was thinking of asses.

No, I don't care about code.

 

[Argo]

I guess it depends how early you learned to program. I learned on Atari XT running Basic and performance was the key. One extra line and the execution time went from 10 seconds to 15. Most of the newer programmers wrote their first program on PII so there was no need for effeciency. Sometimes, at work, I catch myself wasting time making a piece of code more streamlined. We todays machines, this isn't always a good thing. But I refuse to change!

 

[KevinMU1]

Wow, seems that the results are not what I expected.

I can see how Mozilla would run away in terms of bloat, things that are free are probably not as likely to be optimized when being worked on in spare time and by programmers who are working all over the world with varying styles.

Here's the next question: if there is such concern for bloat, is it important enough that you'd switch from one thing to another if a smaller alternative were available?

 

[AbsolutZero]

Originally posted by: Sir Fredrick
I think the first thing that programmers should worry about is speed. If the file size must be slightly larger, so be it, the code should be fast.
The code should also be readable. You should not have to spend 20 minutes reading through pages and pages of code just to figure out what one small portion is doing; it should be obvious to a moderate programmer.

I agree with that statement. Readable and reusable code is more important than making code efficient in most programming environments: team programming, contracted programming, or places with high turnover.

 

[DivideBYZero]

Originally posted by: Howard
Here's a piece of code I saw in my friend's app (nothing really important):

int x = 1;
for (int i = 0, i < 3; i++)
x = 2;

 

[SSP]

YES IT IS!!!! Just look at Winamp 3!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

[zephyrprime]

AbsoluteZero is totally right. Readability and maintainability are sooo much more important than code size. We just have so much RAM it doesn't matter. Even on microcontrollers you can get quite a lot of onchip RAM (relatively speaking). On the other hand, speed is still important because it pretty incredible how bad performance software can have sometimes. I'm not talking about things like games either which are naturally processor hogs. I mean simple mundane things in office apps that are slow sometimes or most of Windows.

Plus, with graphically programs, a lot of the program footprint isn't code at all but bitmaps. Most graphical program has to keep a uncompressed copy of what it shows on the screen in memory and this can take up a lot of memory if there are a lot of controls on screen and stuff.

 

[KevinMU1]

SSP--excellent case in point.... I still use WinAmp 2. I find that 3 has a ton of stuff I'll never use. Let's see, I want to play an mp3 or playlist... all I want is to click on the file and have it play. Beyond that... yeah.

At least they still have 2 available.

 

[KevinMU1]

zephyrprime, looks like we simultaneously posted, so here's my reply to you.

You are right that even some office apps feel sluggish on Windows. It definitely does seem that by now the computers should be waiting on us, not the other way around.

I believe that Apple uses vectors rather than bitmaps in Mac OS X, which I would think reduces memory usage substantially. The venerable bitmap is not the only answer.

 

[Zugzwang152]

Originally posted by: McPhreak

Originally posted by: ElFenix
i like tight code

me too....







oh wait. Nevermind. I was thinking of asses.

No, I don't care about code.

 

[KevinMU1]

It all has to come back to animal instinct and sex, doesn't it?

 

[KevinMU1]

So those of you using ICQ, how do you justify that?

 

[DaveSimmons]

Originally posted by: zephyrprime
AbsoluteZero is totally right. Readability and maintainability are sooo much more important than code size.

Exactly. In classes you write something once and often never use it again. For "real" applications the same code base is used for many years, with both bug fixes and new features added.

Last year I did some weekend consulting to add a feature for my ex-employer to code I'd written five years ago. The oldest parts of the code base at my current employer are now over three years old.

Once you've had to change code you haven't looked at in over a year a few times, you'll stop writing single-line packed "for" loops and start writing a few comments and using longer variable names

 

[BoberFett]

The design of a classes and their interaction is far more important than the efficiency of code within those classes. If there was more time spent on the design phase of most software, the size and speed of the code would be less of any issue for most people because chances are it would work better. I'll glady sacrifice some speed for stability and expandability in the future.

 

[Lithium381]

Originally posted by: Argo
I guess it depends how early you learned to program. I learned on Atari XT running Basic and performance was the key. One extra line and the execution time went from 10 seconds to 15. Most of the newer programmers wrote their first program on PII so there was no need for effeciency. Sometimes, at work, I catch myself wasting time making a piece of code more streamlined. We todays machines, this isn't always a good thing. But I refuse to change!

i started programming back on a 486.....yes, clean code is important....size is an issue, but not THAT big, i keep it reasonable...though i havne't programmed in a while..

 

[joohang]

It depends on the design goals of the software project. Like someone mentioned earlier, if maintainability is one of the primary goals, it should be favoured over reducing code size.

But then I think that it is necessary for programmers to review each other's code. This way you can ensure that the code is readable to each other (maintainability tends to be high on the list on most projects). Also, any program that is overbloated is a sign that the programmer didn't know what the hell he or she was doing. Peer review could help out on this as well.