The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
It's even worse than that: debug-by-printing is often explicitly recommended.
And why is that so bad?
I have found a lot of bugs just adding a couple of messageboxes / wprintf in places of the code
If you are programming things that might have a timing component, debugging alters the real world use case when you hit the stop points. Saving a couple of values there and printing them later on the screen doesn't screw your performance or timing relational so bad.
And as de2k88 said... you might use it always.
You can even "debug" the release version with it.
I think this is like the "goto"... it is not bad per se. But I can agree with you that it might get messy pretty fast.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
If you are building code to ship to customers, then in the field problem diagnosis is a fundamentally important thing. If something only fails in the field and you can't reproduce it, it can turn into a major circle-jerk (with you being the jerk in the circle.) Good logging, with variable threshold, is a key part of that.
And, since it's already there, it will serve you just as well during development as well. For me, I have a very powerful logging system that is supported throughout the entire code base, and the ability to log to a centralized log server. This has saved me more times than I can count. I mean, we all love being jerked in a circle, but sometimes you just don't have time for it.
Assuming you had enough runs left: Our score for an assignment decreased by 10% for each run over three.
When I moved into the "real world" and started working with embedded Z80 assembler, I had to write my own debugger to stop the process and display register / memory data in real time ...
Visual Studio has so many tools to make beginners life easier, and many of them have no idea that they even exist, much less that "debugging" is different from "fixing the compilation errors".
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
It seems that problem solving at all is not a skill taught to anyone anywhere...
Actually - 'you have a problem' is considered rude to tell a student, as it implies the need to take responsibility, which totally uncommon these days (and to force it on someone is unforgivable)...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
I wasn't taught anything related to debugging when I was at University. In fact, when I got my first job I had support tickets with the customer claiming something was happening. I fell into the trap of asking my team leader "X says this is happening, can you think of a reason why?"
It was only after being constantly told "Can you reproduce it? If so, have you debugged it to see why it's happening? If not, then we obviously need more information" that I really fully embraced debugging. It seems silly, but up until then I'd only worked on personal projects which were less complex and the bugs were self-explanatory so I only debugged rarely.
If they don't teach it in College/University then I don't have a problem with senior developers teaching more junior developers the values. We have a few developers at my current place who, while being really adept and forward-thinking, sometimes forget to debug and inspect. A gentle nudge every now and then gets them back on track.
But you're right, while there's plenty of material on building code taught at Uni, there doesn't seem to be much in the way of properly debugging and diagnosing code. And I don't think anything prepares students for those situations where a client or customer has made something up!
I don't think that lack of debugging knowledge is the issue, so much as an inability even to understand what steps to take in problem analysis. Look at some of the questions here and you can see that some so called developers do not really understand the code they may even have written themselves. I suspect there are far too many people following a career into IT because they think it pays well, rather than because they have an interest in problem analysis and finding solutions.
I suspect there are far too many people following a career into IT because they think it pays well, rather than because they have an interest in problem analysis and finding solutions.
I would tend to agree. Many people coming into IT are career professionals rather than following a true passion for the industry.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
This is true for many careers. Many mechanics can't find problems in cars because they don't know how they work, they simply follow the company's instructions. So do many electricians.
If you know how the thing you made works, you also know where and what to look at to discover problems. If you don't, i.e. you copy-pasted code without minimal knowledge, you can know every single debugger function and still be useless as a bike to a fish.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
Agreed. There is a big difference between being able to use debugging tools and being able to do problem solving.
Kinda like the super intelligent person who lacks common sense.
A course in OR (Operations Research) could help. Working with real time systems will really test those skills.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
"If you hear hooves, think of horses not zebras" is another of my favourites. Had one guy at a place I used to work always assumed every database issue was due to faults in the NAT firmware in the routers or maybe the network cards were dropping packets so needed updating. He'd spend his time researching new drivers etc etc, and when he still couldn't get it working I would take a look and nine times out of ten he had misspelled the server name in the connection string, or omitted the instance name or something like that.
It's worse than that. The code the junior devs write is often so algorithmically and/or architecturally wrong that debugging won't actually solve the problem. Abstracting the problem, breaking the problem down into smaller problem sets, asserting on inputs, writing try-catch handlers, none of this taught. As a result, debugging something that is broken from the get-go is pointless.
And debugging existing code that hopefully someone with more experience wrote? Forget it. Simple syntax like null continuation, generics, lambda functions, LINQ, callbacks...it's all Greek to them because they were never exposed to real programming.
The mantra my mentee kept repeating over and over again was "oh my god, why didn't they teach us that in school???"