Coding standards?
-
:eek: :eek: :eek: Until I started working on a debugging tool this week, I've written one macro ( mid, to return a value clamped between two values ). Macros are evil, in fact Stroustrup says they are usually indicative of bad design. He must have consulted there before you did. :-) Christian After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
Sonork ID 100.10002:MeanManOz
I live in Bob's HungOut now
I also find it hard to believe some of this code was written by someone with 10+ years experience and a Master's Degree. You can lead a horse to university, but you can't educate him. :)
-
I can't believe my eyes. I was looking over some code we were supposed to port for use in a W2K COM project. I found the previous authors had created about 800 lines of macros, divided into about 25+ header files (some with just one line). Their implementation was basically nothing more than calling these macros. No exception handling, code formatted with no regard to tabs, 30-40 blank lines in the middle of a routine. What gets even worse is the lead developer for this project thinks this is the best they can produce. Makes me glad to be a consultant. One, I'll always have work fixing their work, and two I can leave when the axe begins to fall.;P
#ifdef NULL #undef NULL #define NULL 0 Why did you do this? Because we wanted to define what NULL was. :confused:
-
I can't believe my eyes. I was looking over some code we were supposed to port for use in a W2K COM project. I found the previous authors had created about 800 lines of macros, divided into about 25+ header files (some with just one line). Their implementation was basically nothing more than calling these macros. No exception handling, code formatted with no regard to tabs, 30-40 blank lines in the middle of a routine. What gets even worse is the lead developer for this project thinks this is the best they can produce. Makes me glad to be a consultant. One, I'll always have work fixing their work, and two I can leave when the axe begins to fall.;P
It's really sad that there are so many people claiming to be software engineers, when all they engineer are poorly constructed designs and badly written code. Imho, unaware and undereducated managers shoulder a lot of the blame for this unhappy state of affairs. I think things will change only when the software development industry is held accountable like other industries such as makers of airplanes, toasters and water heaters. /ravi "There is always one more bug..." ravib@ravib.com http://www.ravib.com
-
I can't believe my eyes. I was looking over some code we were supposed to port for use in a W2K COM project. I found the previous authors had created about 800 lines of macros, divided into about 25+ header files (some with just one line). Their implementation was basically nothing more than calling these macros. No exception handling, code formatted with no regard to tabs, 30-40 blank lines in the middle of a routine. What gets even worse is the lead developer for this project thinks this is the best they can produce. Makes me glad to be a consultant. One, I'll always have work fixing their work, and two I can leave when the axe begins to fall.;P
No exception handling Woohoo, at least he did one thing right. ;) Other than the fact that I can't use exception handling in WinCE, I find that most people don't have a clue how to properly use it. They just sort of throw it in because they think they should. Then don't really do anything with it. There are the cases where some moron decided that an exception was MUCH better than just returning a simple failure flag. Whine whine whine :) Tim Smith Descartes Systems Sciences, Inc.
-
No exception handling Woohoo, at least he did one thing right. ;) Other than the fact that I can't use exception handling in WinCE, I find that most people don't have a clue how to properly use it. They just sort of throw it in because they think they should. Then don't really do anything with it. There are the cases where some moron decided that an exception was MUCH better than just returning a simple failure flag. Whine whine whine :) Tim Smith Descartes Systems Sciences, Inc.
I'll agree that a lot don't know how to properly use SEH, but in a system that is supposed to be 99.999% reliable (contract requirements), not using any is just outrageously poor design.
-
I'll agree that a lot don't know how to properly use SEH, but in a system that is supposed to be 99.999% reliable (contract requirements), not using any is just outrageously poor design.
Actually, I totally disagree. exceptions != reliability. (But I will say that in many cases exceptions can make your life easier.) Of course, software controlled exceptions are ok.
if (i != 22)
throw CBadBoyException ();However, that 'can' be replaced by.
if (i != 22)
return false;Of course, this model has all sorts of drawbacks. The first one being that if the programmer doesn't check return values, then returning false doesn't do a damn bit of good either. However, exceptions have the same type of pitfalls. One of the basic theories is that during a given operation, if an exception is thrown, then all of the operation is rolled back. Thus, the operation is basically atomic. (i.e. An exception during a std::map operation will leave the map valid and in the prior state.) However, programmers have a bad habit of not properly checking for exception when partial operations need to be rolled back. Then we get into other exceptions such as out of memory. Now in theory, a program should survive and out of memory exception and handle it properly. However, in the real world, there are many cases where the program can't function properly without the memory. Then it becomes a question of does the program abend gracefully. The final type of exception is a hardware exception such as an access violation. Many people think they can continue from a general out of the blue access violation. But realistically, can the application be trusted to operate reasonable after that type of failure? Only god knows what data might have been damaged. This is especially critical in mission critical applications. Your program has just faulted, do you really trust it to continue to control equipment that might put a person's life in danger. Here again, it becomes a question of dead the program abend gracefully. In general, exceptions shouldn't happen except for well defined and expected cases. An access violation is still a bug, and the bug must be corrected. If for one don't trust an exception handler to try and 'fix' an access violation. Tim Smith Descartes Systems Sciences, Inc.
-
#ifdef NULL #undef NULL #define NULL 0 Why did you do this? Because we wanted to define what NULL was. :confused:
Actually, this is valid code. NULL is different between C and C++. In C, NULL is (void*)0, in C++ it's just 0. If you have code that mixes the two, you might well want to make sure what is defined. -- Where are we going? And why am I in this handbasket?
-
Actually, I totally disagree. exceptions != reliability. (But I will say that in many cases exceptions can make your life easier.) Of course, software controlled exceptions are ok.
if (i != 22)
throw CBadBoyException ();However, that 'can' be replaced by.
if (i != 22)
return false;Of course, this model has all sorts of drawbacks. The first one being that if the programmer doesn't check return values, then returning false doesn't do a damn bit of good either. However, exceptions have the same type of pitfalls. One of the basic theories is that during a given operation, if an exception is thrown, then all of the operation is rolled back. Thus, the operation is basically atomic. (i.e. An exception during a std::map operation will leave the map valid and in the prior state.) However, programmers have a bad habit of not properly checking for exception when partial operations need to be rolled back. Then we get into other exceptions such as out of memory. Now in theory, a program should survive and out of memory exception and handle it properly. However, in the real world, there are many cases where the program can't function properly without the memory. Then it becomes a question of does the program abend gracefully. The final type of exception is a hardware exception such as an access violation. Many people think they can continue from a general out of the blue access violation. But realistically, can the application be trusted to operate reasonable after that type of failure? Only god knows what data might have been damaged. This is especially critical in mission critical applications. Your program has just faulted, do you really trust it to continue to control equipment that might put a person's life in danger. Here again, it becomes a question of dead the program abend gracefully. In general, exceptions shouldn't happen except for well defined and expected cases. An access violation is still a bug, and the bug must be corrected. If for one don't trust an exception handler to try and 'fix' an access violation. Tim Smith Descartes Systems Sciences, Inc.
Out of memory exceptions are the biggest problem with this code. They are allocating it all over the place and never checking it. Since they rely so heavily on macros there is very little return code checking also. In a system that, as I said, is supposed to be 99.999% reliable, you must expect the unexpected and plan for an exception to occur. It is comical that the company is planning on spending thousands on redundant hardware, but doesn't see this type of coding to be of concern. If nothing else the experience has started my weekend with a much need laugh.
-
Out of memory exceptions are the biggest problem with this code. They are allocating it all over the place and never checking it. Since they rely so heavily on macros there is very little return code checking also. In a system that, as I said, is supposed to be 99.999% reliable, you must expect the unexpected and plan for an exception to occur. It is comical that the company is planning on spending thousands on redundant hardware, but doesn't see this type of coding to be of concern. If nothing else the experience has started my weekend with a much need laugh.
-
No exception handling Woohoo, at least he did one thing right. ;) Other than the fact that I can't use exception handling in WinCE, I find that most people don't have a clue how to properly use it. They just sort of throw it in because they think they should. Then don't really do anything with it. There are the cases where some moron decided that an exception was MUCH better than just returning a simple failure flag. Whine whine whine :) Tim Smith Descartes Systems Sciences, Inc.
Funny you should mention that. Altough I understand the concepts, I really have never been able to implement anything I was satisfied with. Do you know of any good reading material on some good exception handling techniques? Thanks, Marcus
-
Funny you should mention that. Altough I understand the concepts, I really have never been able to implement anything I was satisfied with. Do you know of any good reading material on some good exception handling techniques? Thanks, Marcus
-
Ack! No I don't. Even though I understand the theory behind exceptions, in practice I am of 'questionable' ability. Which probably colors my opinion on them. :) Tim Smith Descartes Systems Sciences, Inc.
Ditto....That's alright, exceptions are lame anyway. ;) Thanks, Marcus
-
Ditto....That's alright, exceptions are lame anyway. ;) Thanks, Marcus
marcus78 wrote: Ditto....That's alright, exceptions are lame anyway. Ditto 2 Regardz Colin J Davies
Sonork ID 100.9197:Colin
I live in Bob's HungOut now
-
It's really sad that there are so many people claiming to be software engineers, when all they engineer are poorly constructed designs and badly written code. Imho, unaware and undereducated managers shoulder a lot of the blame for this unhappy state of affairs. I think things will change only when the software development industry is held accountable like other industries such as makers of airplanes, toasters and water heaters. /ravi "There is always one more bug..." ravib@ravib.com http://www.ravib.com
Ravi Bhavnani wrote: I think things will change only when the software development industry is held accountable like other industries such as makers of airplanes, toasters and water heaters. I agree with you but I really do have to wonder whether my toaster manufacture can be held accountable. About 6.53 times out of 10 the toast pops out so vigourously that it lands on the floor. Every time it happens I stand their jaw dropped wondering how in this day and age such a thing is possible.:confused: Neville Franks, Author of ED for Windows. www.getsoft.com
-
Ravi Bhavnani wrote: I think things will change only when the software development industry is held accountable like other industries such as makers of airplanes, toasters and water heaters. I agree with you but I really do have to wonder whether my toaster manufacture can be held accountable. About 6.53 times out of 10 the toast pops out so vigourously that it lands on the floor. Every time it happens I stand their jaw dropped wondering how in this day and age such a thing is possible.:confused: Neville Franks, Author of ED for Windows. www.getsoft.com
Neville Franks wrote: About 6.53 times out of 10 the toast pops out so vigourously that it lands on the floor. Really? That's so cool. Can you get some MPEG footage of this? I'm more than happy to post it on CodeProject purely for the giggle factor. cheers, Chris Maunder
-
I can't believe my eyes. I was looking over some code we were supposed to port for use in a W2K COM project. I found the previous authors had created about 800 lines of macros, divided into about 25+ header files (some with just one line). Their implementation was basically nothing more than calling these macros. No exception handling, code formatted with no regard to tabs, 30-40 blank lines in the middle of a routine. What gets even worse is the lead developer for this project thinks this is the best they can produce. Makes me glad to be a consultant. One, I'll always have work fixing their work, and two I can leave when the axe begins to fall.;P
I guess it's always the case that the other peoples code doesn't look the way we would expect it to. I am not sure about the macros and exceptions problem because it often depends on the problem and implementation and it might be justified. However the bad formatting of the code is quite bad. The 30-40 blank lines is really bad. If I was a manager and some of my people would produce blank lines like that I would simply fire the guy on the spot. People who do not take a second to review their code and leave mess behind are only to cause the troubles in the (near) future. People who review their code and think that's OK are not worthy to keep either. In my office the main problem I notice is a lot of copy-paste that leads to a huge multiplicated chunks of code that is a nightmare to maintain. I blame it for the company's policy to code fast and without proper design - that always forces people to take shortcuts to make job done fast.
-
Funny you should mention that. Altough I understand the concepts, I really have never been able to implement anything I was satisfied with. Do you know of any good reading material on some good exception handling techniques? Thanks, Marcus
Do you know of any good reading material on some good exception handling techniques? Exceptional C++ - http://www.gotw.ca/publications/xc++.htm More Exceptional C++ - http://www.gotw.ca/publications/mxc++.htm - Wilka
-
:eek: :eek: :eek: Until I started working on a debugging tool this week, I've written one macro ( mid, to return a value clamped between two values ). Macros are evil, in fact Stroustrup says they are usually indicative of bad design. He must have consulted there before you did. :-) Christian After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
Sonork ID 100.10002:MeanManOz
I live in Bob's HungOut now
****Christian Graus wrote: Macros are evil I disagree. I use them often in code where, if it weren't for speed considerations, i'd use a small subroutine. yes, i could use an inline function, but as i see it, aside from type checking (which isn't really required in the sections of code i'm talking about), inlines and macros are identical. ****Christian Graus wrote: Stroustrup says they are usually indicative of bad design that's quite a broad statement from someone who probably hasn't written every possible program under every possible constraint. :) -c
-
Ravi Bhavnani wrote: I think things will change only when the software development industry is held accountable like other industries such as makers of airplanes, toasters and water heaters. I agree with you but I really do have to wonder whether my toaster manufacture can be held accountable. About 6.53 times out of 10 the toast pops out so vigourously that it lands on the floor. Every time it happens I stand their jaw dropped wondering how in this day and age such a thing is possible.:confused: Neville Franks, Author of ED for Windows. www.getsoft.com
Neville, In the US, we have a non-profit watchdog organization (Consumer's Union) that publishes a monthly magazine (Consumer's Report) in which they review household kitchen appliances, among other things. The magazine accepts no advertising and has been partially responsible for exposing the truth about the Suzuki Samurai in the '80s. I think your errant toaster would make it to the magazine if you wrote to them and it was sold in the US. PS: Ed looks very cool! /ravi "There is always one more bug..." http://www.ravib.com ravib@ravib.com
-
****Christian Graus wrote: Macros are evil I disagree. I use them often in code where, if it weren't for speed considerations, i'd use a small subroutine. yes, i could use an inline function, but as i see it, aside from type checking (which isn't really required in the sections of code i'm talking about), inlines and macros are identical. ****Christian Graus wrote: Stroustrup says they are usually indicative of bad design that's quite a broad statement from someone who probably hasn't written every possible program under every possible constraint. :) -c
Chris Losinger wrote: I use them often in code where, if it weren't for speed considerations, i'd use a small subroutine. Before yesterday I had a couple I used, I suspect in similar circumstances to you, when I need a small routine inside a loop iterating over an image's bits. I've had to write several over the past day, because of the nature of the code I am working on. I still believe they are an option to only use after careful consideration of available options. Chris Losinger wrote: that's quite a broad statement from someone who probably hasn't written every possible program under every possible constraint. I'm not sure why you're discounting the fact that he has had to consider the broadness of uses for C++ when he designed it. Christian After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
Sonork ID 100.10002:MeanManOz
I live in Bob's HungOut now
