Bloated code
From IeXwiki
A term given to programs and files with unnecesary content. This leads to slower, more unstable and more resource-demanding without reason (hence "bloated" ) applications. Bloated code is a hallmark of betas, as they tend to focus, initially, on features for features sake, with little concern given to the elegance of the code. This tends to be refined only towards the end of betas, or when they become such a problem that they affect the stability and functionality of the beta. An example of this would be the leaks in explorer, the windows core-system, in early windows longhorn builds. It proved so diastarous that the longhorn teams had to resolve the problem.
A very simple analogy of code bloat is demonstrated below. It is not actual application coding/markup and serves only as an example.
Eg: A program, example.exe must do the following tasks:
Say the message "switching picture" Switch the desktop image of the computer between four pictures, 1.jpeg, 2.jpeg, 3.jpeg and 4.jpeg.
Here is an example of bloated code:
<change picture to : 1.jpeg>
<say : switching picture>
<change picture to : 2.jpeg> <say : switching picture>
<change picture to : 3.jpeg> <say : switching picture>
<change picture to : 4.jpeg> <say : switching picture>
<repeat from start>
As we can see, the command " <say : switching picture> " has been used 4 times, with each instance having the same function. This may not seem like a great deal, but imagine a program where a similar function must be done 1000s of times, and the code quickly becomes large. The analogy was *very* simple, and in real code, the source of bloat would be from a large component repeated, or inefficiently coded. The above code can be simplified and streamlined as shown below:
<value#1 = "say : switching picture">
<change picture to : 1.jpeg> <value#1>
<change picture to : 2.jpeg> <value#1>
<change picture to : 3.jpeg> <value#1>
<change picture to : 4.jpeg> <value#1>
<Repeat>
As we can see, the commonly occuring command has been defined at one point, and then called upon everytime it is needed. This would, in real applications, typically be done in a .dll or similar file, so multiple components/applications could access the repetitive code. Further optimizations could be made, by defining the whole picture changing code, and simply allowing it to be recalled with a picture-indicating variable.
