One guidelines for C/C++ programmer
-
BadKarma wrote:
That's correct, in fact here we encourage people to use the most ugly, unwell formed and disaster bringing code that they may come up to. Poke tongue
Or otherwise known as: Job Security ;P
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008)We should write our own coding standard. For beginner - Writing Code Horrors for dummies - Learn to Code in Horror Style in 21 days For Professionals - Advanced Horror Techniques : When template gone wrong - Gibberish : Take your obfuscation skill to a higher level
Learn from the mistakes of others, you may not live long enough to make them all yourself.
-
In your project, If you are using if condition like
enum
{
Blue_c,
Yellow_c,
Red_c
};
int color;if( color == yellow_c)
{
.....
......
}
or
if(color != Red_c)
{
....
.....
}Now you know by mistake if you forget one = or ! means if(color = yellow_c) or if(color = Red_c) then no error will come and bug fixing cost for your projects So To avoid this cost you should use
if(yellow_c == color)
{
.....
......
}
or
if(Red_c != color)
{
....
.....
}Now if you forgot to put one = ot ! then compilation error will come.. So this should be in coding standard to use like this...
Truth Can'nt be changed
Real
C
programmers (i.e. real men) don't use such girly tricks. They bravely make mistakes whenever is needed. ;PIf the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
In your project, If you are using if condition like
enum
{
Blue_c,
Yellow_c,
Red_c
};
int color;if( color == yellow_c)
{
.....
......
}
or
if(color != Red_c)
{
....
.....
}Now you know by mistake if you forget one = or ! means if(color = yellow_c) or if(color = Red_c) then no error will come and bug fixing cost for your projects So To avoid this cost you should use
if(yellow_c == color)
{
.....
......
}
or
if(Red_c != color)
{
....
.....
}Now if you forgot to put one = ot ! then compilation error will come.. So this should be in coding standard to use like this...
Truth Can'nt be changed
Oh, a coding standards horror. That only works when comparing an Lvalue and an Rvalue, and if a programmer can remember to do that, then he can remember to use the correct operator in the first place. Newbies will continue to screw it up, and experienced programmers will continue to get it right the first time. One company I worked for did have that in the coding standard, but even the guy who defined the standards admitted that it was pretty useless. If it causes you trouble you could switch to D, which will throw an error if it's not done right (if I recall correctly).
-
In your project, If you are using if condition like
enum
{
Blue_c,
Yellow_c,
Red_c
};
int color;if( color == yellow_c)
{
.....
......
}
or
if(color != Red_c)
{
....
.....
}Now you know by mistake if you forget one = or ! means if(color = yellow_c) or if(color = Red_c) then no error will come and bug fixing cost for your projects So To avoid this cost you should use
if(yellow_c == color)
{
.....
......
}
or
if(Red_c != color)
{
....
.....
}Now if you forgot to put one = ot ! then compilation error will come.. So this should be in coding standard to use like this...
Truth Can'nt be changed
Yes, because actually looking at your warnings is apparently too difficult.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
In your project, If you are using if condition like
enum
{
Blue_c,
Yellow_c,
Red_c
};
int color;if( color == yellow_c)
{
.....
......
}
or
if(color != Red_c)
{
....
.....
}Now you know by mistake if you forget one = or ! means if(color = yellow_c) or if(color = Red_c) then no error will come and bug fixing cost for your projects So To avoid this cost you should use
if(yellow_c == color)
{
.....
......
}
or
if(Red_c != color)
{
....
.....
}Now if you forgot to put one = ot ! then compilation error will come.. So this should be in coding standard to use like this...
Truth Can'nt be changed
Ahh, those with negative men points could always use
#define equals ==
which brings a nice touch to the code
int a = 3; if( a equals 3) { ... }
But why stop here, just add the following
#define if if( #define then ){ #define endif }
And youre code will look like this
if a equals 3 then ... endif
It somehows reminds me of another language, I just can't get my fingers on the name ...
Learn from the mistakes of others, you may not live long enough to make them all yourself.
-
In your project, If you are using if condition like
enum
{
Blue_c,
Yellow_c,
Red_c
};
int color;if( color == yellow_c)
{
.....
......
}
or
if(color != Red_c)
{
....
.....
}Now you know by mistake if you forget one = or ! means if(color = yellow_c) or if(color = Red_c) then no error will come and bug fixing cost for your projects So To avoid this cost you should use
if(yellow_c == color)
{
.....
......
}
or
if(Red_c != color)
{
....
.....
}Now if you forgot to put one = ot ! then compilation error will come.. So this should be in coding standard to use like this...
Truth Can'nt be changed
You haven't dealt with object equality. I know as a random key monkey, it's very dificult for me to remember that
objA == objB
is not the same asobjA.equals(objB)
Can you provide the best answer. I have to get the bugs out of the LCG framework before Thursday!
Panic, Chaos, Destruction. My work here is done.
-
In your project, If you are using if condition like
enum
{
Blue_c,
Yellow_c,
Red_c
};
int color;if( color == yellow_c)
{
.....
......
}
or
if(color != Red_c)
{
....
.....
}Now you know by mistake if you forget one = or ! means if(color = yellow_c) or if(color = Red_c) then no error will come and bug fixing cost for your projects So To avoid this cost you should use
if(yellow_c == color)
{
.....
......
}
or
if(Red_c != color)
{
....
.....
}Now if you forgot to put one = ot ! then compilation error will come.. So this should be in coding standard to use like this...
Truth Can'nt be changed
Guideline 1: Always compile cleanly on warning level 4.
-- Time you enjoy wasting is not wasted time - Bertrand Russel
-
Real
C
programmers (i.e. real men) don't use such girly tricks. They bravely make mistakes whenever is needed. ;PIf the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]I am not talking about a single or some person who can take care his code itself nicely. But when you will come to some big organization then Why they follows some process becausethey want minimize defects, minimize manpower,etc. So this small care can save some time .
Truth Can'nt be changed
-
I am not talking about a single or some person who can take care his code itself nicely. But when you will come to some big organization then Why they follows some process becausethey want minimize defects, minimize manpower,etc. So this small care can save some time .
Truth Can'nt be changed
asadullah ansari wrote:
minimize manpower
Hence not a real-men company! BTW What is the point on minimizing manpower in software industry? Our work is creative after all, don't you agree? The Software Laborer :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Ahh, those with negative men points could always use
#define equals ==
which brings a nice touch to the code
int a = 3; if( a equals 3) { ... }
But why stop here, just add the following
#define if if( #define then ){ #define endif }
And youre code will look like this
if a equals 3 then ... endif
It somehows reminds me of another language, I just can't get my fingers on the name ...
Learn from the mistakes of others, you may not live long enough to make them all yourself.
LOL. I remember someone suggesting defines like this:
#define please
#define thanksAnd the code would be much more pleasant to read:
please do {
...
} while (i < imax);
thanks -
Guideline 1: Always compile cleanly on warning level 4.
-- Time you enjoy wasting is not wasted time - Bertrand Russel
Johann Gerell wrote:
Guideline 1: Always compile cleanly on warning level 4.
Gudeline 2: Turn on the option: "Treat warnings as errors".
-
LOL. I remember someone suggesting defines like this:
#define please
#define thanksAnd the code would be much more pleasant to read:
please do {
...
} while (i < imax);
thanksDoesn't LOLCode do something similar to this?
HAI
CAN HAS STDIO?
PLZ OPEN FILE "LOLCATS.TXT"?
AWSUM THX
VISIBLE FILE
O NOES
INVISIBLE "ERROR!"
KTHXBYEImagine that you are hired to build a bridge over a river which gets slightly wider every day; sometimes it shrinks but nobody can predict when. Your client provides no concrete or steel, only timber and cut stone (but they won't tell you what kind). The coefficient of gravity changes randomly from hour to hour, as does the viscosity of air. Your only tools are a hacksaw, a chainsaw, a rubber mallet, and a length of rope. Welcome to my world. -Me explaining my job to an engineer
-
In your project, If you are using if condition like
enum
{
Blue_c,
Yellow_c,
Red_c
};
int color;if( color == yellow_c)
{
.....
......
}
or
if(color != Red_c)
{
....
.....
}Now you know by mistake if you forget one = or ! means if(color = yellow_c) or if(color = Red_c) then no error will come and bug fixing cost for your projects So To avoid this cost you should use
if(yellow_c == color)
{
.....
......
}
or
if(Red_c != color)
{
....
.....
}Now if you forgot to put one = ot ! then compilation error will come.. So this should be in coding standard to use like this...
Truth Can'nt be changed
It's easier for me to remember the == than it is to remember to write the condition backwards.
-
In your project, If you are using if condition like
enum
{
Blue_c,
Yellow_c,
Red_c
};
int color;if( color == yellow_c)
{
.....
......
}
or
if(color != Red_c)
{
....
.....
}Now you know by mistake if you forget one = or ! means if(color = yellow_c) or if(color = Red_c) then no error will come and bug fixing cost for your projects So To avoid this cost you should use
if(yellow_c == color)
{
.....
......
}
or
if(Red_c != color)
{
....
.....
}Now if you forgot to put one = ot ! then compilation error will come.. So this should be in coding standard to use like this...
Truth Can'nt be changed
When posting to the forums, it's perfectly acceptable to post C/C++ questions in the C# forum because they've all got C somewhere in there name. Of course, this also means you can ask COBOL questions in there as well but that's the price you pay. Sod it - you can always throw Java questions in there because they've got curly brackets as well.
Deja View - the feeling that you've seen this post before.
-
Johann Gerell wrote:
Guideline 1: Always compile cleanly on warning level 4.
Gudeline 2: Turn on the option: "Treat warnings as errors".
-
Guideline 1: Always compile cleanly on warning level 4.
-- Time you enjoy wasting is not wasted time - Bertrand Russel
-
Actually, writing if (x = 0) ... does not generate any warning at all (at least in VS 2005). Looks like this is a flaw in the compilor.
ed welch wrote:
Actually, writing if (x = 0) ... does not generate any warning at all (at least in VS 2005).
Of course it does. But you have to enable warning level 4 (as I pointed out in the "guideline") in the project property pages under C/C++ > General. Then you get this:
warning C4706: assignment within conditional expression
If you also set that warnings should be treated as errors, you get this:
error C2220: warning treated as error - no 'object' file generated
warning C4706: assignment within conditional expressionand that way you just cannot miss the assignment.
-- Time you enjoy wasting is not wasted time - Bertrand Russel
-
Actually, writing if (x = 0) ... does not generate any warning at all (at least in VS 2005). Looks like this is a flaw in the compilor.
Depends on the compiler: Borland C++ 5.5 for Win32 reports: Warning W8060 xtc.c 14: Possibly incorrect assignment in function main As usual, HP C V7.3-009 on OpenVMS Alpha V8.3 takes it to a whole other level: CHECK Messages reporting code or practices that, although correct and perhaps portable, are sometimes considered ill-advised because they can be confusing or fragile to maintain. For example, assignment as the test expression in an "if" statement. NOTE: The check group gets defined by enabling LEVEL5 messages. LEVEL4 Useful check/portable messages. LEVEL5 Not so useful check/portable messages. CC/WARNING=(ENABLE=LEVEL5,VERBOSE) TEST.C if ( argc = 1 ) ....^ %CC-I-CONTROLASSIGN, In this statement, the assignment expression "argc=1" is used as the controlling expression of an if, while or for statement. at line number 14 in file MY$ROOT:[000000]TEST.C;2 Description: A common user mistake is to accidentally use assignment operator "=" instead of the equality operator "==" in an expression that controls a transfer. For example sayin g if (a = b) instead of if (a == b). While using the assignment operator is valid, it is often not what was intended. When this message is enabled, the compiler will detect these cases at compile-time. This can often avoid long debugging sessions needed to find the bug in the user's program. User Action: Make sure that the assignment operator is what is expected. printf ( "Hello, %s!" , argv [ 1 ] ) ; ........^ %CC-I-IGNORECALLVAL, In this statement, the value returned from the function "printf(...)" is not used - if this is intended, it should be cast to "void". at line number 16 in file MY$ROOT:[000000]TEST.C;2 Description: A function that returns a value has been invoked, yet the value was not used. This might not have been what you intended. User Action: Cast the function to void to suppress the message. CC/WARNING=(ENABLE=CONTROLASSIGN) TEST.C if ( argc = 1 ) ....^ %CC-I-CONTROLASSIGN, In this statement, the assignment expression "argc=1" is used as the controlling expression of an if, while or for statement. at line number 14 in file MY$ROOT:[000000]TEST.C;2
-
Depends on the compiler: Borland C++ 5.5 for Win32 reports: Warning W8060 xtc.c 14: Possibly incorrect assignment in function main As usual, HP C V7.3-009 on OpenVMS Alpha V8.3 takes it to a whole other level: CHECK Messages reporting code or practices that, although correct and perhaps portable, are sometimes considered ill-advised because they can be confusing or fragile to maintain. For example, assignment as the test expression in an "if" statement. NOTE: The check group gets defined by enabling LEVEL5 messages. LEVEL4 Useful check/portable messages. LEVEL5 Not so useful check/portable messages. CC/WARNING=(ENABLE=LEVEL5,VERBOSE) TEST.C if ( argc = 1 ) ....^ %CC-I-CONTROLASSIGN, In this statement, the assignment expression "argc=1" is used as the controlling expression of an if, while or for statement. at line number 14 in file MY$ROOT:[000000]TEST.C;2 Description: A common user mistake is to accidentally use assignment operator "=" instead of the equality operator "==" in an expression that controls a transfer. For example sayin g if (a = b) instead of if (a == b). While using the assignment operator is valid, it is often not what was intended. When this message is enabled, the compiler will detect these cases at compile-time. This can often avoid long debugging sessions needed to find the bug in the user's program. User Action: Make sure that the assignment operator is what is expected. printf ( "Hello, %s!" , argv [ 1 ] ) ; ........^ %CC-I-IGNORECALLVAL, In this statement, the value returned from the function "printf(...)" is not used - if this is intended, it should be cast to "void". at line number 16 in file MY$ROOT:[000000]TEST.C;2 Description: A function that returns a value has been invoked, yet the value was not used. This might not have been what you intended. User Action: Cast the function to void to suppress the message. CC/WARNING=(ENABLE=CONTROLASSIGN) TEST.C if ( argc = 1 ) ....^ %CC-I-CONTROLASSIGN, In this statement, the assignment expression "argc=1" is used as the controlling expression of an if, while or for statement. at line number 14 in file MY$ROOT:[000000]TEST.C;2
PIEBALDconsult wrote:
As usual, HP C V7.3-009 on OpenVMS Alpha V8.3 takes it to a whole other level:
Wow! I wonder how much money HP could get by porting their warning reporter into a visual studio plugin?
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Johann Gerell wrote:
Guideline 1: Always compile cleanly on warning level 4.
Gudeline 2: Turn on the option: "Treat warnings as errors".
Nemanja Trifunovic wrote:
Gudeline 2: Turn on the option: "Treat warnings as errors".
I do that for release builds, but not debug.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke