Does everyone get tested this way in computer science class?

It seems that a lot of high school computer science classes still use visual basic 6 for learning to program. At my school, our tests have these things called "output questions" where you have to follow the code and write down the output. The only problem with these is that my teacher will create really dumb variable names like "haha", "hehe", or even more confusing ones like "heha" and hahe." All the functions and procedures will be named the same way, and it gets really confusing when loops are thrown in. I find it to be a really stupid and pointless method of testing because all that it tests is my ability to follow incoherent code. I can create better and more complex programs than the majority of my class, but when it comes to the tests, I end up getting in the low 70s or mid 60s. I don't know if I should complain to the teacher about it, because if I can program, why should I need to know how to do this? Ya so anyway, is anyone else tested this way?

Quote:

---

Originally Posted by chees

... I find it to be a really stupid and pointless method of testing because all that it tests is my ability to follow incoherent code. ...

---

Question rather belong to General Developer Forum.

Anyway... That is actually quite important - if you decide to proceed with the programming carrer then you will be working with somebody else's piece of art and that means you have to be very patient... But I leave the rest for the rest of the gang... :) Say hello to your teacher - he is a good one. :wave:

Yeah I went through that, although not quite as confusing as that.

To cut your answer short. Yes I went through it, and yes, it has some relevance to programming, despite its pointlessness.

for a bit more lengthly answer:
It's apart of the syllabus, so we had to learn it. It does come useful when you're debugging programs. Helps me alot.

Even if you can write better and more complex programs than the rest of the class, what happens when there's an error in a sub that you had variables in? You may have to trace through the variables (VB always allow you to see what is stored inside the variables at debug mode - try it. Create a buggy program and debug it. Then move your mouse over the variable :D).

Whoops, I didn't notice I posted in the vb classic forum, I thought I was in the general forum lol. Is there a way to move the thread?

Besides that, if I were reading somebody else's code, wouldn't it be a lot easier because they would have commenting and variable names, which would be directed to the situation. Like the names "haha" and "hehe" are thrown in purely to mess me up.

Or better yet... have some one ELSE write a buggy program, and YOU debug it....that's more likely to be the case in the real world. It isn't stepping in your code, but through something someone else wrote...... months ago.... or years ago....

-tg

Quote:

---

Originally Posted by chees

Whoops, I didn't notice I posted in the vb classic forum, I thought I was in the general forum lol. Is there a way to move the thread?

Besides that, if I were reading somebody else's code, wouldn't it be a lot easier because they would have commenting and variable names, which would be directed to the situation. Like the names "haha" and "hehe" are thrown in purely to mess me up.

---

As I said "say hello ..." and be thankfull you have him - many wouldn't even bother with this stuff (boring but extremly important).

I agree that it is a very useful thing to experience - as it does come up in the real world fairly often, even with code you have written yourself.

There are some objects which have properties with similar names, and there is obviously a need to differentiate between them. At times you will also find that you accidentally create variables with similar names to existing ones (especially in larger routines).

As TG and RB said, there are many times that you will get code that someone else has written (either "inherit" a program from a collegue, or get examples from the web etc), and you will rarely find that things are named or commented as you would like them to be. As kregg said, it is also a very useful skill when writing your own programs - as you are likely to make some mistakes every now and then, and this kind of work is what you need to do to find them.

The fact that you are getting 'low' grades for this is not good, but I'm afraid it isn't the fault of your teachers naming scheme that you can't accurately follow what the code is doing.. I presume it is simply because you are going too fast, and mis-reading the variable names.

Quote:

---

Originally Posted by chees

Whoops, I didn't notice I posted in the vb classic forum, I thought I was in the general forum lol. Is there a way to move the thread?

---

Only Moderators and Admins can move threads - so I have moved it for you.

Well it does get really confusing when you have procedures and variables that have the same name.... I didn't even know you could do that lol. Time constraints are also a problem to I guess.

Maybe it has something to do with math abilities, cause that's the only other thing I mess up frequently in.

Quote:

---

Only Moderators and Admins can move threads - so I have moved it for you.

---

Thank you :)

They are pretty bad names, and as everybody has said, you will benefit from debugging that crap. However, is this only on paper, and what tools are you allowed to use? I can think of a couple of potentially useful techniques if it is only on paper, and others if it is on a computer.

On Paper:
You are having trouble tracking variables because they are similar? Make them less similar! When you first get the code, go through it marking each variable in a unique way. This will probably work on a test, because there likely are not all THAT many variables. If you can use highlighters, simply make one yellow, one blue, etc. If you only have a pen or pencil, then circle one, underline another, etc. The key is to make similar names readily identifiable before you get into the code.

On any computer system:
Same thing! Search and Replace, baby, search and replace!!!

Quote:

---

On Paper:
You are having trouble tracking variables because they are similar? Make them less similar! When you first get the code, go through it marking each variable in a unique way. This will probably work on a test, because there likely are not all THAT many variables. If you can use highlighters, simply make one yellow, one blue, etc. If you only have a pen or pencil, then circle one, underline another, etc. The key is to make similar names readily identifiable before you get into the code.

---

Wow, I never thought about making them different. Highlighting seems like a great idea. I'll keep that in mind when the next test comes up. Thanks!

Quote:

---

because all that it tests is my ability to follow incoherent code.

---

Writing incoherent code is an ability possessed by many programmers.

Quote:

---

if I were reading somebody else's code, wouldn't it be a lot easier because they would have commenting and variable names, which would be directed to the situation

---

It certainly would, if the original coder did put in comments, useful variablenames and indentation.

As RhinoBull said, you will at some point have to work with someone else's code and not everyone writes code with having it read by others in mind.

For a nice example, dig up some old code that you wrote a long time ago and try to make sense of it.

We had to do this in final year I.T. But, our teacher gave us exercises which really helped.

Basically, say you are tracing a loop. Make a table on paper of variables vs. iterations, e.g.:

Code:

---

        1  2  3  4  5  6

haha

hehe

hoho

---

and fill in the cells as you go through. It makes it very easy to see at a glance what every value is.

I still use this technique sometimes when manually tracing a bit of tricky code.
As you develop skill at this you will find you can start to do more of it mentally, and with properly named variables you can usually trace the whole thing in your head.

As for getting muddled - we all do that at the beginning. Work through it a bit more slowly and logically to start with and build up your ability at it.

Quote:

---

Originally Posted by chees

Besides that, if I were reading somebody else's code, wouldn't it be a lot easier because they would have commenting and variable names, which would be directed to the situation.

---

You should see some of my code then. :eek:

I comment the heck out of code I expect somebody else to read. If I only expect me to be reading it, some things don't get commented. After all these years, I have a style, and can read my style well. Certain variables pop up again and again in my code (like st1), but I always use them the exact same way (out of habit, not some documented reason), so I always know what role they serve.

Now, if somebody ELSE were to read my code, it might take them a little while to learn the style. My function and class names, as well as most variable names, are actually fairly verbose and informative, but I sometimes find myself adding huge amounts of comment to code when I have to fix something. If I am adding lots of comments upon review, then they should have been there to begin with. Upon reflection, I would say that only about half of my code is well-commented.