[Lazarus] Hints usability

[JoshyFun]

Hello Christian,

Friday, April 10, 2009, 10:17:28 PM, you wrote:

>> In other words MY (capital, as it is my problem, maybe not the problem
>> of other people) is that the amount of expected hints are hidding the
>> non-expected ones.

CI> Right. And as I said, it would probably be more productive to disable an
CI> entire type of hints.

Well, I compile my code with all checks and it must be
error/warning/hint free before being considered ready. Hide hints even
of a given kind is not a solution to me, but of course it is better to
have a way to hide them, kind by kind than nothing.
The current Lazarus filter is fine for that but I only want to hide
the hints in the places that it is the expected thing.

CI> Ok, I can see what you're doing there. In my opinion, it's not very
CI> pretty. How about something like this:

CI> procedure SilenceHint(const A); inline;
CI> begin
CI> end;

Hmmm... I'm not used to use formal parameters, I'm always using strict
formats and simply forget that possibility.

CI> That should require only 1 procedure, and wont require search-replace
CI> because it will simply be optimized out.

Hmmm... not it will not be optimized out. Inline and formal parameters
are not compatible and if not using inline it will not be optimized out
at least not by FPC and I think the linker will not remove it also.

The remove maybe will be performed using global optimization, but I
can not test it.

CI> Still, I think it's kind of ugly ;-)

It is :)

CI> My original point is that the "uninitialized variable" hint is so common
CI> that it becomes practically useless in certain applications -- for
CI> example lazarus ones. If you could say, e.g:
CI> {$HINT UNUSED_PARAMETER OFF}

I really prefer something like {$UNUSED X,Y,Other,Sender}

I prefer to specify which parameters are unused by intention.

CI> I think my version works fine. You could even overload it to accept
CI> multiple argument, so you could do
CI> SilenceHint(Sender, X, Y);

Yes but that's a one specific shot, maybe good for one class, but not
for a generic use (this kind of overload).

-- 
Best regards,
 JoshyFun