Browse Prior Art Database

Method for allowing customised code "skins" Disclosure Number: IPCOM000124452D
Original Publication Date: 2005-Apr-21
Included in the Prior Art Database: 2005-Apr-21
Document File: 3 page(s) / 35K

Publishing Venue



The concept of applying customised code formatting rules to source code has been present in many Integrated Development Environments for many years, and is of proven benefit to developers. However, there is no prescriptive set of code formatting rules and this can lead to problems when integrating code across a team. From a maintainability point of view, all code should conform to a set of common formatting standards, but how do you then make sure your developers can work efficiently and productively? Code skins allow developers to customise code appearance for their own development environments, whilst maintaining commonality within the team repository.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 3

Method for allowing customised code "skins"

Many Integrated Development Environments (IDEs) such as Eclipse provide code formatting tools to format a source file to a particular developer's personal taste. The traditional benefits of this are based around the fact that if a developer can work with source code in a format that suits them, then they will become more productive. However, debates about the best form for source code to be formatted in often get heated as there are many proponents for the various different options available. For example, consider the following snippets of the same Java* code:

public int add(int int1, int int2) {

int result = int1 + int2;

if(debug = true)

System.out.println("Result = " + result);

return result; }

public int add(int int1, int int2) {

int result = int1 + int2;

If (debug = true)


System.out.println("Result = " + result);


return result; }

    Both of these snippets are functionally identical, but apply different code formatting rules, for example the positioning of the curly braces.

    For serviceability and maintainability of a particular project, it is often preferred to have all source files formatted in the same way. This enables changes to source files to be easily identified by diff tools, and reduces the hurdle of understanding code written by different developers. However, code formatting tools can introduce problems in this area. For instance, in the two source code snippets above, the number of lines taken up by the first snippet is six versus nine for the second snippet. Also, the if statement in the first snippet uses a different syntax (no braces) to the second snippet. If in the course of a code change, a developer checks out a file formatted as per snippet one, and in the course of the change modifies the formatting to match snippet two, as this is their preferred format, then on checking in the file, the changes are going to be more than just the actual code change. The delta introduced by the formatting change will also be reflected by any diff between the new and old files, making it harder to ascertain the real change to the code.

    In order to overcome such a problem, a common approach taken by projects is to utilize the code formatting tools to try and force all developers to stick to one common format. For example, a team may be told to configure their Eclipse environment with a common set of formatting rules. Whilst in a good team the rules

Page 2 of 3

will be discussed and agreed, no one set of formatting rules will allow all developers within the team to work in the most productive fashion.

    The proposed alternative is a method for allowing customized code "skins" to allow developers to work with code formatting rules most suitable to them, whilst maintaining a common agreed underlying format. The core idea is to enable code to be "skinned" to an individual developer's preferences without the underlying format of the source code being changed. The idea is analogous to the c...