Live data from Hacker News

What's wrong with this code, really?

cvmountain.com

161–170 of 217 posts

Re: What's wrong with this code, really?

#161

Earlier quoted context omitted.

I've noticed this "magic" thing too, among the most clueless members of our profession. Even if they have no idea how bad they are, which they usually don't.

You see this a lot (even on this forum) with people referring to Rails "magic", when it can't possibly be anything but a bunch of lines of code being executed according to the rules of a certain interpreter.

Rails magic is vastly different from the magic referred to in the gp. Rails uses a number of dynamic approaches that create results that in other frameworks would take some amount of explicit configuration. The word "magic" in this context is ironic and merely means "dynamic".

Re: What's wrong with this code, really?

#162

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…

If the candidate picks up on the fact that the code is ugly and should be rewritten, and then is able to explain why, then I think the question is worth it. It weeds out the people who honestly don't see anything wrong with that kind of code.

Re: What's wrong with this code, really?

#163

OK, fairly newbie coder here.. What would be wrong with just setting a variable to the value of 'this.MyControl.TabPages.Count' outside of the for loop and refering to this?? ie; var x = this.MyControl.TabPages.Count; for ( int i=0 ; i as a quick fix, or if someone did not know while loops or clear function??

Well, what happens when you try to remove the 10th page when there's only 1 left? As a rule of thumb, don't ever rely on indexation in a collection if you do random deletes. Usually you'll just blow up your app gracelessly. Sometimes, epic failure ensues. Through some feats of logic we might deduce that there's always a first element, though, until the collection is empty. So you might do this inside the loop: MyCont…

[deleted]

Re: What's wrong with this code, really?

#164
post #64

Earlier quoted context omitted.

This is the second time you said that in this thread, now I can't restrain myself anymore - 'list' != 'array', and it all depends on how they're implemented; I see no reason to assert that for 'most implementations' removing from the end is faster. For a single linked list, it's faster to remove from the start. For a double linked list, it doesn't matter (well it depends, it could be slower). For a 'we call it a list…

He post you are actually responding to answers your questions. Javascript and Python are mentioned.

"Lists" in python are not in fact lists (as the term is traditionally used to refer to linked lists). They are array backed. I expect "arrays" in javascript are similarly arrays...

roel_v is correct to point out this misunderstanding.

Re: What's wrong with this code, really?

#165

Earlier quoted context omitted.

I'm genuinely curious -- why? The last time I coded my own linked-list, it was doubly-linked, so deleting either the head or the tail was exactly the same.

And for singly linked lists, deleting the last would be O(n), while the first would be O(1) (just change the head to point to the next node). Parent has a point for arrays/arraylists, though, you need to copy everything after the element.

Singly linked lists can still maintain a tail and before-tail pointer, maintaining O(1) tail operations.

Re: What's wrong with this code, really?

#166
post #62
post #7

Deleting from a container while you are iterating over it should always raise red flags.

Depends on what you want to accomplish and what your container and iterators support. If your Iterator offers a delete method, I think it's a very elegant and clear way to filter a container. for (Iterator it = container.iterator(); it.hasNext(); ) if (!predicate(it.next())( it.remove(); It's more ugly and error prone if you've got to juggle an index, though.

Discussion about iterators removing anything aside, I don't think your example disagrees with the parents point. His point was that iterating over a containing while removing items should raise red flags. And it should, always. You should always inspect such loops with more scrutiny because more things are going on, and it's surprisingly easy to get such code correct as multiple things are changing out from under you.

In the systems class I TAed, when students had memory corruption problems, removing items while iterating over a linked list was at the top of my list of things to look for.

Re: What's wrong with this code, really?

#167

Earlier quoted context omitted.

The code was unacceptable from line 1 onwards, and would not pass code review with me on watch. For one, for loops have invariants . Next up, you are altering the loop bound in the loop. I do not care if the code works, the code is hard to reason about when it goes all non-linear like that. Finally, there is a goddamn Clear method. That is the kind of code you see the next morning and delete; hoping none of your peer…

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.

Re: What's wrong with this code, really?

#168
post #27

About the McConnell quote: "Inefficient programmers tend to experiment randomly until they find a combination that seems to work." The essence of this quote is being passed around quite often these days. When you first start programming, you generally have no idea what the hell you are doing. You learn all these strange, abstract concepts best, by experimenting. It's easy to dismiss people "jiggling things around unt…

I blame JavaSchools for this. Computing education should be started in Scheme or Python, without all that accidental complexity-- "public static void main(String[] args)"-- littered around the first program. To absorb all of that requires more than should be expected before people can write a first program. JavaSchools get people used to magic incantations that create a culture where inadequate knowledge is the norm.…

My CS degree program was primarily taught in Java. This was not a problem. Language syntax had little to do with conceptual understanding. I appreciated graduating with a firm grasp of a popular language's syntax and core libraries in additional to an understanding of CS theory.

Can you name a school that teaches a student only one CS course expecting them to be a programmer?

Re: What's wrong with this code, really?

#169

Earlier quoted context omitted.

Premature optimization is the root of all evil, but removing from the beginning of any array-based growable structure rather than the beginning will turn a O(n) operation into an O(n^2) operation. And you don't know what's going into those tabs. That cliché shouldn't be used to excuse positively brain-dead choices.

but removing from the beginning of any array-based growable structure rather than the beginning will turn a O(n) operation into an O(n^2) operation. I'll bite: in arrays, front deletion (like back deletion) can be done in O(1) time. Keep a pointer to the first element, and just increment it upon front deletion (and free the element if necessary). Obviously, you may want to be smart to avoid memory use getting out of…

> I'll bite: in arrays, front deletion (like back deletion) can be done in O(1) time. Keep a pointer to the first element, and just increment it upon front deletion (and free the element if necessary). Obviously, you may want to be smart to avoid memory use getting out of hand.

Actually that's how they often do array-based queues and deques. To help with memory use they let the tail pointer overflow through the end (so you could have tail at index 2 and head at index 8).

Re: What's wrong with this code, really?

#170

Earlier quoted context omitted.

And for singly linked lists, deleting the last would be O(n), while the first would be O(1) (just change the head to point to the next node). Parent has a point for arrays/arraylists, though, you need to copy everything after the element.

Singly linked lists can still maintain a tail and before-tail pointer, maintaining O(1) tail operations.

So after you delete the last element, how do you get the new before-tail pointer?

If you recalculate it right there, you've actually done nothing in terms of the algorithmic complexity. If you defer it either until it's needed or until you next enumerate the list, then you get to O(1) in the case of individual removes at the end (as long as they're interspersed with other operations), but you're still O(n^2) for removing the entire list starting at the tail.

Post reply on HN