[MonoDevelop] New code formatter joins line to aggressively

[Mike Krüger]

Hi

> Not all developers have 28" screens. A 13" Macbook, for example, has
> resolution of 1280x800. I can comfortably display about 120 columns on
> such a screen. My desktop has a 24" screen @ 1920 x 1200 but use a
> fairly large font, so I can only display ~140 columns.
> 
> Even if the lines do fit on the screen, it's easier to mentally parse
> an expression that is meaningfully split up over multiple lines.
> 
Yes thats true, but with an artificial limit of X columns you can't
assume that expressions got meaningfully split - they got split in a way
that makes them harder to read. Read again what I've said - we can do it
but is it really a good feature ?

> I personally try to wrap code to *around* 120 chars, which is what the
> MD solutions' column ruler is set to for C# files. I don't use it as a
> hard rule, just a guideline for readability.
> 

Again, try to make an algorithm that improves readability this way -
artificial limits only break long lines in a way that possible don't
make sense - a better approach is to just preserve the user line breaks.

> Case in point: you made formatting changes to code that I wrote
> definitely damaged readability (lines 56 and 277):
> http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/addins/MonoDevelop.DesignerSupport/MonoDevelop.DesignerSupport/ClassOutlineTextEditorExtension.cs?r1=132705&r2=141721
> 

That was the on the fly formatter, it was a bit too aggresive in my
working copy but again I think thats more a matter of personal taste. I
can read line 56 much better this way. 
line 56 can be written shorter as:
IDotNetLanguageBinding binding =
LanguageBindingService.GetBindingPerFileName (doc.Name) as
IDotNetLanguageBinding;
(when adding the using using MonoDevelop.Projects;)

Line 277 would maybe better if you just write 

return !outer.IsEmpty && outer.End > inner.End;

instead of

return ((outer.End.Line > 0 && outer.End.Line > inner.End.Line) ||
(outer.End.Line == inner.End.Line && outer.End.Column >
inner.End.Column));

But I just fixed the bug and the auto formatter did format the lines I
didn't see.

I'm currently working on improvinge the on the fly formatter so that the
algorithm is taken for the whole document format, it'll preserve the
user line breaks.

Regards
Mike