What's wrong with this code, really?

Post by [deleted] » Sat, Sep 17, 2011, 1:10 AM UTC

kragen wrote: post #167

trevelyan wrote: post #137

Earlier quoted context omitted.

Perhaps the programmer wanted to run test functions on the objects as he deleted them? Or perhaps the data structure is a vector of pointers in C++, in which case using the standard clear method would introduce a massive memory leak. There are a lot of reasons why someone doing difficult work with complex objects would use a loop to delete them, and using invariants is only possible if you have immutable data structu…

> using invariants is only possible if you have immutable data structures. Wow, dude, maybe if you don't know what the words mean, you shouldn't argue about them.

Post by palish » Sat, Sep 17, 2011, 2:06 AM UTC

tspiteri wrote: post #106

palish wrote: post #13

Earlier quoted context omitted.

No, I pretty much just recoiled in horror immediately. Even if I had to avoid .Clear(), there are immediately-obvious, better ways. while ( !thing.Empty() ) thing.Remove( 0 ); In fact, the code isn't just bad; it's risky. What if someone changes "int" to "uint"? It wouldn't even infinite loop / crash... It would remove exactly one element!

What if someone changes "int" to "uint"? It wouldn't even infinite loop / crash... It would remove exactly one element! I can't see that. If i is a uint, at the end of the first cycle, i-- changes i to the maximum uint, then i++ changes i to 0, then i while ( 0

Post by codeslush » Sat, Sep 17, 2011, 2:22 AM UTC

codeslush wrote: post #184

When pressed for a deadline, a demo, a functioning "something" - I do stuff that might not be the right way to do things because I need to get it to work. If the code ever has a chance of being witnessed by someone else, I always try to: /* Can't find a clear/remove method, don't have time to screw around with it now, might revisit later, might not. Sorry. */

Post by [deleted] » Sat, Sep 17, 2011, 4:36 AM UTC

hammock wrote: post #178

raganwald wrote: post #12

The article's point about writing code that does what it says it does is fine. But as an interview question, I have trouble imagining that candidates won't figure out that this is a game of "guess the answer I'm looking for" and say that they would rewrite this code. A better question would be, there's tremendous deadline pressure, the company is in imminent danger of losing a giant deal if we don't have working code…

I am not a programmer, so I did not know about the clear() method. I thought it was a rather elegant solution! I guess it's all about perspective.

Post by Confusion » Sat, Sep 17, 2011, 7:19 AM UTC

jbri wrote: post #23

shabble wrote: post #9

Earlier quoted context omitted.

The other nice thing about running it in reverse is that the .count method (assuming it's a method and not a property), needs only to be accessed in the initial condition setup. If you're accessing the size of, say, a linked list, you end up sneaking an O(n^2) runtime because it has to re-count the size of the list every iteration to check for termination. c.f. https://secure.wikimedia.org/wikipedia/en/wiki/Schlemiel…

Though you have to be careful with that, because the obvious code for removing from a collection in reverse: for(i = list.size; i >= 0; i--) list.removeAt(i); Is itself a schlemiel algorithm on any singly-linked list...