Re: Const qualifier conversion warnings
Re: Const qualifier conversion warnings
- Subject: Re: Const qualifier conversion warnings
- From: "Theodore H. Smith" <email@hidden>
- Date: Sat, 4 Jun 2005 21:52:19 +0100
On 4 Jun 2005, at 21:11, George Warner wrote:
On Fri, 3 Jun 2005 20:22:56 +0100, "Theodore H. Smith"
<email@hidden>
wrote:
I did that before, and then decided against it because of the amount
of work it was requiring from me.
This work is minor compared to debugging an unintentional
modification to
what should be a const variable.
I declare Left as const, but then Left calls another function to do
it's work. So that needs to be defined const too. But then that
function also calls other functions, and soon enough I'm having to
rework my entire class, that was already totally valid, simply
because of a complaining compiler.
The compiler is trying to save you from yourself. If a routine doesn't
modify a variable passed to it then it should be declared const.
It's ok to
pass a non-const variable as a const (you shouldn't get a warning
for this);
But it's not ok to pass a const as a non-const (since the routine
should not
be able to modify a const variable).
I see a compilers job as to be making my job easier. I know when code
is correct or not, and I know that that code is correct at least as
far as constness goes, so I'd like to be able to tell the compiler to
not make my job harder by complaining about stuff that's fine.
About ever other week or so I receive a project that a developer
wants me to
debug because they can't figure it out why it's crashing. The first
thing I
do is turn all the warnings and errors back on and pay attention to
what
they're saying. They weren't put there to annoy you. They're there
to help
you write better code.
George,
I know a thing or two about writing good code.
I regularly use assertions to validate anything assumption that my
code relies on. I write unit tests to throw the most twisted
scenarios imaginable, that are still valid scenarios, at my code. My
unit tests generally will execute every function, and aim to execute
every pathway of each function.
I split my files up if they are too long. I try to keep my function
length maximum around 20 lines or so, and just segment them into
smaller functions, each with a well defined purpose. I try to make
sure all my function names are clear, and that parameter names are
clear. I even try (as far as my environment allows) to make sure that
my types are clear, preferring u8, s16, u32, etc etc, to long, short
and int.
I use sentinels when I think I might be corrupting some RAM, or I
just don't feel like risking it. I try to modularise my code, making
sure I have the minimum code to do what I need to do. By having less
code do the same thing, I reduce the possibility of getting a bug,
and increase the maintainability of the code.
Once you know the rules well enough, you get a feel of when you can
bend, or even break them, and it actually works in your favour. I
think Steve McConnell of Code Complete actually wrote this in his
book, that for every example of a coding rule, there is almost always
a case when this rule can be broken for the best. Even a goto can
sometimes make code clearer, and I almost never use those things myself.
In my long experience of debugging errors, const correctness is just
not one of those errors that has caused me problems.
I have complained on these lists before, that Xcode was not giving me
*enough* warnings. And I've complained about times when the compiler
made something a warning that should have never passed. (like not
returning a value function a function that is defined to return a
value). Trust me, I totally understand what you are saying about
needing the compiler to make my job easier, by protecting me from the
fact that I am a human who does make mistakes.
I might have come across as not doing things properly on these
lists... Well I'm new to Cocoa and Xcode. I'm learning in general
here, and I've also learnt from your answers. That does not mean I'm
new to software development.
--
http://elfdata.com/plugin/ Industrial strength string processing,
made easy.
"All things are logical. Putting free-will in the slot for premises in
a logical system, makes all of life both understandable, and free."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden