|
Using the debugger is an admission of defeat. A option of last resort (just short of actually asking for help).
modified 16-Feb-22 9:16am.
|
|
|
|
|
Division by 0, array index out of bounds, null values? 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
var vAux = 'whatever...';
if (vAux = null && vAux = undefined && vAux.length = 0)
console.log('Error at ValidationCode!');
|
|
|
|
|
I think one point that is often missed in teaching coding is making sure you can show that your code is correct. Not necessarily TDD, but setting up some input that you know what the output should be.
This is very helpful in understanding the problem, and helps you know when you are done.
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
I'd agree - and one of the planned articles is all about testing. I'll be mentioning it in "Debugging" but not to any depth.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Cut and paste errors
x = x + 1;
y = x + 1;
(Slightly more complicated would be better)
Because your brain sees what it wants. Not what is there!
(My sons first comp sci program. He didn’t see it. I didn’t see it. but stepping through the debugger sure made it obvious!)
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
Infinite or range-error loops e.g while(test = 1) or for(i = 100; i > 0; ++i) I know I'm guilty of both of these, on occasion.
Keep Calm and Carry On
|
|
|
|
|
k5054 wrote: Infinite
 and put a short counter on it so that it doesn't completely blow up! 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
We / I learned how to flowchart before learning to write code. Don't know how you get to one without the other (at some point), without a lot of "explaining".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Comparing for equality two real valued calculated results, which should mathematically be identical, but due to limited precision, they differ in the least significant bit (or two).
If you were working on old machines using 1-complement integer representation, you could also compare plus and minus zero for equality, but I haven't seen a 1-complement machine for quite a few years now.
A related one: When casting (implied or explicitly) to a longer word length, will the upper bits be zero or sign bit filled? Note: This can be both language/datatype and machine architecture dependent. I once spent half a day to understand a single if(x>y) statement: Both alternative seemed to do exactly the same, just in slightly different order. The reason was an implied cast (from 8 to 16 bits - this was on an 8051) where "wrong" sign extension would wreck the result if the same order of execution was used in both cases.
Edit: This was intended as a reply to the OP, not as a reply to Gerry.
|
|
|
|
|
Using iterative instead of declarative statements to manipulate collections using Linq??
|
|
|
|
|
|
I'm not sure this can be done anymore, declare a global variable DateTime as an int. Worked in VB (possibly 6) and truly screwed up an application.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I was once told to write a short snippet in C++ with a couple bugs in it. One obvious and one less obvious to give as a coding test to prospective new hires. It took me hours. Plus, I never docked a candidate that "failed" the test in an interview. And thus hold interview tests in the highest disdain.
My suggestion: An if statement with 2 indented lines under the conditional but no enclosing code block delimiters (braces).
if (x > y)
x++;
y++;
|
|
|
|
|
Integer arithmetic
3 / 2
Integer versus double
If 3/2 == 1.5
Another post covers double == double.
Always use code formatter to help with misleading indents/ missing braces.
|
|
|
|
|
I spent three months tracking down a bug in a 3d rendering system, burried under thousands of lines. Here's the gist of it.
struct vertex {
double x, y, z;
}
struct model {
struct vertex* vertices;
size_t triangles;
}
void loadToGpu(struct model* m) {
void* buffer = getDeviceBuffer();
memcpy(buffer, m->vertices, m->triangles*3);
}
I hope at least a few of you have to look twice at this so I can feel a little better. 
|
|
|
|
|
How the heck did that not go 'poof' the very first time you loaded up vertices, and then used it? Just bad luck it didn't?
|
|
|
|
|
the gpu/driver/bios/something pre-zero'd (binary 0) the buffer so it just saw all the other verts are at 0,0,0 (double 0) which is not technically invalid, just invisible due to having a surface area of 0. Those few verts that were copied in just happened to be facing away from the camera so were backface-culled.
|
|
|
|
|
C# variables have initial values of binary zero, by language definition. I don't think C is similar, but correct me if I am wrong. I believe that there are other languages that defines initial values of zero.
This has been debated for years, and apparently someone in the VS team disagree with the C# designers: I get a curly warning line if I use an unassigned variable. Maybe I could switch that off, but I think it is OK the way it is.
I learned my first "serious" programming in Pascal, where a type may define a value range that does not include a zero value (such as an integer ranging from 1900 .. 2100). It would be rather meaningless for the language to specify an illegal initial value for some variables, arguing that it makes sense for other variables. In Pascal, enumerations are not named integers: If you define one TYPE Color = (red, blue, green, yellow); you should not take for granted that red is represented as binary zero. Even though Pascal treats the values as ordered, the application semantics often doesn't (for colors, the rainbow ordering is often completely irrelevant). If, for some reason, the order in the type definition is changed, with internal values assigned from 0 and initial values binary zero, this could cause a change in program semantics even if the code does not consider colors ordered.
If you insist on some defined initial value, a much better value would be upper bit set, remaining bits zero. In most architectures, a 0x1000...000 pointer is likely to point outside the heap, to be caught as uninitialized. An integer would be -MAXINT-1, an abnormal value which is its own negation. For sign/exp/mantissa float, it is minus zero. For enums, it it practically always outside limits. Character code 1000 0000 is not assigned any function. It is quite likely than an unassigned value would be caught - far more so than with all zero initial value
|
|
|
|
|
C# variables have initial values of binary zero, by language definition. I don't think C is similar, but correct me if I am wrong. I believe that there are other languages that defines initial values of zero.
Yes and no. In C++, a class-level variable will have the value that is provided by the constructor. If no constructor is explicitly defined, the default constructor will give it a value of zero BUT if a constructor is defined and that constructor fails to assign a value to the variable, it'll keep whatever garbage was already in ram. (furhter reading). A scoped variable (on the thread stack) has the dreaded "undefined behavior" if used without being initialized, and so many compilers (when not told to optimize) will populate the thread stack with the wrongest possible value in order to cause a bug to help you find places where it is accessed before being initialized (by exploding). Usually that means 0xCC repeating (at least in the case of gcc).
However, when the variable/buffer in question came from somewhere else, especially a hardware device that is not really even ram, the compiler will leave it alone because writing to it might cause the hardware to act on that data which could be cataclysmic under the wrong circumstances.
|
|
|
|
|
You can share the bug that is in my FractalBrowser program. If you download the project now, and get a view you want, then try to save it, the program will crash. It boils down to my home-brewed versioning approach. I've got it fixed on my end, but haven't uploaded the new project. It also has a comment in that portion of the code that appears to be out of sync with the code! Don't know how THAT happened!!!
|
|
|
|
|
How about the simple case of removing items from a list within a forwards for loop?
List<int> values = new() { 1, 2, 2, 3, 3, 3, 4, 4, 4, 4 };
for (int index = 0; index < values.Count; index++)
{
if ((values[index] % 2) == 0)
{
values.RemoveAt(index);
}
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
It's hard to believe how difficult it is to purposely illustrate buggy code given the sheer number of examples shown in this list. Especially considering the fact that I've actually done most of these unintentionally at one time or another in my long storied career.
|
|
|
|
|
Public Relations and paleo diet create order. (11)
... and to further the theme, a bonus extra:
Between Tuesday and Monday? (4)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I see what you did there! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
