[Lazarus] "Figures" in code explorer

[Mattias Gaertner]

On Mon, 20 Apr 2009 12:14:18 +1100
Alexander Klenin <klenin at gmail.com> wrote:

> On Mon, Apr 20, 2009 at 10:19, Mattias Gaertner
> <nc-gaertnma at netcologne.de> wrote:
> 
> >> >> 4c) Add 'Empty begin..end' block, probably with the same check
> >> >> for the comments as in (4a)
> >> >> 4d) Add 'Single statement in begin..end block'
> >> >> 4e) Add 'Too many nesting statements' and 'Too many nesting
> >> >> procedures'
> >> >> 4f) Add 'Line loo long' with default limit of perhaps 80
> >> >> or 90 characters.
> >> >> 4g) Add 'Incorrect indentation' for the cases where
> >> >> indentation does not correctly represent
> >> >>   statement nesting.
> >> >
> >> > Are you joking or are you a grammar nazi?
> >>
> >> Well, 'grammar nazi' can not exist for a compiled language, since
> >> compiler will simply reject grammatically incorrect source.
> >> So you probably mean 'stylistic nazi'. Well, yes, actually I am ;-)

No you are not. You gave some valid points that the categories are not
stylistic. See below.


>[...]
> Let's review:
> (4c) and (4d) are in principle fixable automatically, but the tool to
> do that should definitely not be called 'formatter'.

About (4c) - empty begin..end
I think it should be added, including repeat..until, try..finally,
try..except, case..else, but only when there is no comment.

About (4d) - single line begin..end
Maybe you can give an example when this is not about code formatting?


> (4e) has nothing to do with formatting

True


> (4f) seems like a no-brainer, but it has issues too:
>   1) there are times when slightly overlong lines are the lesser of
> two evils, like e.g. DebugLn lines in Lazarus or some list-formatted
> array initialization.
>   2) line splitting, sepecially for complex expression, seriously
> affects readability,
>     so the choice of the optimal line break position can not be
> automated. 

A good formatter is very flexible and has a lot of options to fine
tune indentation and line break. IMO complex expressions which can not
be automatically broken nicely, should be changed anyway. Maybe the
code explorer should show deeply nested expressions.

Long lines depends on right margin and this heavily depends on
programmers choice. For example if you set your right margin to 80
and you open a unit of other programmers the code explorer will
easily list thousands of long lines. A performance killer.


>(4g) again seems simple, but 'auto-fixing' can in this can
> make things _worse_ by hiding the problem. Consider the code (idented
> by '~' characters): 
> for i := 0 to High(A) do
> ~~if A[i] > m then
> Writeln(A[i]);
> 
> The actual error is a missing 'm := i' line after the if, but
> formatter would change it to
> for i := 0 to High(A) do
> ~~if A[i] > m then
> ~~~~Writeln(A[i]);
> 
> Obtaining correctly formatted but semantically wrong code.
> Hint, on the other hand, will simply point programmer to the
> problematic location where he will hopefully notice and fix it.

Ok, the above example is a good. I thought you meant showing wrong
indentation in general. That would not make much sense, because the
indentation rules belongs to the code formatter and makes only sense
for units you wrote.
So the code explorer can scan for lines 'do' and 'then' lines where the
following line is indented less or equal. Of course some programmers
will switch off the "equal".


Mattias