On 09 Jan 09, at 15:41, I. Savant wrote:
On Jan 9, 2009, at 1:01 PM, Stuart Malin wrote:
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.
I believe comments and documentation are the best way to handle
context (so it's not "unstated" :-) ), but I admit that not only
have I not thought about this as an argument for -Wall et al, but I
find I agree 100%. Well said.
I'll add one of my own favorite statement: A computer is just like
an under-socialized geek - it takes everything *way* too literally.
Do you really want to trust that it "gets it"?
Not to mention, there is no guarantee that future versions of the
compiler will behave identically when processing code that generates
warnings. It is not uncommon for warnings to later turn into errors,
or (worse!) incorrect behavior, especially when optimizations are
involved.
Warnings are generally easy to work around when they're false alarms.
Turning them off, or ignoring them, just means you'll miss the serious
ones.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
