[Lazarus] "Figures" in code explorer

[Mattias Gaertner]

On Mon, 20 Apr 2009 02:03:30 +1100
Alexander Klenin <klenin at gmail.com> wrote:

> On Mon, Apr 20, 2009 at 01:28, Paul Ishenin <webpirat at mail.ru> wrote:
> > Martin Friebe wrote:
> >>
> >> Hm, while some of them probably are most likely to be used to find
> >> possible issues, there is no need to see them as an "problem
> >> indicator" only.
> >> So point 1 is "correct" as they are a collecion of numbers
> >> "figures"
> >>
> >> Still, maybe they would be better named as "statistics"? (maybe
> >> "analytics" ?)
> > I would call them "IDE Hints" or "Code Hints". But "Figures" are
> > also ok for me.
> 
> My main point with the name is usability. The name should convey
> at least something about the named object to an unprepared reader --
> this is an important rule both in programming and interface design.
> So yes, 'code hints', 'analytics' -- anything suggested in this thread
> is better than 'figures'.
> (Not 'statistics', however, which, by the way, would be another
> interesting feature)

I thought about 'statistics', 'hints' and some more and IMO
they are all misleading.
The new section should sum up and/or list all kinds of noteworthy
numbers, places, lines, structures and facts of the current unit, that
don't fit into the other categories.
These combine several different types of categories like:
-unoptimized code/left over: e.g. empty methods
-code formatting: e.g. unsorted members
-readability/needs refactoring: e.g. long procedures, unnamed constants
-comments: e.g. todos
-...

About 'statistics': statistics are about summarizing and
interpretation. None of the current categories fit into this
description.

About 'hints':
Theoretically you can define 'hint' very generic: some
message about a pascal source. But then the term 'hint' becomes almost
meaningless and every time a user user reads about 'hint' he doesn't
know whether it means fpc hint or lazarus hint. Just like the word
'package' has more than five meanings on this mailing list.
IMHO the term 'hint' has already enough meanings.

Modelmaker has a similar feature called 'live metrics', which fits,
because they mostly list code formatting and readability
categories.
But IMO the category 'code formatting' is questionable.
All other categories list things, that need some manual attention - the
programmer must decide if and how to change it.
OTOH 'code formatting' can be applied safely. 
If you don't like long lines, then you need a tool to break them. When
such a tool exists, you don't need a tool to show where the long lines
are, you just need a flag: this unit needs code formatting.
Instead of adding code explorer categories 'unsorted procedures' it
makes more sense to improve the jedi code formatter and its
lazarus integration.
In fact, I added  the 'unsorted members' categories just as
demonstration and speed test.

Another argument for 'figures' is this:
At the moment the items are listed in the tree.
Eventually the lists should be moved to a second tree below, where
some context buttons are shown. Additionally this would waste less
space and update time.
Then the current tree will only list the available categories and the
total numbers, which is afaik often called in English 'figures'.


Mattias