Description Aaron Digulla 2004-02-25 07:52:12 EST

This is a proposal for post-3.0.

Everybody, who works in a team with other developers, knows that there is (at 
least on a subconscious level) a constant disagreement how to format code.

With Eclipse, we now have (maybe for the first time ever), the possibility to 
take code formatting one step into the future: Realtime code formatting. 
Developers no longer see the code as it really is but how they prefer to see 
it. While Eclipse parses the code to color it, it should also layout it 
according to the preferences of the developer.

When the code is saved, Eclipse should convert the code into a common format 
(probably the Java standard or something on which the team can agree).

Example:

1. Original code in file:

....if (a||b||c||d) {
.........doSomething();
....} else if (e) {
.........doSomethingElse();
....}

2. Code on screen of developer A (wants braces on own lines):

....if(a||b||c||d)
....{
.........doSomething();
....}
....else if(e)
....{
.........doSomethingElse();
....}

3. Code on screen of developer B:

....if (a
.........|| b
.........|| c
.........|| d
....)
....{
.........doSomething ();
....}
....else if (e)
....{
.........doSomethingElse ();
....}

4. Code after saving/during compiling:

....if (a || b || c || d) {
.........doSomething();
....} else if (e) {
.........doSomethingElse();
....}

Now, when the code is compiled, there is a big chance that line numbers are off 
(compare what developer b and the compiler see). To fix this problem, Eclipse 
should start to use virtual line numbers (VLN). A VLN maps the line number in 
the saved/compiled code to the line number on the screen (SLN).

The algorithm is like this:

- Take the code on screen.
- Convert it to the common format. Match each token in both streams (the number 
of tokens is the same).
- To convert a VLN to a SLN, go to the line in the common format. Search the 
first token in that line. Return the line number of the same token in the code 
on screen.
- To convert a SLN to a VLN, go to the line on screen. Search the first token 
in that line. Return the line number of the same token in the code in the 
common format.

Advantages:

- Different developers see the code as they like it.

- The editor can get rid of the whitespace to the left of every line. The 
function of this whitespace is only to make the code more readable. When 
Eclipse layouts the code in realtime, we can in fact just increase the indent 
level of the next line when we encounter the "{" token. There is no need 
to "fix the indentation" of a line and to add/remove spaces anywhere. When I 
type "if(a||b)", Eclipse will show "if (a\n\t|| b\n)\n{" on the screen.

- Code is formatted by the computer and developers can concentrate on more 
important issues.

- It's possible to add more sophisticated layouts of the code. An idea might be 
to fold comments into the code (get rid of the /**/ and display the text with 
times-italic and wrapped to the width of the window) or to add vertical lines 
to show common blocks. Or we could get rid of the braces altogether: They are 
in the code but not displayed. Indentation and thin vertical lines show which 
code belongs to which execution path. Things like switch/case could be 
formatted in a much better way (a "case" in a switch is a label and labels 
shouldn't be indented).

- Since the code is saved in a common format, it's possible to debug or to view 
it outside of eclipse and the line numbers will be correct.

- It could help to debug complex expressions. Eclipse could add a lot of new 
lines in there (creating new VLNs) and the line number of the 
NullPointerException would then point to the part of the expression at fault.

Disadvantages:

- VLNs make things more complex. When a developer says "just look at line 15", 
that can mean nothing to another developer. Displaying VLNs on screen will 
probably irritate the developer. A solution might be to show the virtual 
location in the status bar.

- Memory usage: We need a second parse tree with lots of tiny objects. OTOH, 
the source will be little bit smaller because we can strip 80% of the 
whitespace.

- Writing good realtime formatters is complex and almost every developer will 
want his own, personal version of it.

- The Text component of Eclipse must be changed quite a lot to allow to render 
this (it must support real indents, word wrap and active controls between the 
normal text).