| simplifying source codeContext As the months go by, the source code changes. New features are added, bugs are fixed. Generally, the ones who make those modifications are not the ones who created the software. In order not to introduce errors, often, code portions are neutralized and the new variables added which are redundant with existing variables. Entire files become unused. In serious event, the following situation happens • Unused code is being maintainedr • Without knowing anything about it, copies of the same code are being maintained • Everything is linked so you don’t know how to get back reusable parts of an existing code. Avoiding such a situation is possible. Unused source code removal Locate and remove parts that are useless in an application allows simplifying and making easier its maintenance. This code can be: • no more used files • Inaccessible code • Files that are included and do not contain useful information • Unused sub-programs • Unused variables • Useless subroutine parameters Information reorganization Often, during the maintenance phase, developers put the corrections in as few files as possible in order to limit the changes impact. Because of this, data are declared in files where they shouldn’t be, sub-routine code finds itself in environment where it shouldn’t be. Thus, you end up with application where all files are linked. They become more and more hard to maintain. It is possible to locate information that is not where it should be and, by a simple location change, to make a code much more modular. Merging two versions of an application If an application is created copying the full code of another application, and then making changes in the duplicated code to adapt it to new requirements, two applications are obtained for which you don’t know where is the common part. Bugs are fixed in one but not in the other. When a third variant has to be realized, you don’t know which code you should use. Identifying all the common parts of two variants of an application is possible. Those common parts are • Files with same name and strictly identical contents (not taking into account comments and presentation) • Files with same name and very close contents • Files with different names but close contents By this way, you can build up a common basis which will male easier maintenance and creation of new variants. | | |