Is debugging for bad programmers?

[mira]

I'm a junior programmer, writing in VB 6. In the company I work for, some people hold the view that if, while you write a program you oversee something but you catch it while you test it, before you present it to other people, that is unacceptable and shows you are not a good programmer. What do you think about that?
They even go further than that and say that in the process of writing the program while you debug what you have just written, if some error occurs, then you are a person that makes errors, so you are not a good programmmer, so your programs are unreliable (Not that this happens too often, one or two times in a full day's work). What do you think about all these?

[Kevin McFarlane]

I think the people you work for are arseholes. Nobody can write bug-free code of any merit at the first attempt. And, in fact, good programmers do just what your bosses describe as being the mark of a bad programmer!

I once read a statement somewhere from someone who said he'd only ever met one or two people who could write bug-free code and they could only do that by testing their code by stepping through it in the debugger.

[NatThoelecke]

:confused: How can you not make an error or two while writing code?
You might as well not code at all.
I think you should be considered a bad programmer if and only if you create errors in your code and instead of acknowledgeing them you claim they are unfinished features. Ergo, Microsoft employs bad programmers. :rolleyes: ;) :D

[Zeb]

sounds to me like they are just trying to intimidate you. everyone makes mistakes the first time through - even the best.

[Latem]

That's crazy. Seriously, making mistakes in code (especially new code) is a fact of life as much as the sun rising up in the morning, I don't care how good you are. We are only humans.

I mean I take it that company shouldn't have had much of a QA team if all the programmers were so good. Haha yea right.

[Andreas Masur]

What do you think about all these?
Well...it is pretty simple....the only bad programmers I can see there are these persons...let them talk....ignore them...you know better...usually these people make the most errors... ;)

[ovidiucucu]

Is debugging for bad programmers?
Put the best programmers write code without a debugger then you'll see. ;)

[Ejaz]

I'm a junior programmer...What do you think about all these?

Did you look at the video clip where win98 was being presented and just when HP printer tried to be installed.....BANG, there gone windows 98, perhaps some good programmer from the same school of thought didn't used the debugger and cause huge embarsement to Bill Gates.

Think logically man, ignorance isn't an escape nor a defence. This is potential avoidance from the bugs but they won't avoid you.

[darwen]

What planet are these people living on ?

Personally if they're so hot on writing stable software suggest they upgrade from the dinosaur that VB6 is to one of the .NET languages. They've got far, far more chance of writing stable software in an object oriented language (which can be unit tested as well) than they'd ever have in VB6.

Bugs in any commercial piece of software are a fact of life. They can be reduced by

(1) Limiting the number of lines of code you write. This involves heavy code re-use and good design.
(2) Thorough testing. Bear in mind the job of a tester is in direct opposition to the job of a programmer. A job of a programmer is to bang out as many bug-free lines of code as possible per day. The job of a tester is to find as many bugs as is possible per day.

The number of bugs in a program can literally be boiled down to a probablility of a bug per line of code. Even though you can make this probability very small you can't eliminate it compeletely.

Things are compounded when you have to work on code written by someone else (or even yourself but say something you wrote years ago which you've forgotten all about). If the code isn't designed to be modular and has loads of pre- and post- conditions on methods you won't remember that you must do A after doing B and C and hence a bug will arise.

If these people think they can write code without using a debugger they must be writing really, really simple software. In which case can I come and work at your company ? I fancy a holiday.

Darwen.

[Firewireguy]

I can honestly say that in my 6 months as a graduate C++ developer I have not written even one buggy line of code ever - even in my own testing.

And this has absolutly nothing at all to do with writing no lines of C++ code at all.



Well maybe it does. I think I've forgotten what a for loop is or what purpose "selection" has in programming.

[ovidiucucu]

I can honestly say that in my 6 months as a graduate C++ developer I have not written even one buggy line of code ever - even in my own testing.

And this has absolutly nothing at all to do with writing no lines of C++ code at all.

Wow, wow!!!
How do you look?
Post a photo here. A colleague of mine asks if you are married.
Send a CV.
No, no, forget it! My boss will hire you and fire all of us.
:D

[Ejaz]

Wow, wow!!!
How do you look?
Post a photo here. A colleague of mine asks if you are married.
Send a CV.
No, no, forget it! My boss will hire you and fire all of us.
:D

Well, in case Firewireguy is not vacent, then I'm available :D and my intention is not anyone to get fired....err...just the collegue you mentioned ;) :cool:

[Andreas Masur]

I can honestly say that in my 6 months as a graduate C++ developer I have not written even one buggy line of code ever - even in my own testing.
Sure...programs such as

#include <iostream>

int main()
{
std::cout << "Hello World\n";
return 0;
}

aren't that difficult the tenth time right? :D :D :D

[ovidiucucu]

Well, in case Firewireguy is not vacent, then I'm available :D and my intention is not anyone to get fired....err...just the collegue you mentioned ;) :cool:
Just you must be a bugs-free-programmer. It's first condition.

P.S.
You didn't see her. She waits for a (bugs-free) prince charming from the time she worked on a UNIVAC computer. Still interested? :D :D

[Ejaz]

Just you must be a bug-free-programmer. It's first condition.

P.S.
You didn't see her. She waits her (bug-free) prince charming from the time she worked on a UNIVAC computer. Still interested? :D :D

err.......isn't some latest version of her available? :ehh: If not, then in honour of senior members, who are better bug-free programmer then me (like you), I withdraw :p

[ovidiucucu]

err.......isn't some latest version of her available? :ehh: If not, then in honour of senior members, who are better bug-free programmer then me (like you), I withdraw :p
No, no I'm not bugs-free but have got a lot of free bugs.

Down the bugs slavery! Down the debuggers! Stop debugging!
:D

[Krzemo]

I can honestly say that in my 6 months as a graduate C++ developer I have not written even one buggy line of code ever - even in my own testing.
It means that U are pretty bad tester or U don't know the definition of the word "bug".
bug - it is not a syntax error :rolleyes: !

[ovidiucucu]

It means that U are pretty bad tester or U don't know the definition of the word "bug".
bug - it is not a syntax error :rolleyes: !
Of course not.

BUG - small insect causing short circuits in a (mainframe) computer and make programs giving erroneous results.
DEBUGGER - an useful guy that uses some dust to kill bugs and make programs run properly.

[Ejaz]

Bug & Debugging (http://www.wordiq.com/definition/Computer_bug)

[Krzemo]

DEBUGGER - an useful guy that uses some dust to kill bugs and make programs run properly. I see.. thats the origin of dust on my proc. cooler.... I didn't know that !
Thanks for the info :D :D :D :D

[Kheun]

Lets be realistic. I don't think there is anyone in the world who can honestly claim that he/she has not made any mistake in his/her entire life. Making mistake is part and parcel of life! Since programming involve human participation, it is very common to find bugs in it.

World renowned software gurus also recognize that. For example, Kent Beck, who is a major contributor to software pattern, has also authored "Extreme Programming". Extreme Programming advocates pair-programming to reduce bugs by actively reviewing the code while it is being written. Martin Flower, who is an consultant on design of enterprise software as well as author of several books (like Refactoring), advocates test-driven programming. In test-driven programming, it assumes that it is natural for programmer to make mistake. Thus, by first writing the test, then implementing the code, it helps to reduce bugs.

If you are to look closely at the libraries provided by your compiler for your favorite programming language, it wouldn't be a surprise to find functions like assert() in C/C++. Such functions helps to identify bugs easier. Similarly, other languages like Eiffel provides constructs for "Design by Contract" and the D programming language goes a bit further by providing "Object Invariant".

To sum up all the above, it is just not humanly possible to write code with any bug. Since to err is human, the most important thing is to learn and grow from mistakes.

[Ben_Phillips]

If someone claims that they have never written a buggy line of code then they are either lying or deeply mistaken. A common mistake of many beginners is to test their program once and believe that it works (like I did way back when I started, naturally it only crashed when I tried to show it to a friend), or to test it with the expected input (like testing a calculator with "1+1" instead of not only testing real expressions, but also testing ones with errors like "1++1")

OT: I don't remember much about it, but I do recall that the last time I looked at Extreme Programming it sounded like a nightmare

[Tom82]

uh thats fine to read this here

i got the same problem like mira,
i normally use a VC++ and its debugger,
now i am new in company and have to use visual SlickEdit with gcc and wxWindows but cant get this running, and noone can help me because i seem to be the only "Debugger User" in the company...

read the whole story here if interested or want to help me: http://www.codeguru.com/forum/showthread.php?t=336348

[Arjay]

uh thats fine to read this here

i got the same problem like mira,
i normally use a VC++ and its debugger,
now i am new in company and have to use visual SlickEdit with gcc and wxWindows but cant get this running, and noone can help me because i seem to be the only "Debugger User" in the company...I can't help you directly because I've been fortunate to use compilers with debugging capabilities, but it's my experience that trying to operate in this sort of 'blind debugging' environment wastes a lot of time - it really should be a last resort. Here's a couple of alternatives if you can't use a debugger directly: 1) Can you add trace output to your program (like OutputDebugString() or equivalent) and use a program like SysInternal's debugview; 2) Can you log trace data to a logfile?

Arjay

[Deniz]

I think your boss is an idiot. Look for another job.

[Kheun]

I have been working in previous embedded project in which we are lacking a good debugger. I have to rely on printf() to display the status of the program via a serial port for debugging. Worst of all, each build takes nearly half an hour (clean build is about 2 hours). As a result, even to debug the simplest bug or memory leak is very time consuming. Since I am only using printf(), I have to repeat several times in order to place the printf() statement near the exact location where the code breaks. Trust me. This is not the glamorous type of job and it is very painful. :( :cry:

Anyway, my team has since migrated to a new processor and invested on a good IDE with good debugging tools. :cool:

[Arjay]

Anyway, my team has since migrated to a new processor and invested on a good IDE with good debugging tools. :cool:Congratulations! I sure the money invested in the new IDE will be quickly recovered with increased developer productivity - not to mention less dev stress.

[Max Payne]

My first job after graduation as a junior programmer, what my boss expects is a program that can run and he doesn't care about bugs or errors in the program, as long as the basic input and output is ok, and he is very detailed when it comes to the interface part, expecially the color of the controls, he is soo stupid.... I hate him for that, need to change the interface everytime he sees it...!!!! :mad:

/even if I hardcode everything, he won't notice, he is sooo stupid...

btw, your company must b full of jerks, what my new boss said to me on my first assignment is "send your code to QA, and don't worry, there must be a bug.."

[zeveck]

I think that your co-workers either presented the idea to you or else took the idea from somewhere else a bit too literally...but I can see the nugget of truth at the heart of their claim.

There is often a subtle difference between those programmers that rely on the debugger as a safety net and those programmers that rely on the debugger as a crutch.

In the first case, the programmer tends to code carefully, but hey, we're all human, and so makes sure to compile the code with all warnings on to catch the occasional mistake. The programmer fixes the obvious errors/warnings, and ponders over the not-so-obvious or completely unexpected errors/warnings. The careful programmer probably also reviews the code to catch places where a similar mistake may have been made.

In the second case, the programmer bangs out code as quickly as possible, runs and then compiles it, fixes a problem and compiles again, fixes a problem and compiles again, and likewise repeats this process until all bugs are gone. This programmer doesn't necessarily understand the cause of many of the problems...just knows enough to make it them go away. This is general procedure. This is closer to "hacking with a debugger as backup" than proper programming.

This is the mindset where this (sorry...had to use C++ for a sufficiently revolting example)...

class Foo {
public:
Foo() : _i(0) {}
const int foo(const int &i) const {
_i += i;
return _i;
}
private:
const int _i;
}
generates a compile error and could become...

class Foo {
public:
Foo() : _i(0) {}
const int foo(const int &i) const {
int *k = const_cast<int*>(&_i);
*k += i;
return _i;
}
private:
const int _i;
}
After all...it gets past the debugger.

So...to paraphrase ObiWan...a great number of truths depend greatly on your point of view.

[darwen]

I think you're mixing up debugger and compiler here :

A compiler error means that the code won't compile.

You use the debugger to find out why code which does compile doesn't work.

You can't use a debugger to tell you what parts of your program won't compile : you have to have compiled it successfully before using a debugger.

This is the difference between syntactical errors and symantic errors. Syntactical errors occur when you write a piece of code which doesn't conform to the compiler's standard of the language.

Symantic errors occur usually as bugs in the program : i.e. something doesn't behave as it should.

To get to fixing symantic errors you have to get past the syntactic errors first.

And what's the best way to fix symantic errors ? By using the debugger - i.e. setting breakpoints, using trace statements etc.

I find the debugger to be an invaluable tool. I would estimate it would take me at least 10 times longer to produce a fully working piece of software (or module, or part of a larger piece of software) than without. If not 100 times longer.

I use the debugger extensively to figure out what's happening in existing code : not just to fix bugs. I.e. code not written by myself. It's much easier to put breakpoints into code you don't understand and follow the path that it takes than trying to understand it just from reading the source code. Besides the fact that the debugger will allow you to read variable values etc as well.

Code will always have symantic errors. That's why we have testers, who's job it is to find them, from a users point of view of course.

Programmers find syntactic errors all the time : or at least I do. I leave it up to the compiler to tell me if I've missed a ) or a ; - after all, the compiler is very good and quick at doing so, and I (as a mere human) am not.

Besides, I see no point in spending 5 minutes (or 2 or 1 or 30 seconds) looking through my code trying to spot the syntactic errors when the compiler will do the same job for me in 2 seconds.

Next you'll be trying to tell me that I should forget the compiler and translate all my C++ to Assembler myself ! :D

Darwen.

[Pinky98]

Personally, I think this is a fantastic idea. We should all write code, and then release it with out ever testing it at all. Think how much time you'de save.

What a bunch of morons...

[zeveck]

Nor would it necessarily seem to be a problem if you stepped through it with a debugger.

Note that my "bad code" example does not include any syntactic errors.

I recognize that the compiler and debugger are technically different entities, but I took the original author's usage to be conflating to the two, so I just lumped them under "debugger".

I don't see how you took my statements to any way imply translation to Assembler or any such menial tasks should be the responsibility of the programmer. My point was only that there are those who employ the compiler/debugger and those that strictly rely on the compiler/debugger. You can find fine programmers in both sets of individuals; but as a whole the latter group will tend to produce buggier code.

I agree that a debugger is an invaluable tool. But it is far better to spend the extra few minutes vetting the code as typed than to just hack it together and then rely on the compiler/debugger to help find errors.

Even the best debugger can only catch certain classes of errors. For one, they can seldom detect design errors, or errors that are in aspects of the code that just aren't exercised by the particular test runs on steps through. This is why, for instance, buffer overflows remain so common - because the error is specific to the data in use and most developers only use the debugger to step through runs on reasonable data.

[SouthernCodeMonkey]

Even the perfect programmer that makes ZERO mistakes in their own code will find a use for a debugger.

What happens when we are handed a library to use and it has a bug? Wishing, dreaming, and hoping will expand your imagination but it will not make your application execute bug-free.

Without the debugger info, you are left having a pointless "No, it's in YOUR code" exchange with the library authors.

So, if you happen to be one of those perfect programmers you will still need the debugger to document the fact that you are, indeed, not to blame. You would actually end up doing more debugging than the programmer who writes buggy code using bug-free libs I am willing to bet. I won't even get into what happens when you give up on waiting for the lib guys to get it straight, implement a correct "fix" only to have their subsequent "fix" break your code again.

A cruel irony huh. Boy am I glad I'm not a perfect programmer. :D

Regards.

[Kevin McFarlane]

Besides, I see no point in spending 5 minutes (or 2 or 1 or 30 seconds) looking through my code trying to spot the syntactic errors when the compiler will do the same job for me in 2 seconds.
Darwen.

Too true. And that's why it's pointless being set technical tests where they ask you to spot the syntax error, as opposed to the semantic error.

[polus]

lmao

I hope your joking.

I think the people you work for are arseholes.

this sums up what I think aswell.

I write realtime software for controlling robotics. We only use C/C++ from the embedded level all the way up to win32 and I can tell you, if we didnt have debuggers we would be up the creak without so much as a stick to paddle with!

I had a multithreaded problem the other day, could not for the life of me work it out, eventually after much debugging it becuase clear what was happening but complex problems like that (especially when Ive only had 1 year of experience of writing C/C++) require a debugger to track down.

Im still shocked at that...If I were you I would be looking for another job.

[zeveck]

Multithreading is another excellent case of the problem with relying on debuggers. Oftentimes bugs in multithreaded programming involve complex race conditions that are hard to reproduce. In fact, oftentimes a race condition that is present in production software is not present in the debugger because the very notion of stepping through the code completely changes the relative timing of events.

Especially with multithreaded apps it is strictly necessary that the code be carefully written and carefully reviewed for logical flow and consitency. OF COURSE it is perfectly permissible to use the debugger when errors DO crop up...but that does not make it okay to code by the seat of one's pants and rely on debugger sessions to catch bugs and fix up the code.

Again...trying to focus on the grains of truth in this notion about the debugger being bad...I am not trying to say people shouldn't USE debuggers.

[Kheun]

Adding to that, certain bug can be very complex, like prority inversion which is very normal in the embedded world. Without a debugger, it is virtually impossible to fix the code. In fact, some vendor like Green Hills have been selling a "Timer-machine" debug box which capture a history of CPU's state and stacks.

Anyway, I always believe that effective developer needs effective tool. :cool:

[JohnW@Wessex]

The debugger can be very useful for me when developing image processing and classification algorithms. Sometimes an image will not be classified as expected and stepping through the code with the debugger can identify the areas where the algorithm is making the mistake. This is not usually a coding error but an indication that the algorithm used may need to be improved.

[puxte]

if the programmer produces a bug free code than than all quality people would loose their job ..

[zeveck]

But wouldn't it be wonderful to have the QA folks dealing with issues of quality aside from bugs? Just think, they'd be freed up to experiment with and comment on the user interface and the general user experience, resulting in immensely more usable products.

Of course...that would also happen if companies would scale back production schedules a bit and plan HCI into the design, implementation, and QA phases of their products...but eh...people buy crap...so what's the incentive?

[SuperKoko]

To write bug-free program (with a phase of debugging, of course), OO is really very, very useful.
You must write small classes (as small as possible), and make different classes the most independent possible (the notion of "Site" can be useful to separate two classes which are too linked).
I name "Site" an abstract base class containing just a few virtual functions, which are called by the class using the site as a set of callback functions.

In fact the user-class (the class which use objects) which contains one or more other classes, can be very depedent on the public interface of these classes, but these classes must be independent of the user-class.
A reusable (in a different context) class is generally a sign of good class design.

You must document (with comment, or at least in your head) each class.
Documenting a class mainly consists saying how we can use the objects.
You can also test for invalid uses of objects (for the debug version of your project) with assertions.
If you have really problems with using an objects, try to put much assertions with detailed error report to see how the object is wrongly used.
IsBadReadPtr and IsBadWritePtr may be very useful to test the validity of some data structure.

Classes usage should be kept as simple as possible.

If possible, you can try to test individually each component (a class).
Each component should be simple enough, to be totally represented in the mind of the programmer.

Multithread is can produce very subtle bugs. And certain bugs may only occur on very fast computers or very slow computers.

I am really paranoid for multithreaded applications, and i try to individualise the synchronisation code to make it very, very short and localised.
And i try to write a mathematical demonstration that my code is thread-safe.
It can took much time. I can spend more time on a 8 lines of code than on 500 lines of simple code.
Once the mathematical demonstration is done (since there may be "bugs" in mathematical demonstrations), it is good to imagine all the priority and race conditions that may occur in only one image (what can be done, only if the code has been correctly individualised).

For other components, since bugs are much more easy to reproduce, it is not necessary to be so paranoid.
If you have an object who is growing during the devlopment time, try to separate this object in two or more different objects (each individualise a part of the full object). Of course you should try to make the objects the more independent you can.

I think that this philosophy (the OO philosophy), can be applied to much programming languages (even assembly language of course, but not old Basics which had only GOTOs and GOSUBs!).
But OO programming languages offer much compile-time error and warnings which can be very useful to avoid a category of bugs.
This bugs are really stupid bugs which correspond to "semantic typos".
That is : the programmer passed a wrong value type, or forgotten to destroy an object, or to initialize it.

With OO, i think that the number of bugs is linear with the total size of code, and components code size should be majored by a constant. With good programming practice, and good beta testers, it is possible (but hard) to write a totally bug free project.
With a do-all-in-a-single-function-or-object design, the number of bugs may be quadratic or exponential with the total size of code.