in Pointers & Delphi :: Take a look at your Delphi application, the one you are developing for many days (weeks, years) ... when you hit Compile - how many compiler warnings do you see? Zero? Bravo! A few? A dozen, hundreds? Do you find in the list the "Variable 'btn' might not have been initialized" warning? Are you ignoring it? You should not!
Read the full article to learn why you should Be Aware Of Uninitialized Variables
Related:
Ignoring “value of function ‘MyFunctionDontCareAboutTheResult’ might be undefined”? Do not unles you wont to spend a day wandering why your program desnt work in some cases but in mos of the cases it works OK. It happend to me becous I was ingnoring this type of messages. And luckily it was just a smal program, so I didn’t have a lot of code to … Večcheck, and this program was intended yust for my own use. Imagine how would it be when one of your customes cals you and says that your program just doesn’t work. That there are no warnings no Acces Violation messages. It could all be a reseult just becouse in certain case your function doesn’t return any meaningful result.
Now to explain what was the problem in my case. I had a certain function whose result was afected by comparing various results from some API functions. The whole function was based on a bunch if if..else if statments. And since I have been seting the result of a function only inside this if..else if statments it was posible that under some circumstances none of those if statments were true so no no result was defined. And since my program has been checking the result value from this function with case block it was posible that becouse function hasn’t returned any predefined value that simply no code was further executed. So you were clicking on a buttom bit it seemed that nothing is happening as that there is something wrong with the OnButtonClik procedure. And it took me almost about 6 hours until I first managed to recreate the problem, and then a few more hour before I figured out what is wrong. And then I also had debuger configured in a way that it didn’t even show me this kind of messages. And the reason for this was that then I was using some third party components wich were so badly designed that they have caused more than a thousand of theese kind of messages.
Now a days, if I found some third components wich raise so many warnings I first try to contact he component autor and ask them to fix this. But if they don’t fiy it I remove thiose components.
So even if some of theese warnings seems that they might not be dangerous they might cause some unpredicted behaviour of your software at certain ocasions. And usualy end clients manage to create all of these events wich you never even predicted.
I’ve no warnings in my 700K lines project
BUT to achieve this I have to disable some Warnings categories in project options, in order to not be lost in a flow of Warnings I consider not important (like platform ones.. etc.)
I have a disabled category that worry me : the one concerning Unsafe TypeCast. If I enable this category I’ve more than a thousand of warnings W1048 in my project.
Considering that VCL code is full of these warnings, I classed them as ‘not harmful’, so I kept this category disabled.
Opinions about this ? Do you also kept this one disabled ?
Could be Interesting to have a list of “Vital” warnings types that should never be disabled.
To make compiler recognize all kinds of errors only where appropriate is such a huge task. Indeed difficult because we all have our different ways of coding.
In the projects I make, I try to make coding so that Delphi Compiler can recognize and take warnings away.
Consider the function :
FUNCTION InvertBoolean(Param:BOOLEAN):BOOLEAN;
BEGIN
CASE Param OF
TRUE : Result := FALSE;
FALSE: Result := TRUE;
END;
END;
This function will make compiler produce a warning!
In this case, it can be ignored because we know the result will be set.
However, if making many functions or calculations or setting of variables within an expression or evaluation, the compiler will give a load of warnings and we may stop looking at them because there are so many.
The better way could be to initialize the result before the case statement.:
Result := FALSE;
That way, you get one additional line in your code, but warning message is gone.
Many things can also be rewritten. Consider :
FUNCTION InvertBoolean(Param:BOOLEAN):BOOLEAN;
BEGIN
Result:=FALSE;
IF Param=FALSE THEN Result := TRUE;
END;
This way, you initialize the variable, and you only check for whats left.
Simple as it is, it works wonders on minimizing compiler warnings.
Best regards,
Morten, Norway.
I wonder if Result:= not Param; would give a error, Like you said there are many ways to skin a cat….
This is off the point or warnings but I don’t even know why anyone would write that function. Call me simplistic but Param:=(not Param) works fine to invert a boolean value and is a lot more efficient.