84 replies to this topic

[Uziel2101]

The best engineer is a lazy engineer

I've been programming with that motto in my head for 17 years.....

P.S... Visual Studio debugger is a god send! I can put breakpoints directly on memory addresses!

[Cornstalks]

P.S... Visual Studio debugger is a god send! I can put breakpoints directly on memory addresses!

You can in GDB too...

br *0xdeadbeef

^^ break when $pc == 0xdeadbeef

edit: but yeah, Visual Studio's debugger is quite nice

Edited by Cornstalks, 20 September 2012 - 11:23 PM.

[mhagain]

Sure it's lazy, in much the same way that shopping for food and clothes is lazy when compared to hunting mastodon.

On the one hand your professor sounds like the cliched typical academic, so long out of the real world that he's lost touch with everything, and a head full of theory and idealized perfection but no practical experience whatsoever. That's on the one hand, but on the other...

I recall one of my lecturers in college coming up with a similar tale of laziness (it wasn't to do with using a debugger because debuggers as we know them today didn't really exist back then, but I can't recall exactly what), and proceeding to talk about it for a while. Then he dropped the bombshell: "all good programmers are lazy" - and proceeded to list of reasons similar to those given upthread (using the most effective tool for the job, etc). So it is possible that your professor is leading you in that direction too, although he seems to have an odd way of going about it.

For your own benefit, you should never underestimate the power and usefulness of a good debugger. By definition all non-trivial software has bugs, so even if you are a careful programmer and make every effort to do things right, you're going to have bugs and things will go wrong. Without a tool to help you identify and analyze what went wrong you will very likely end up reduced to hacking at code in the hope that something random you change makes it go away - not always, sometimes you'll be able to pinpoint an exact cause from the bug report, but often enough to be a huge drain on time better spent being productive.

I need to take issue with the "debugger as tool of last resort" thinking some have expounded upthread. I also use a debugger as a "prevention is better than cure" tool, so all new code is always developed and initially tested using debug builds. Always. If you can catch bugs when they're first introduced you have a smaller surface area to deal with, and any changes required by the fix are more likely to have a much smaller impact on the codebase as a whole. Of course differences between performance and behaviour of debug builds and release builds mean that you should test your release build too, but the saving in time and stress achieved by this approach is immense (and that gives me more time and energy to devote to productive work).

[Olof Hedman]

Debuggers can't save bad programming.

But debuggers make good programmers even more productive.

If they didn't, they wouldn't exist in the first place.

[swiftcoder]

If they didn't, they wouldn't exist in the first place.

That's not a very valid philosophy right there. Try applying it to Hitler, or Windows ME.

[Hodgman]

When I first took computer classes, we were taught to "desk check" all our code before running it (or even typing it into the computer). You'd walk through your code on paper, keeping track of the state of variables, making sure everything worked as it was supposed to. You'd repeat this with a bunch of different inputs, especially all "edge cases" -- such as values right on either side of a branch condition.

These days, I use a debugger for this. I don't consider any code "done" unless I've watched it function line-by-line via my debugger.

There's been quite a few times where my code has looked correct, and I've even added it to the latest build because it looked like it was working, but then upon stepping through the code it becomes plainly obvious that I've written a "<=" instead of a "<", or an "i++" instead of a "++i", or a "+1" instead of a "-1" etc, etc, which only would've shown up in a bug report in a few months time when someone actually used some rare edge case of my system.

[Zomgbie]

To me, using a debugger is a calling for good programmers. When I meet someone that knows the value of a debugger, I always tend to think higher of said person.

I write my code, and let it run. Then I observe the behaviour of my program. Does it consume more memory then it should? Is the output unexpected? Did it crash? If something missbehaves, I usually know where i could have failed. But when i can't find the error my self, the debugger is where i turn for help.

So as many other people already mentioned, build your code without relying on the debugger, but use it as much as you want when you need it!

[Madhed]

I wouldn't have thought that this thread would stir up such a controversy.

IMO a debugger is an indispensible tool in a programmers hands. The reality for most beginners is that they don't even know that such a thing as a debugger exists. They spend endless hours cluttering their code with printf's and log calls when the right tool is just a click away. (I know I did many years ago)

I didn't even think that one could abuse a debugger but it seems every case exists.

[swiftcoder]

I didn't even think that one could abuse a debugger but it seems every case exists.

I don't think it is so much a case of abuse, as a case of dependency.

I have no problem with a programmer who uses a debugger often and well. But he damn well better still be able to debug his code in an environment where a debugger isn't available, and he damn well better be able to walk through the entire execution of his code on a whiteboard.

[Promit]

Most of you would do well to listen carefully to swiftcoder, as the debugger issue is a bit more complex and subtle than it seems at first glance. Indeed, I would suggest a handful of necessary but not sufficient criteria for a competent software engineer:
* Able to effectively debug problems in a debugger.
* Able to effectively debug problems without a debugger, but with other runtime tools. Very common in games, kernels, distributed systems, high performance or GPU computing.
* Able to effectively debug problems without ANY runtime tools. This one is hard, as it rules out printf, visualization, etc.

There are competing aspects of competence here. You have a large variety of tools at your disposal as a programmer, in fact an extraordinary amount compared to most other disciplines. It is important to be able to work your way around all of these tools at various levels. I hate doing the vi/gcc thing for example, but I can and occasionally need to. The counter point is that there are an awful lot of situations where, for whatever reason, your tools are highly ineffective.

Why do production games now have major custom debugging suites in games and toolchain? Debuggers are one tool that serve a particular purpose. Sometimes this purpose is inappropriate, as in the case of tracking how values evolve over time. Sometimes the tool itself is non-functional; I work with a robot system that expects its host to maintain a certain response time, which means that a debugger will crash it if I try to pause the host software. There are a large and exciting variety of situations in which debuggers will generate no results or worse still, deceving/confusing/blatantly wrong information. There's also my favorite: attaching a debugger fixes the problem. This is very common with multithreading heisenbugs.

It's critical that you are able to use all of your tools, including but not limited to debuggers. It's also critical that you're able to use your brain, as many problems are fixed much more quickly by reasoning critically about the nature of the issue, or applying other techniques such as binary search through a revision history in the case of regressions. Being multitalented and adaptable is key.

[Codarki]

I have no problem with a programmer who uses a debugger often and well. But he damn well better still be able to debug his code in an environment where a debugger isn't available, and he damn well better be able to walk through the entire execution of his code on a whiteboard.

I'll quote you just for the typo

"But he damn well better still be able to debug his code in an environment where a debugger isn't available"

Debugger is essential. But, many times close to the release, when build times takes 30min and starting the debugger another 30min, you do not want to program against debugger. Swiftcoder is right, you must be able to type bug-free code, and find typo-bugs and logical-bugs without debugger too. Debugger doesn't always help in release-only builds (it's the worst feeling when release has a bug but debug build wont catch it).

Edited by Codarki, 21 September 2012 - 03:04 PM.

[Cornstalks]

I have no problem with a programmer who uses a debugger often and well. But he damn well better still be able to debug his code in an environment where a debugger isn't available, and he damn well better be able to walk through the entire execution of his code on a whiteboard.

I'll quote you just for the typo

"But he damn well better still be able to debug his code in an environment where a debugger isn't available"

I don't see the typo...

[swiftcoder]

I don't see the typo...

Codarki's point is suggesting it isn't 'debugging' without a debugger. That's probably an issue for a different discussion, but I would disagree - one can find bugs (i.e. through testing), and fix them, all without ever touching a debugger.

[Cornstalks]

I don't see the typo...

Codarki's point is suggesting it isn't 'debugging' without a debugger. That's probably an issue for a different discussion, but I would disagree - one can find bugs (i.e. through testing), and fix them, all without ever touching a debugger.

Ah, I see. Yeah, I'd say they're separate, but both are important.

[Codarki]

Corn, I see I was wrong. I've debugged release a lot without debugger.

I think posts 49 and especially 50 were spot on, I have no more to add.

[kuramayoko10]

Through college I've seen many people coding without a debugger. Most of them didn't know what they were doing neither were producing good code.

I am of those that believe: "If you think you have reached the truth (right output), then you probably messed up somewhere".
There is a rule for this... something like "From a false statement, any conclusion is true".

I do not accept a right output at first execution. And I can't see how a good programmer should.
The use of a debugger is pretty much essential to me to walk thourgh my code and "desk check" some tests and watch over variables.

The right output is just one objective of the code. I have to make sure that the code is achieving it the right way [knowing that the right way depends on the problem].
So if there is one tool out there that helps me achieve that, I will certainly use it.

I don't think every good warrior should fight with his fists. If he can wield a sword well, he should use it.

[sundersoft]

I almost never use a debugger because:
-I usually have a good idea of where the bug is; it's usually in the last code you wrote (assuming you're testing properly). The code's errorneous behavior is also usually enough to determine roughly where the bug is. Having to look at stack traces and whatnot takes a good amount of time and it's usually not necessary to know exactly where the bug is.
-My approach to fixing bugs is to look at the relevant code and try to improve it. I may find other bugs that I didn't know about or I may find that the code or variable names are confusing. I may also decide that the method I'm using is naturally error prone (has many special cases, etc) and that I should rewrite the code to be simpler. With a debugger, I normally find the bug, fix it, and leave, so the code quality is not improved much. I'd rather spend time looking at the code than using a debugger.

When I do use a debugger, it's usually to generate a stack trace for an uncaught exception or segmentation fault. Although well written C++ code shouldn't throw many exceptions or have many opportunities to segfault, so I very rarely use the debugger. I normally do printf-style debugging since it's faster than using a debugger to generate the same information if you're lucky, and since I prefer reading log files over suspending the program every time I want data.

I also hate Visual Studio because it gets in my way so much. You should just be able to write text without having a box suddenly pop up on the screen, eat your keyboard input, and block out the rest of the code. Why can't the autocomplete stuff be on a seperate panel on the side of the screen instead of blocking the code? I use Dev-C++ (a beta version of it and with the most recent version of GCC) to do all development because the IDE is simple and doesn't get in my way. Also, autocomplete encourages lazy variable naming because the penalty for not naming your variables properly is reduced which makes it harder to detect badly-named variables. Many of the other IDE's features are stupidly implemented and it would waste more space (specifically vertical space) than Dev-C++ even if you disabled all of its features.

With that being said, most people are reliant on debuggers and prefer complicated IDEs such as Visual Studio.

[jwezorek]

I need to take issue with the "debugger as tool of last resort" thinking some have expounded upthread. I also use a debugger as a "prevention is better than cure" tool, so all new code is always developed and initially tested using debug builds.

Well, fine, but what is good for 'prevention is better than cure' is formal unit tests. I think all new code should be tested but don't see how that equates to all new code should be stepped through with a debugger.

[Hodgman]

I need to take issue with the "debugger as tool of last resort" thinking some have expounded upthread. I also use a debugger as a "prevention is better than cure" tool, so all new code is always developed and initially tested using debug builds.

Well, fine, but what is good for 'prevention is better than cure' is formal unit tests. I think all new code should be tested but don't see how that equates to all new code should be stepped through with a debugger.

I do both -- just like back when you had math homework, you couldn't just write the final answer down; your teacher always asked you to show your "working", to show how you got to the answer.
A good unit test will have complete code-coverage, so it will run your code through all it's edge cases, and will validate that all the outputs are expected.
I then make sure that I watch the unit test occur to ensure that the "working" is correct, as it's always possible that two bugs have coincidentally caused broken code to generate a valid result

Also, regarding 'debug builds', almost every game studio I've worked for has actually had 3 kinds of builds, instead of the usual 2 (debug/release).
* Debug is unoptimised and does as much internal validation as possible.
* "Release" is optimised, but still contains debug information and most assertions.
* Shipping is optimised with assertions stripped.
So even when working with "release" builds, there's still a lot of assertion checking going on, so code should vary rarely crash from anything other than an assertion failure (which tells you exactly what is broken).

Edited by Hodgman, 21 September 2012 - 11:06 PM.

[Olof Hedman]

If they didn't, they wouldn't exist in the first place.

That's not a very valid philosophy right there. Try applying it to Hitler, or Windows ME.

What? I really have no idea what you are talking about now... how could I apply that to either?

I'm just saying a debugger is a tool, made by programmers, to make themselfs more productive.
If the debugger wouldn't make them more productive, they would stop developing them.
I'm not trying to make any general philosophical statement.

Anyhow, my professional opinion is that anyone who ignores the benefits of a debugger is a fool.
They can save you lots of time better spend on figuring out the actual problem instead of some ghost problem you think you have.
But of course they are not a replacement for good software engineering, just a very useful tool to verify your (or others) software engineering.

Edited by Olof Hedman, 22 September 2012 - 06:20 AM.