find the bugs

[Gianni Mariani]

zeppe wrote:
....

What's wrong with ignoring arguments? For me, a bug is something that:
- makes the program crash
- doesn't make the program compile (but I would call it error as Ian
pointed out)
- makes the program act differently from what I want.

.... ooh ... there is is. Unexpected behaviour. It is reasonable to
expect that any argument put on a command line is used and if it is not
used then it should be noted by the parser with at least a warning.

.... That is, if

nobody tells me that the program shouldn't ignore input arguments, I
assume that this is legal. It may seem a rather rigid reasoning, but
this is an interview question, it's not a real program, in which case I
would ask what is the program for, before making assumptions.

If you were in an interview with me, you would get extra marks for being
thorough in explaining that silently ignoring command line arguments is
unexpected behaviour. It's a common sense thing.

Correct parsing should be:

if (argc < 2 )
{
std::cerr<<"Need ???NAME??? parameter to command "<<argv[0]<< "\n";
return 1;
}

you decided that there should be at least a parameter? and based on
what?

Based on what I expect a command line parser to do.

.... You know nothing about this program, and for me it seems like it

produces a result even without parameters. And, as far as we both know,
it may be the correct (expected) result.

if (argc > 2) {
std::cerr<<"too many parameters passed to command "<<argv[0]<<"\n";
return 1;
}

again. You are imposing restrictions on your own account.

YUP. That's right. I want the program to tell me how to use it unless
specified otherwise.

or probably a precondition on lookUpName, I would say...

Not specified. You need to find out in the interview, the best way it
to specify it as an error and find out otherwise.

You made good comments about pieces of code that are questionable, and
that's good. The only thing is that you weren't required to do so, but
just to find the errors.

That's IMHO, of course...

probably, if the interview context would have been appropriate, after
having pointer out the two error I'd have spent some words on the parts
of code that are "weak" in terms of behaviour, that are more or less the
ones that you described (but there would be a lot, for example that it's
so bad mixing char* and std::string, and that there is no reason not to
use only std::string, make the interfaces uniform, etc.).

I have conducted many interviews and hired many programmers. I can tell
you that if you don't point them out, you're not doing as well as
someone who does. Wether you call them bugs or "different to what I
expect" is irrelevant.

I also often ask what are 2 problems when there are 4 or more. But then
again, I also don't hinge the entire interview on one bad question or
bad answer.

There are 3 stages to any inteview, the first is determining if the
candidate "can do the job" which is pretty easy. The next stage is
trying to figure out "will the cadidate do the job", which is much
tougher to answer, the final question is "can we handle this guy in our
team".

When you start pointing out nice things about how you try to do what is
expected (i.e. not dropping arguments silently) it starts to answer the
more important aspects of the interview.

 

[James Kanze]

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.

 

[Ian Collins]

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.

Exactly! I implied from your response "if this code were checked in,
and I had to compile it" that you were talking about code that was
checked in *and* visible to others.

 

[James Kanze]

Exactly! I implied from your response "if this code were checked in,
and I had to compile it" that you were talking about code that was
checked in *and* visible to others.

Actually, I suspected such.

On the other hand, in real life, for various reasons, we're
often called on to maintain code that shouldn't have been made
visible to others. You don't mean to tell me that you've never
been given a pile of shit, and been told to make it smell nice.

 

[Ian Collins]

Actually, I suspected such.

On the other hand, in real life, for various reasons, we're
often called on to maintain code that shouldn't have been made
visible to others. You don't mean to tell me that you've never
been given a pile of shit, and been told to make it smell nice.

All to often, once managers or clients realised I was good a deodorising
code!

 

[Sylvester Hesp]

a std::string can not be null. If lookupName returns a NULL pointer, then
the line before this one will be in error, you can not assign a
std::string a null pointer. In my compiler when I run it I get memory
access reading location 0x00000000.

That is true, but you know nothing of the definition and behaviour of the
lookupName() function. A valid precondition can be that the passed char* may
be 0, and it might return a std::string rather than a char*. Therefore, you
cannot say whether this is a bug.

- Sylvester Hesp

 

[Jim Langston]

That is true, but you know nothing of the definition and behaviour of the
lookupName() function. A valid precondition can be that the passed char*
may be 0, and it might return a std::string rather than a char*.
Therefore, you cannot say whether this is a bug.

I can say that
if ( name == NULL )
is a bug because the condition can never be true. Which is what I was
saying.