Re: find the bugs
On May 6, 3:03 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On May 5, 10:55 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On May 5, 12:15 am, Ian Collins <ian-n...@hotmail.com> wrote:
ak wrote:
Recently at an interview i was asked the following question :
Assuming the function lookupName is defined, what's wrong with this
code (hint: 2 bugs)?
const char *getName(const char *c) {
std::string name = lookupName(c);
if (name == NULL)
This isn't a bug, its an error.
What's the difference?
My understanding of a bug is defective behavior that compiles.
Comparing a std::string with 0 is a compile time error.
I don't like the word bug, to begin with. Both the problems
here are programmer errors. Bug sounds too much like something
that crept in despite the programmer.
In the generally accepted sense, however, a bug ceases to be a
bug once it has been fixed. "Bugs" that are signaled by the
compiler don't stay in that state very long, and don't make it
into released software (so a user wouldn't consider it a bug,
since he'd never see it). On the other hand, if this code were
checked in, and I had to compile it, I'd certainly consider it a
"bug".
The real bug is in the process that lets you check in untested code!
What does checking something in have to do with it? A
developer should be able to check code in at any time, in order
to be able to back out of whatever he's doing. The important
thing is that checked in code doesn't become visible until it
has passed code review, the regression tests, and everything
else.
Allowing code to become visible to other users before it has
passed code review, regression tests, etc., is a serious error
in the process. But you don't want to throw the code out, just
because it hasn't reached that stage, and the author isn't
available any longer. And of course, most companies also have
to deal with legacy code, which was written before modern
software processes were introduced. Realistically, every
professional, in his lifetime, will be called on to deal with
such code.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34