Never mind the rest said i agree that 'coding style' is something as different among people as are nose shapes or eye colors, but for that line show a good example. I mean in the following code, what would it help if the value of the variables was known to track the bug?Originally Posted by esbo
Code:unsigned int gory_mess(void *a, int size) { int j; unsigned int hash; hash = 0xF348D6EE; for(j=0; j<size; j++) hash += (*(int *)(a + j + 1))<<(size - j); return hash; }
A typical example of ...cheap programming practices.Code:... goto johny_walker_red_label; johny_walker_blue_label: exit(-149$); johny_walker_red_label : exit( -22$);
It might help you determine what is wrong with the program.
It would make everyone write really simple code, because if the system had to take snapshots of the "function call stack" and the "stack frame" at each and every change of an automatic variable from program start to end, then if you wrote anything moderately complex you'd bog your system memory down with megabytes of useless information.
[edit]Of course I'm merely having fun here. The system I'm on does provide me with a trace very much like this, but in a big circular buffer.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
This is probably why I don't use a debugger, it is easy to get bogged down in the detail,It would make everyone write really simple code, because if the system had to take snapshots of the "function call stack" and the "stack frame" at each and every change of an automatic variable from program start to end, then if you wrote anything moderately complex you'd bog your system memory down with megabytes of useless information.
[edit]Of course I'm merely having fun here. The system I'm on does provide me with a trace very much like this, but in a big circular buffer.
it is usually better to step back and think about what is going on and often quicker, also
I have known programs which run fine when you compile in debug mode but crash when you
compile it normally!
I manage on a few debug printf statements, more thought, less data which is better than
megabytes of data but little thought about what might be wrong!
This is a problem - you never wrote program bigger than several lines of code...
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Well, we've really strayed from the matter at hand thanks to esbo entirely. Somehow, now we're stuck discussing what you feel to be proper practice. We may as well discuss it somewhat seriously. Maybe we'll change your mind one of these days.
Fixed!I have written programs which run fine when you compile in debug mode but crash when you compile it normally!
On the whole I imagine that these programs are simply poorly written on your part. The whole purpose of debug mode is to find and fix problems; I can't imagine why it's okay to do it bass ackwards and expect that a release build makes it possible to encounter all the bugs you sneak in. I mean, I depend on my debugger to break execution when the program is about to crash. At least I likely know the area of the problem after that.
I'm not really against people stepping back and thinking, as you noted, but programmers who deserve to be employed already learn to do that. You're also endorsing a system of development that saps their productivity:
The whole notion that you can effectively debug a large project with printf's seems like a bit of a fallacy to me. I can't imagine working on even an open source project where volunteers were depending on printf to bump into errors. To track down a segmentation fault somewhere without the aid of another tool, for example, you would have to bloat your part of the code base considerably with printf calls and write sufficient wrappers for them so all those extra calls aren't compiled at all when you want to release. You probably won't agree with me here, but that seems like an excellent way to tack on kilos of useless information to your intermediate executables. Such a waste of effort! Because even after all of that you still have to hope that you made an appropriate guess at the problem area, then actually fix it.
I'm assuming one hell of a bug, but they happen to people and programmers quite indiscriminately.
This thread seems to have run its course.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
