Something Every Developer Knows
- Thread starter Covar
- Start date
- Status
It's the transparency that's the problem.
How about this?
If you don't know why that is very very wrong, you are in BIG trouble.
Edit: For extra points: What is truth?
This is worse than above btw.
Code:
for(int i = 1; i <= arraysize; i++)
array[i] = array[i] + i;If you don't know why that is very very wrong, you are in BIG trouble.
Edit: For extra points: What is truth?
This is worse than above btw.
Code:
enum Bool
{
True,
False,
FileNotFound
};
Necronic
Staff member
Ok, other than the index starting at one (which will break the loop at the final step since i<=arraysize is the exit condition, which will take you out of bounds on the loop), and the "array=array + 1" line being deeply strange (but it should work assuming the values are numeric,integers preferably depending on how the language works), I don't see any issues.
I'm missing something really obvious, or was it one of those issues?
edit: heh, apparently I can't put an I in brackets or it itallicizes my writing.
Necronic,
Yes, 1-off problems are basically the bane of developers in any language. I think that if you spent nothing but a month on them for beginners, it still wouldn't be enough time. I still see it. Hence why the focus on enumeration lately across virtually all languages, since the collection itself tells you when it's done. But whenever you do math based upon the indexes (transforms often have this) or are traversing more than one collection at a time you're back to index-based (usually) and people still make these errors way too often.
I'm actually hyper-sensitive about this ever since an old project in University where I had this problem. I was overwriting "somewhere" in memory, and the program crashed in the destructor of an STL class. I was 99% certain that the destructor didn't have a bug, and had no f'n idea where my actual bug was. I was fortunate that in that case I was able to re-compile with a different compiler, and it threw a more useful error. But ever since it's the first thing I look for with "why isn't this working?" when looking at things.
Yes, 1-off problems are basically the bane of developers in any language. I think that if you spent nothing but a month on them for beginners, it still wouldn't be enough time. I still see it. Hence why the focus on enumeration lately across virtually all languages, since the collection itself tells you when it's done. But whenever you do math based upon the indexes (transforms often have this) or are traversing more than one collection at a time you're back to index-based (usually) and people still make these errors way too often.
I'm actually hyper-sensitive about this ever since an old project in University where I had this problem. I was overwriting "somewhere" in memory, and the program crashed in the destructor of an STL class. I was 99% certain that the destructor didn't have a bug, and had no f'n idea where my actual bug was. I was fortunate that in that case I was able to re-compile with a different compiler, and it threw a more useful error. But ever since it's the first thing I look for with "why isn't this working?" when looking at things.
- Status