Release and debug versions

The jQuery example (again)

Did you try to open jQuery.js? If you do so - especially the 'compressed' version - you'll see that it is almost unreadable. The whole code stands on few lines, everything looks encrypted. Fortunately, with the help of the Online JavaScript beautifier, one can make the source easier to read.

But why did the developer wrote the code this way?

Actually, the 'real' development version probably looks more like this one: indeed, it contains comments and the variable names are not shortened to one character.

So what happened and why?

The need for a "release" version

There are several advantages of publishing a condensed version: the most important one is the fact that it contains only what is necessary for the implementation. Indeed, all comments are removed; variables and non-exposed members can be renamed to reduce the file size. The release version may also be designed in a way that eliminates all the debugging stuff (asserts, traces, performance monitors...).

As a consequence, the source is smaller (which means it loads faster in the browser) and this should speed up the execution of code.

Another effect of this non readable version is to harden the possibility of code intrusion. Indeed, most of the interpreted languages like JavaScript do not include any compiling process. It means that when a software component is developed with it, the only way to publish it is to provide the source. Hence, it can be easily analyzed, copied or tweaked.
By extension, any programming language - at least the ones I know - are published in a way that allows reverse engineering. Even C or C++ languages are compiled and generate executable that - in the end - are a list of processor instructions that can be translated into an algorithm (but this is very difficult).

The need for a debug version

On the other hand, the debug version drops all the advantages of the release one. But, as a counterpart, it offers the possibility to troubleshoot the code with a readable version of the code. Additional tests and traces could be provided in order to test the algorithms.

Functionally speaking, it is - at least - equivalent to the release version but with a bigger size and slower execution speed.

Sources and generation

Sources

There are many different ways to build both versions: they can be independent or one may be generated out of the other. In that case, the debug version is maintained by the developers (as it contains comments and readable code) and an action is required to output the release version.

The debug version itself can be generated out of several files (sources) that are grouped together during another generation process. Usually, the bigger the project the more small units are required to simplify maintenance.

Generating the release version

As far as I can tell, it is simpler to generate automatically the release version from the debug one: it means that there is only one code to maintain and the release version can be obtained quickly. In any case, the developers have to make sure that the release version behaves like the debug one: the generation process must not introduce any defects.

Different methods can be used to generate the release version, from the simpler ones (automated search and replace) to more advanced (source code analyzing and rewriting).

Automating the tests

To guarantee that the release version is functionally equivalent to the debug one (and also because I am too lazy to document everything) one simple way is to provide a testing procedure that can be applied on each version and that should generate a comprehensive report highlighting the defects.

This is also useful for the non-regression tests, i.e. to answer the following question: how do you verify that the new version of your code behaves like the previous one?

My choices

I realize that if I want to be exhaustive, I would probably need more time than what I really have and the articles would be far much longer. I obviously plan to have a debug version composed of several files loaded at the same time. Also, the release version would be generated from the debug version.

I hope to have enough time and will to describe all the technics in this blog.