[Lazarus] Hints usability (was: Re: Large program size - 1.8 MB for empty GUI project)

[Mattias Gärtner]

Zitat von Alexander Klenin <klenin at gmail.com>:

> 2009/4/9 Mattias Gärtner <nc-gaertnma at netcologne.de>:
> >> As I already written some time ago, the solution is to introduce a
> >> hint/warning for the circular dependencies in implementation sections.
> >> This hint should probably be disabled by default, for compatibility
> reasons.
> >
> > Yes, a hint would be nice.
> > But a hint won't be enough. It would go unnoticed too easy.
>
> This is another important problem. Easily unnoticed hints are just useless.
> There are two related causes here:
> 1) The message window interface of Lazarus is currently very weak.
>   (And it hides most of the hints by default, which I consider a bug in
> design).

What hints are hidden?


>   This interface is one thing I think is worth borrowing from Visual Studio.

Can you give more details for the people who don't know VS?


> 2) The compiler produces _many_ extraneous hints, which is very harmful --
>   it is impossible to produce hints-free code, so new hints has much
> more chances  to go unnoticed.

True.


> First point is IMO of "patches welcome" category (and perhaps I will
> provide some,
> but don't count on that), but the second one is more fundamental.
> There are two main sources of harmful hints now:
>
> 1) "Parameter unused".
> This is by far the main culprit. There are many cases when parameters are
> unused deliberately -- e.g. basic implementations of virtual
> functions, most events etc.
> OTOH, the hint is not _entirely_ useless and can in some rare cases
> point to a real bugs.
> The solution is to enable per-variable hint suppression. It is done in C/C++
> by omitting variable name, but I think a better way would be a
> compiler directive.
>
> I see two variants:
>  a) procedure TMyForm.Button1Click(ASender {$UNUSED}: TObject);
>  b) procedure TMyForm.Button1Click(ASender: TObject); {$UNUSED ASender}
>
> The first one is slightly messy in case of many unused arguments,
> while the second one avoids duplicating their names, so I am not sure
> which is better.
> Implementing either of them will fix the problem.

That's pretty much what I purposed a long time ago. I even implemented it once
via IDE directives.
But the code gets ugly and it worked only in lazarus.
A compiler solution with some synedit sugar might improve this.


> 2) "Uninitialized variable" for auto-initialized strings.
> See http://bugs.freepascal.org/view.php?id=0013341 and
> http://bugs.freepascal.org/view.php?id=13370.
> Both issues were resolved as "won't fix" which IMHO was done without
> considering full picture.

... or because they considered an even bigger picture than you.


> Here is my argument:
> There are two possible approaches to "non-initialized" warning:
> a) Do not guarantee anything about non-initialized variables, complain
> on their usage.
> This is C/C++ route. It is not entirely consistent there as well
> (global variables of simple types
> are still auto-initialized to zero), but that is their problem.
> b) Makes some guarantees about variable initialization and complain only for
> the variables which are not initialized automatically. This is Object
> Pascal/Delphi route.
> It does not warn about global variables, object fields, strings and
> interfaces since they are guaranteed
> to be auto-initialized in a consistent way (and programmers rely on that).
>
> FPC seems to take the third route -- it inconsistently warns[1] about
> globals, strings and interfaces but
> not object fields. This is the worst of both worlds and should be
> fixed one way or another.
> Compatibility and language tradition dictate retaining
> auto-initialization, but I am not principle
> opposed to removing it -- this, however, should be a loudly declared
> lack of feature/incompatibility
> and have a good reason.

Wrong list. Lazarus will not change the compiler.


> [1] FPC issues this warning even in Delphi mode, which is an outright bug.



Mattias