if(x=5)
-
Ravi beat me to it, but this is the first thing that comes to mind. I'd been coding C++ for about 8 months, paid employment for about 2. I spent a day looking for this bug, every time I saw the line if (x=5) my brain just turned it in to if (x==5) which is obviously what I meant. I got into the habit of writing if (5 == x ) after that, and every now and again, I'd get the compiler error that told me I'd made the same typo again :-)
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Hmm. I know you all use Visual C. Though I seldom make this mistake, Borlands C++Builder compiler gives me a neat warning: 'Possibly incorrect statement.:cool:'
Cees Meijer Software / Hardware Engineer QMetrix BV Specialists in River and Sea flow measurements.
-
Christian Graus wrote:
I got into the habit of writing if (5 == x )
I don't like that but it's quite common and is one reason (amomg many) why, in the newer languages, we shouldn't still be using C-syntax three decades after it was first devised. Still, I don't make this particular mistake. Maybe it's just the way my mind works. (I make all sorts of other mistake of course.:))
Kevin
*grin* I don't believe I've ever made it except as a typo. Yeah, I have abandoned that syntax in C#, as it's no longer necessary.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Hmm. I know you all use Visual C. Though I seldom make this mistake, Borlands C++Builder compiler gives me a neat warning: 'Possibly incorrect statement.:cool:'
Cees Meijer Software / Hardware Engineer QMetrix BV Specialists in River and Sea flow measurements.
So does VC on a level 4. I should mention, I took this job on a project that had been around for some time, and when I started, there were 600 warnings or something. This was the event that finally helped me convince my boss to let me clear all those warnings, and impliment a 'warnings are errors' policy.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Ravi beat me to it, but this is the first thing that comes to mind. I'd been coding C++ for about 8 months, paid employment for about 2. I spent a day looking for this bug, every time I saw the line if (x=5) my brain just turned it in to if (x==5) which is obviously what I meant. I got into the habit of writing if (5 == x ) after that, and every now and again, I'd get the compiler error that told me I'd made the same typo again :-)
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
if (x=5)
Hasn't everyone* made this same mistake at one point in time? :doh: Not really wanting to admit this has happened to me on at least two occasions.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
-
Ravi beat me to it, but this is the first thing that comes to mind. I'd been coding C++ for about 8 months, paid employment for about 2. I spent a day looking for this bug, every time I saw the line if (x=5) my brain just turned it in to if (x==5) which is obviously what I meant. I got into the habit of writing if (5 == x ) after that, and every now and again, I'd get the compiler error that told me I'd made the same typo again :-)
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
if (5 == x )
I've done this for years (after running into that bug a couple times in college and spending days trying to track it down). Interestingly enough, I've run into opposition to it from supervisors when coding standards are discussed. I've never quite understood why they wouldn't want to avoid possible bugs, but sometimes they are almost religious about it.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
In C# if statments can only evaluate booleans so if(x=5) would not give it a boolean and cause a compiler error. C# is the way of the future.
static int Sqrt(int x) { if (x<0) throw new ArgumentOutOfRangeException(); int temp, y=0, b=0x8000, bshft=15, v=x; do { if (v>=(temp=(y<<1)+b<>=1)>0); return y; :omg:
Henize wrote:
In C# if statments can only evaluate booleans so if(x=5) would not give it a boolean and cause a compiler error.
Which it "borrowed" from Java ...
Henize wrote:
C# is the way of the future.
Just like you don't use a hammer when you need a screwdriver, you don't use C# (or Java or VB) when you need C++.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
Christian Graus wrote:
if (5 == x )
I've done this for years (after running into that bug a couple times in college and spending days trying to track it down). Interestingly enough, I've run into opposition to it from supervisors when coding standards are discussed. I've never quite understood why they wouldn't want to avoid possible bugs, but sometimes they are almost religious about it.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
Zac Howland wrote:
nterestingly enough, I've run into opposition to it from supervisors when coding standards are discussed. I've never quite understood why they wouldn't want to avoid possible bugs, but sometimes they are almost religious about it.
I don't especially like this style but it's not the kind of thing I would forbid in a coding standard. It should concentrate on more important things, e.g., in C/C++, uninitialised variables.
Kevin
-
Zac Howland wrote:
nterestingly enough, I've run into opposition to it from supervisors when coding standards are discussed. I've never quite understood why they wouldn't want to avoid possible bugs, but sometimes they are almost religious about it.
I don't especially like this style but it's not the kind of thing I would forbid in a coding standard. It should concentrate on more important things, e.g., in C/C++, uninitialised variables.
Kevin
Kevin McFarlane wrote:
It should concentrate on more important things, e.g., in C/C++, uninitialised variables.
Agreed. However, it is interesting what topics actually get fought over most when discussing coding standard guidelines. I've been in meetings with 2 different development teams at 2 different companies and had similar discussions over what I consider to be rather trivial issues.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
Ravi beat me to it, but this is the first thing that comes to mind. I'd been coding C++ for about 8 months, paid employment for about 2. I spent a day looking for this bug, every time I saw the line if (x=5) my brain just turned it in to if (x==5) which is obviously what I meant. I got into the habit of writing if (5 == x ) after that, and every now and again, I'd get the compiler error that told me I'd made the same typo again :-)
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Zac Howland wrote:
nterestingly enough, I've run into opposition to it from supervisors when coding standards are discussed. I've never quite understood why they wouldn't want to avoid possible bugs, but sometimes they are almost religious about it.
I don't especially like this style but it's not the kind of thing I would forbid in a coding standard. It should concentrate on more important things, e.g., in C/C++, uninitialised variables.
Kevin
[coding standards]
Kevin McFarlane wrote:
It should concentrate on more important things
Like which ways brackets should be placed! :mad: Hating coding style guides and the people that are content in contriving them
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
-
Ravi beat me to it, but this is the first thing that comes to mind. I'd been coding C++ for about 8 months, paid employment for about 2. I spent a day looking for this bug, every time I saw the line if (x=5) my brain just turned it in to if (x==5) which is obviously what I meant. I got into the habit of writing if (5 == x ) after that, and every now and again, I'd get the compiler error that told me I'd made the same typo again :-)
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
if (5 == x )
Actually, there is quite some resistence to this. Their justification is that you don't avoid bugs by tricks or writing unreadable code. You happen to have such a trick for this case, but many other bugs cannot be avoided by tricks. Sticking to a good discipline is the key. The good thing is when you think of that trick, you are avoiding the bug already, regardless of which way you actually code. :)
Best, Jun
-
Kevin McFarlane wrote:
It should concentrate on more important things, e.g., in C/C++, uninitialised variables.
Agreed. However, it is interesting what topics actually get fought over most when discussing coding standard guidelines. I've been in meetings with 2 different development teams at 2 different companies and had similar discussions over what I consider to be rather trivial issues.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
Zac Howland wrote:
I've been in meetings with 2 different development teams at 2 different companies and had similar discussions over what I consider to be rather trivial issues.
Guidelines I've come across usually split into recommended and mandatory. Then the things which people disagree over are put in recommendations. But really guidelines, e.g., for C++, should concentrate on the kind of stuff in Scott Meyers's Effective C++ books.
Kevin
-
[coding standards]
Kevin McFarlane wrote:
It should concentrate on more important things
Like which ways brackets should be placed! :mad: Hating coding style guides and the people that are content in contriving them
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
jhwurmbach wrote:
Hating coding style guides and the people that are content in contriving them
Well, they should be about Standards rather than style. That's the key. I have my preferences over curly bracket placement but they wouldn't be enforced in a standards document I would write.
Kevin
-
Zac Howland wrote:
I've been in meetings with 2 different development teams at 2 different companies and had similar discussions over what I consider to be rather trivial issues.
Guidelines I've come across usually split into recommended and mandatory. Then the things which people disagree over are put in recommendations. But really guidelines, e.g., for C++, should concentrate on the kind of stuff in Scott Meyers's Effective C++ books.
Kevin
Kevin McFarlane wrote:
Guidelines I've come across usually split into recommended and mandatory. Then the things which people disagree over are put in recommendations. But really guidelines, e.g., for C++, should concentrate on the kind of stuff in Scott Meyers's Effective C++ books.
I don't disagree with that one bit. Its just been my experience that it hasn't worked out that way (and it should be noted that in the first case, I was the only one who was even vaguely familiar with Meyer's books ... much less Robbins, Sutter, etc). I've even had objections arise when I tried to make a case for always forcing code to compile on the highest warning level with 0 errors/0 warnings before being checked in to version control (which is something I always thought should be a given).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
[coding standards]
Kevin McFarlane wrote:
It should concentrate on more important things
Like which ways brackets should be placed! :mad: Hating coding style guides and the people that are content in contriving them
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
jhwurmbach wrote:
Like which ways brackets should be placed!
Everyone knows they should always be placed on the same line! All your code should look like this:
if (isTrue()) { for (int i = 0; i < SomeNumber; i++) { int q = i; DosomethingWithQ(q); } PrintSomething(); };P
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
Kevin McFarlane wrote:
Guidelines I've come across usually split into recommended and mandatory. Then the things which people disagree over are put in recommendations. But really guidelines, e.g., for C++, should concentrate on the kind of stuff in Scott Meyers's Effective C++ books.
I don't disagree with that one bit. Its just been my experience that it hasn't worked out that way (and it should be noted that in the first case, I was the only one who was even vaguely familiar with Meyer's books ... much less Robbins, Sutter, etc). I've even had objections arise when I tried to make a case for always forcing code to compile on the highest warning level with 0 errors/0 warnings before being checked in to version control (which is something I always thought should be a given).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
Zac Howland wrote:
Its just been my experience that it hasn't worked out that way (and it should be noted that in the first case, I was the only one who was even vaguely familiar with Meyer's books
According to Francis Glassborow of the Association of C and C++ Users (ACCU), most programmers don't read books on programming, so I'm not surprised. He told me this in an email after he'd wriiteen that he'd lent a colleague Effective C++ and it had been returned unopened.
Kevin
-
Henize wrote:
In C# if statments can only evaluate booleans so if(x=5) would not give it a boolean and cause a compiler error.
Which it "borrowed" from Java ...
Henize wrote:
C# is the way of the future.
Just like you don't use a hammer when you need a screwdriver, you don't use C# (or Java or VB) when you need C++.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
Check out the Microsoft research project called Singularity. Its an operating system written in C#. Around %99 of it(including the kernel) is written in C#.
Zac Howland wrote:
Which it "borrowed" from Java ...
Yes, Java was a good start and had the right idea. C# can do more. .NET allows any language to be compiled to the .NET platform.
static int Sqrt(int x) { if (x<0) throw new ArgumentOutOfRangeException(); int temp, y=0, b=0x8000, bshft=15, v=x; do { if (v>=(temp=(y<<1)+b<>=1)>0); return y; :omg:
-
In C# if statments can only evaluate booleans so if(x=5) would not give it a boolean and cause a compiler error. C# is the way of the future.
static int Sqrt(int x) { if (x<0) throw new ArgumentOutOfRangeException(); int temp, y=0, b=0x8000, bshft=15, v=x; do { if (v>=(temp=(y<<1)+b<>=1)>0); return y; :omg:
Henize wrote:
static int Sqrt(int x) { if (x<0) throw new ArgumentOutOfRangeException(); int temp, y=0, b=0x8000, bshft=15, v=x; do { if (v>=(temp=(y<<1)+b<>=1)>0); return y;
Talking about errorprone statements ;P btw, I have never thought of that, not even after I had this error happen five times in a 500k lines application. Good tip, will keep that in mind and ask the quality manager to add it to the code convention.
WM.
Yaaarrrr What about weapons of mass-construction? -
jhwurmbach wrote:
Like which ways brackets should be placed!
Everyone knows they should always be placed on the same line! All your code should look like this:
if (isTrue()) { for (int i = 0; i < SomeNumber; i++) { int q = i; DosomethingWithQ(q); } PrintSomething(); };P
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
Zac Howland wrote:
[brackets] Everyone knows they should always be placed on the same line!
You her a multitude of voices from all directions shouting: "For that you will burn on the stake, heretic!" ;P Thats what is fundamental about coding styles: When you have three programmers together, there are at least four stlyes assembled.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
-
Zac Howland wrote:
Its just been my experience that it hasn't worked out that way (and it should be noted that in the first case, I was the only one who was even vaguely familiar with Meyer's books
According to Francis Glassborow of the Association of C and C++ Users (ACCU), most programmers don't read books on programming, so I'm not surprised. He told me this in an email after he'd wriiteen that he'd lent a colleague Effective C++ and it had been returned unopened.
Kevin
Which explains why there are so many horrible programmers running around getting paid to do their worst ...
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac