Xcode 4 Looping output

Classic newbie mistake. Look very very closely at your for statement.

 

That's the other classic mistake. Assuming that since you wrote the code it must be correct, and suspecting your tools.

 

A very big clue.

Your exit condition is : n < 20

Your output is :

Code:

2012-01-23 11:16:16.393 Looping Program[995:707] 20
2012-01-23 11:16:16.397 Looping Program[995:707] This is line 20.

 

Your 'clues' are not terribly helpful

I've been a developer longer than you've been alive Knight...
And an approach like this where your'e really trying to make yourself feel superior isn't helpful to the poster, or to anyone.

If you've actually written much code - you know how easy it can be to let you mind gloss over something as small as a ;.... and once you miss it - it's hard to find.

Help the guy along. Your approach doesn't amount to teaching - it's all about YOU and not the poster.


To the poster - you've got a ; at the end of your for loop line... you're executing that loop correctly - but executing a null block... not the block of code below the loop. That code, below the loop, is executed once, AFTER your for loop is complete.

Knight is correct that you should learn to trust the tool. Question yourself. But you should also learn from mistakes, learn to be comfortable asking for help and not getting useless responses... and experience will teach you... there's nothing wrong with being new to this, as Knight would have you believe.


- Peter

 

Or maybe I was just trying to not give the answer to the poster at all. It's not about feeling big, but someone who finds the answer for himself rather than being told of his mistake actually learns something. In this case, the OP would have probably asked why the code in brackets still got executed, and we could have explained to him about unnamed blocks to explain why his syntax, while causing a logic mistake, was still valid.

I thank you for your multi-line insult however. I do have 1 question, how do you know how long I've been programming ?

 

That's why I didn't want to give you the answer straight. The IDE didn't pick up the mistake because there was none in the syntax. Your code as posted is quite valid.

See, and frankly, the operator was a big clue, along with the output. The way your loop was written, if it didn't have the extra semi-colon at the end, would have never print 20. Ever. It would have printed 0 to 19. That should have told you right there that the NSLog() functions were being called outside of the loop rather than during an iteration of it. The other clue, to look carefully at your for, should have explained why.

Basically, the loop was executing with no code other than the increment operator on n (n++). The loop only served to increment n until it reached 20. Then you had an unnamed block that contained your 2 NSLog().

That is why I took my approach, so that you learn to spot these mistakes yourself rather than always been told. So that you learn the symptoms and how to associate them with the underlying cause.

People like pfloyd might sound helpful when they straight up give you the answer, but in the end, you're not learning. Even after reading his post, you're still sure the IDE should have pointed out the mistake. Again, there was no mistake to point out, the syntax you used was perfectly fine.

After this post, if you still tell me I'm not helpful, frankly, I will be glad to move you to ignore and never try to give you clues so that you can find your problem yourself and then ask us why it happened instead of being told the mistake outright and not learning about all the useful diagnostic procedures to fix it next time.

 

KnightWRX: I don't think you did anything wrong, you pointed out the exact thing that was wrong.

Alberquerque: Just as an experiment, change your for look to look like this:

Code:

        for (int n=0; n < 20 ; n++);

And remove the declaration for the variable 'n' that you already have.

 

But now I'm sure from this experience that the OP won't make the trailing-semicolon mistake again.

Whereas if someone had just initially pointed out there was a misplaced semicolon, I think the OP would have just deleted it, posted back "thanks" and moved on; without having had this extended experience with the issue in order to drive the lesson home.


This has definitely been my experience with first-year Java students. If I tell them this problem straight-up, I have to remind them when they make the mistake again.

If I tell them, like KnightWRX did, to look very closely at their code; the discovery process seems to reinforce the lesson and they're much less likely to repeat the mistake.

It also serves as a good lesson to start paying careful attention to punctuation. Beginning programmers need to start training their eye to look at these small details, instead of glossing over them at it would be use to doing.

 

In my experience, this is a mistake.

I used to stay up late working on code at work. Really late. Then go in really late the next day (Yay flex-time). After a while, it dawned on me that I was spending half the next day fixing the bugs I'd introduced by staying up so late the previous night. Or the previous three nights.

Oh sure, the code would compile fine (OK, time to call it a night), but it wouldn't work, and sometimes the bugs were really subtle. Not so subtle that I'd have made the mistake if I was thinking straight when I wrote it, but subtle enough that they were a bitch to find in the overall mass of code.

And plenty of times there were just blatant stupid mistakes, where my first thought was "What was this idiot thinking" only to realize it was code I wrote a couple weeks ago in a late-night session.

So the short version is if you can't see it, it's well past time to stop. Get some sleep, look at it later. Who knows, you might even dream how to fix it (that's happened to me plenty of times).

 

Agreed. This was very subtle point KnightWRX was pointing out. I usually tell people to go into the debugger and start stepping through the code if they don't see the semicolon.

End of line "operator" is wrong. Eject this completely from your mind. End of statement "operator" is better. Statement terminator is correct.

This is not that situation. This is you posting code as a learner.

 

Why do you feel my pointing out your operator was trying to teach you about the operator ?

Again, I was only trying to make you realise that your loop was in fact iterating as written and that the NSLog() function was being called outside of the loop.

The operator was a big clue of this as printing 20 inside the loop was impossible. If your operator had been <=, it would have printed 21 and the operator would have still been a big clue.

In the end, I wanted you to find that semi-colon on your own.

As Jiminaus points out, had you posted then and there that you were still not getting what was wrong, I would have pointed out to use the debugger and step through the code while watching n. You would have seen it slowly increment while never going into the block, the cursor sticking to the for line until the loop ended. Pfloyd came in too fast with the answer, there was still some work to do in order to let you find this on your own.

BTW, I think you took the "newbie" comment as an insult. That's not what it's intended as. Don't feel bad about learning and being new to something, it's actually great that you are indeed trying to learn this. We've all been there, and I can tell you with assurance that everyone who posts here or even everyone who has programmed as made this mistake. I still make it from time to time when banging out code fast (either with if statements or loops) but I'm quick to find it because I know the symptoms (operators "not working as they should" are a big a clue, debugger stepping in a weird way like sticking to the loop condition line and not going into the code block), symptoms I tried to point out to you so that in the future, you too would be quick to find these weird runtime bugs due to proper, but quite erroneous syntax.

 

Another beginners mistake (not only beginners, unfortunately): Writing code when you're tired. Never do that. If you stop after working eight hours a day, it is better for your health, it is better for enjoying your life, and you are far more productive. If you continue writing code after that, you'll just spend more time fixing the problems that you created while you were tired.

 

Mistakes like this are sometimes like finding needles in a haystack. You're not really learning anything by trying to find that one mistake, you're just wasting time. To ask for a few extra pairs of eyes to comb over the haystack for the needle is fine... the person asking wastes less of their own time and a fresh new set of eyes can take a look. To have one person actually come in, say they've found it, and then not say where it is, well, that's just kind of rude and causes everyone's time to be wasted.

Making people learn on their own rather than asking every time they have an issue is one thing, but when it comes to an issue like this, I think it's fine to just point it out and they can get on with their task of trying to write some code that does something new that hasn't been done before.

Maybe I'm being too philosophical or something. Or maybe I'm up too late right now xD... I've been up 22 hours now and only had 3 hours of sleep last night...

 

Except this is not an example of a needle in a haystack. There are tons of clues as to why this is happening, as have been pointed out in this very thread. One should be able to find these mistakes on their own with a little experience, which the OP would have gained here (and let's hope he did after it was explained to him what these clues were).

 

If you work too long and are over tired, then looking for help on MacRumors is not the way to go. Finding ways to work fewer hours is it. A very important thing to remember is that working 40 hours a week actually gives you maximum overall productivity in the long run. You won't achieve more by working longer hours.

And I don't think people here want to "help" by acting as a human debugger. They want to help by teaching others how to solve their own problems. In this case, the information given was: 1. Look very close at the "for" statement (which is where the bug was, reducing the problem to finding a bug in a single line of code), giving the poster an opportunity to figure out _why_ that statement was incorrect. 2. Assume it is a problem in _your_ code, not something else - that is the biggest psychological obstacle to fixing your problems. 3. A hint that the output didn't match what the OP thought the problem was.

 

Wow! Assumption, after assumption as to the motives of others. I think you could, perhaps, learn a thing, or two, about others, before you presume to teach anybody anything at all.

 

So you're saying you'd rather act as a human debugger than help teach to people how to find problems themselves, is that what I'm getting from your comment ?

 

And you yourself refuse to learn anything about people and their motives.

 

It's not that I refuse, you have not offered the insight for us. If contrary to what Gnasher says, you aren't here to help teach people how to find their problems themselves, then what is your motivation ?

 

Considering that I taught people C programming in 1982 or so, this is funny.

 

I am here mostly to learn.

----------

And I've both taught and mentored people in problem solving and programming since 1979.

So what.

People here make so many assumptions as to HOW others should learn and not understanding not everyone learn like they do. Stop presuming everyone has the same motives and ways as yourselves - because they don't!