This study provides a critical analysis of refactoring by surveying the refactoring tools in IDEA and Eclipse. Ways are discussed to locate targets for refactorings, via detection of code smells from static code analysis in IDEA and during the compilation process in Eclipse. New code smells are defined as well as the refactorings needed to remove the code smells. The impacts the code smells have on design are well documented. Considerable effort is made to describe how these code smells and their refactorings can be used to improve design. Practical methods are provided to detect code smells in large projects such as Sun’s JDK. The methodology includes a classification scheme to categorise code smells by their value and complexity to handle large projects more efficiently. Additionally a detailed analysis is performed on the evolution of the JDK from a maintainability point of view. Code smells are used to measure maintainability in this instance. / Dissertation (MSc (Computer Science))--University of Pretoria, 2008. / Computer Science / unrestricted

This study assesses how maintainability can be improved by manual and automatic refactoring strategies. Firstly, the structure of the CSS is important and CSS rules should conform to a certain order depending on their purpose. Secondly, dead code makes files unnecessarily large and more difficult to read. Removing dead code is an important step for improving maintenance. These refactoring strategies were taken from the book CSS Refactoring by Lindstrom. The refactoring strategies were tested on a large CSS code base from an ASP.NET application called AktiveraMera. The structure was manually applied by following a step by step process where each CSS rule was classified and sorted into files and folders. For example, rules styling a specific button were put in a file which is then placed in the \emph{component-styles} folder. All these separate files are then concatenated into one file which is then minimized in order to keep it small when it is later served to the user. The divided structure makes it easier for developers to add new component-, structure-, or browser-specific CSS in the correct place. It also makes it easier to keep refactoring limited and the developer knows all rules that are relevant to a certain element are kept in the same place. The new structure introduced some visual regression. It is difficult to assess how much extra time it adds if all visual regression must be remedied, but some of the changes could probably be ignored while fixing the more egregious changes. Either way, some extra work needs to be done but according to interviewed developers it would probably be worth it. The assessment is that the new structure does improve maintainability. The tool CSS-analyser was then used to find and remove duplicated CSS, a form of dead CSS code, in order to reduce the size of the CSS files. Smaller file size (fewer lines of code) is correlated to readability and by extent maintainability since it is less code to read through and understand. However, while the results did show a reduction in file size it did introduce a lot of very obvious visual regression which means a lot more work. In an industry setting there are often time constraints and if something adds more work it might not be a good strategy. The visual regression was akin to a broken website where the entire layout is changed, so it could not be ignored if it was used on the live application in question. Maintainability can be improved by introducing some structure to the CSS code in the form of a folder structure with sorted and classified CSS rules. Removing dead CSS code is difficult to do automatically without introducing website breaking visual regression. It is much more important to make sure the structure of the CSS is good than to directly try to remove dead code, especially since the structure can make other refactoring strategies more effective.