[commentary] The value of warnings [was: Re: A Data Object in Cocoa]
[commentary] The value of warnings [was: Re: A Data Object in Cocoa]
- Subject: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
- From: Stuart Malin <email@hidden>
- Date: Fri, 9 Jan 2009 08:01:32 -1000
From time to time I see questions arise and comments made about
disabling warnings. I am reposting commentary made very recently since
I believe it is a powerfully stated argument in favor of having the
compiler generate warnings (-Wall, etc.), and for writing code that
doesn't cause the compiler to emit them. [My apologies for being
redundant, but thought this perspective might be missed by those not
following the OPs thread on parameter naming.]
On Jan 9, 2009, at 5:28 AM, glenn andreas wrote:
On Jan 9, 2009, at 9:13 AM, Andy Lee wrote:
I haven't checked, but I suspect the compiler chooses the right
thing, since this is only a warning. Maybe someone knows a way to
disable the warning? In Java, I wouldn't be surprised if there were
a way to enable a similar warning.
--Andy
Don't do that - compiler warning exist for reasons: to help prevent
you from writing buggy code.
In this case the warning isn't that the compiler is going to do the
"wrong" thing (since it basically gets to define what is right and
wrong - and it is right), it's that your code (or somebody else's code
who has to later maintain this code) is potentially going to make a
mistake and use "label" when they mean the instance variable, and not
"label" the parameter (and then things will break).
Compiler warning are basically its way of saying "I'm going to do
something that you told me to, but it may not be what you meant, since
what you wrote could be ambiguous or have undefined results".
Fix the warning, don't disable it.
My small addition: I consider that warnings are less about what one is
doing in the very moment of composing code, but about interpreting
code in the future, because when when writing code so much unstated
context is alive in our head, but later all that (valuable) additional
context is (often) gone, and the code must stand plainly on its own.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden