Code bloat

Code bloat is the production of code that is perceived as unnecessarily long, slow, or otherwise wasteful of resources. Code bloat can be caused by inadequacies in the language in which the code is written, inadequacies in the compiler used to compile the code, or by a programmer. Therefore, code bloat generally refers to source code size (as produced by the programmer), but sometimes is used to refer instead to the generated code size or even the binary file size.

Common causes

Often, bloated code can result from a programmer who simply uses more lines of code than the optimal solution to a problem.

Some reasons for programmer derived code bloat are:

• Overuse of object oriented (OOP) constructs – such as classes and inheritance – can lead to messy and confusing designs, often taking many more lines of code than an optimal solution.
• Incorrect usage of design patterns – OOP developers may attempt to "force" design patterns as solutions to problems that do not need them.
• Not using appropriate encapsulation of solutions to partial problems and thus allowing for their re-use, resulting in code duplication
• Declarative programming – implementing a declarative programming style in an imperative or OOP language often leads to code bloat.
• Excessive loop unrolling – without justification through improved performance.
• Excessive use of multiple conditional If statements – instead of, for instance, using a lookup table.

Some native implementations of the template system employed in C++ are examples of inadequacies in the compiler used to compile the language.

A native compiler implementing this feature can introduce versions of a method of a template class for every type it is used with. This in turns leads to compiled methods that may never be used, thus resulting in code bloat. More sophisticated compilers and linkers detect the superfluous copies and discard them, or avoid generating them at all, reducing the bloat. Thus template code can result in smaller binaries because a compiler is allowed to discard this kind of dead code.

Some examples of native compiler derived bloat include:

• Dead code – code which is executed but whose result is never used.
• Redundant calculations – re-evaluating expressions that have already been calculated once. Such redundant calculations are often generated when implementing "bounds checking" code to prevent buffer overflow. Sophisticated compilers calculate such things exactly once, eliminating the following redundant calculations, using common subexpression elimination and loop-invariant code motion.

Examples

The following JavaScript algorithm has a large number of redundant variables, unnecessary logic and inefficient string concatenation.

// Complex 
function TK2getImageHTML(size, zoom, sensor, markers) {
    var strFinalImage = "";
    var strHTMLStart = '<img src="';
    var strHTMLEnd = '" alt="The map"/>';    
    var strURL = "http://maps.google.com/maps/api/staticmap?center=";
    var strSize = '&size='+ size;
    var strZoom = '&zoom='+ zoom;
    var strSensor = '&sensor='+ sensor;    
   
    strURL += markers[0].latitude;
    strURL += ",";
    strURL += markers[0].longitude;
    strURL += strSize;
    strURL += strZoom;
    strURL += strSensor;
    
    for (var i = 0; i < markers.length; i++) {
        strURL += markers[i].addMarker();
    }
    
    strFinalImage = strHTMLStart + strURL + strHTMLEnd;
    return strFinalImage;
};

The same logic can be stated more efficiently as follows:

// Simplified 
function TK2getImageHTML(size, zoom, sensor, markers) {
    var url = [ 'http://maps.google.com/maps/api/staticmap',
        '?center=', markers[0].latitude, ',', markers[0].longitude,
        '&size=', size,
        '&zoom=', zoom,
        '&sensor=', sensor ]; 
    for (var i = 0; i < markers.length; i++) {
        url.push(markers[i].addMarker());
    }
    return '<img src="' + url.join('') + '" alt="The map" />';
}

Code density of different languages

The difference in code density between various computer languages is so great that often less memory is needed to hold both a program written in a "compact" language (such as a domain-specific programming language, Microsoft P-Code, or threaded code), plus an interpreter for that compact language (written in native code), than to hold that program written directly in native code.

Reducing bloat

Some techniques for reducing code bloat include:

• Refactoring commonly used code sequence into a subroutine, and calling that subroutine from several locations, rather than copy and pasting the code at each of those locations.
• Re-using subroutines that have already been written (perhaps with additional parameters), rather than re-writing them again from scratch as a new routine.

See also

• Overloading in polymorphism
• Software bloat
• Minimalism