Learn Java and logic with the debugger. Have I been cheating?
After taking a break from coding altogether, my way of thinking logically disappeared (as if it started with ...). I am not a master programmer. Intermediate at best. I decided to see if I could write an algorithm to print the fibonacci sequence in Java. I got really frustrated because it was something very simple and I used a debugger to see what was happening with my variables. resolved it in less than a minute with a debugger.
This is a lie?
When I read the code, either from the book or from someone else, I now find that it takes me a little longer to figure it out. If the algorithm is difficult (for me), I end up jotting down notes of what happens in the loop. A primitive debugger, if you do.
When you other programmers read the code, do you also need to record information about what the code is doing? Or are you a genius and just keep it?
source to share
No, this is not cheating.
I think if your sense of programming "logic" has dimmed a little, then the absolute, best, 100% way to update or even learn it is to watch the code in a debugger.
It's such a great idea that if I ever teach a beginner programming class, I have to have a computer running there in a debugger so students can watch what happens.
In response to your second question, if I really needed to worry about what the code was doing, I would start writing things. However, if I go through the code while navigating in Eclipse, I rarely have to write things down because the history of where I just was is readily available. However, if this story hadn't been recorded by the computer, I would have absolutely frantically scrawled on the pad as I moved around the code.
source to share
This was what I needed a while to figure out:
Understanding code written by someone else is not voodoo magic, it is just practice.
It is not a matter of intelligence and logic, truly, it is a skill that you develop, when in fact you need to understand other code. I really started to understand this and increased this skill while I started working as I needed to make changes to the code of others.
Don't be afraid, the more code you read, the easier it will be.
source to share
It is not "trickery" to use the debugger to find errors or to observe the behavior of your program, but you must be careful not to turn it into a crutch. Too much reliance on the debugger can also lead to " programming by accident ", which is also not very productive. Also, you really want to be able to conceptualize how something should work before you observe in the debugger if it works as you think it does.
Programming is basically an abstract, mental activity. You have to decide in your head how something will work (design), then you go and write the code (implementation). The more you can decide in your head how something will work, the more productive you will ultimately be.
As mentioned, there are many times when you cannot use the debugger. I think that in the long run it will be best for you to write your code to make it easier to understand its behavior.
source to share
Even the most seasoned programmers look for a debugger for answers and clarifications; or write a plain old printf to understand states; or write things down as they read / view another user's code.
I think that you are studying something, looking at what is happening under the hood, this is not cheating, but in fact you will have a clearer, more concrete understanding than just reading books and using it as an abstract idea.
No, this is not cheating at all.
source to share
In most cases, the exercise should get you thinking about what might happen in your code, rather than what is happening in a particular run. So running it a couple of times with a debugger might help, but you still have to do the generalizing work from those specific runs. For algorithms, this often means thinking about how paths grow with the size of the input. For concurrent programs, this means thinking about how the paths of different threads of execution will interact with each other in your code. The debugger will not tell you about this, however many times you run it.
Jumping with a debugger can only tell you what happened in one test; it will not teach you to think about your program in the abstract - it is one apple falling from a tree, not a theory of gravity.
source to share
It's good to use a debugger to try and figure out why something happened, especially in cryptic code, but it's best to try to predict what should happen first and then see if the debugger confirms your reasoning and intuition. In the future, this will help you write test cases that catch unexpected errors, and more and more often you will write code that works from the start.
source to share
Absolutely not! This is the complete opposite of cheating! The best way to find out what's going on is to get there in courage and see how it happens. Reading code from a book can be overwhelmingly boring ... but seeing it run in the debugger can be magical, especially if you're having problems with a particular section.
I NEVER release the code I wrote without running it in the debugger and observing almost all of it.
source to share
I agree that you were not cheating in a general sense. I can only see two cases where you might consider using a debugger as a trick:
-
you've set a bar for yourself where you want to complete the task at hand without any help like a debugger. Obviously, if you are using a debugger in this case, you might consider it cheating.
-
you have been instructed by your teacher or proctor to conduct the interview so as not to use external tools.
source to share
Well, it's a scam if you are middle class for a class and there is a "programming" problem that requires you to parse something on paper without running it. But I've always hated this kind of test, precisely because it didn't seem useful at all - it doesn't look like programming itself. And heck, even there, you'll probably still finish "running" it by writing intermediate processing in your notes.
I do believe not to rely too much on the actual debugger, because sometimes you have to rely on simpler debugging techniques (if, say, you are trying to debug a problem that can only be reproduced on a computer owned by a tester who does not want to you played on your computer). But even there, you still run the code and see what happens (and perhaps add "debug" messages or text-write-to-disk functions). Trying to read any program is much harder than "Hello World" without actually running it (even on paper), without avoiding trickery, that's masochism.
However, it's true, you start to do it less the more you've seen the specific language / class of the problem. But of course, if ever an error, even an error in the code, you've seen similar versions a million times over, the fastest and least painful way to find it is always to run the code and see what it does.
source to share
I think there is exceptional value in debuggers and they can be especially good as a learning tool. Sometimes you just need to diagnose a defect. However, I think that bad programming habits can arise if you constantly rely on the debugger when developing software.
A perfectly effective software developer understands the abstractions with which she works - languages, frameworks, OS - well enough to state her problem with the system and know that it is correct. Of course, this is an unrealistic ideal, but I think this is something to strive for. If you find yourself in the debugger a lot, it means that you don't understand your abstractions, and that means that you will move a lot slower while writing code. Even if you've dealt with this problem with a debugger, your ignorance will slow you down when you try to use features and functions.
Obviously you are in learning mode, so anything that gets you to that level of understanding depends on your learning style. If a debugger can help you get there, great. But if you want to be productive, it's a good goal to figure out where you can get the correct code, since you don't write it when you run it.
In connection with this question, there is Linus Torvalds' rant on debuggers, which I especially like:
source to share