Oh boy. I've given myself a challenge now.
-
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!
-
I'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
-
Infinite or range-error loops e.g
while(test = 1)
orfor(i = 100; i > 0; ++i)
I know I'm guilty of both of these, on occasion.Keep Calm and Carry On
-
I'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
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
-
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.
-
I'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
Using iterative instead of declarative statements to manipulate collections using Linq??
-
I'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
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'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
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++; -
I'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
-
Using iterative instead of declarative statements to manipulate collections using Linq??
-
I'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
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;//every 3 verts = a triangle. If two triangles use the same vert, that vert is repeated. } 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. ;)
-
please forgive formatting. using System.Linq; Instead of double orderTotal; foreach(var item in account) { if(item.Status == "CheckOut") { orderTotal += item.AmountOwed; } } but using Linq we can do decimal total = (from item in account where account.Status == "CheckOut" select account.AmountOwed).Sum();
-
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;//every 3 verts = a triangle. If two triangles use the same vert, that vert is repeated. } 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?Our Forgotten Astronomy | Object Oriented Programming with C++
-
I'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
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!!! :laugh: :laugh: :laugh:
Our Forgotten Astronomy | Object Oriented Programming with C++
-
I'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
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 };
// Remove all even numbers:
for (int index = 0; index < values.Count; index++)
{
if ((values[index] % 2) == 0)
{
values.RemoveAt(index);
}
}// Expected output: { 1, 3, 3, 3 }
// Actual output: { 1, 2, 3, 3, 3, 4, 4 }
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
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?Our Forgotten Astronomy | Object Oriented Programming with C++
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.
-
I'm working on a series of "How to Write Code to Solve a Problem, A Beginner's Guide" articles to cover the bits learners seem to have the most problems with*. So fare I've covered the "break the problem into smaller pieces" approach to getting started, and syntax errors. And the next one is a biggie: Debugging. And there is my problem. To show how to debug something I need to write some short-ish code with a small, subtle bug in it, prove it has a bug, and then show how to fix it. But ... have you ever tried to deliberately write code with a bug in? It's not as simple as I thought it would be ... In fact, I'm finding it a lot harder to write buggy code than I do to write good code! :laugh: * Other than being told "no, I won't do your homework for you" of course. Or maybe I should write one of those ... Hmmm.
"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!
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.
-
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. 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](https://en.cppreference.com/w/cpp/language/value\_initialization)). 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.