C++ professional disagreements at work
-
One recent example would be in "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Sutter and Alexandrescu in item 68 they claim "Assert liberally to document internal assumptions and invariants". However, people at work say assertions contaminate the code and have no value, aspecailly in Test Driven Development (which is wrong by my personal experience while working on several huge software products in XP) They say if you really need it, throw exceptions. No point to aseert for null pointers, etc...
Anyone who thinks ASSERTs are bad is an idiot and if I was the boss I'd fire them on the spot. You should only ASSERT things you think (and assume in the code) can never happen. This is not the same as an exception which is normally reserved for things you assume will happen infrequently.
Steve
-
Hi, There are different c++ books around by Herb Sutter, Meyer etc who preach you to program in certain ways and apply cirtain coding practices. You read the books and get convinced that this is the way should be, as books usually have very good arguments. However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry. Moreover, when you refer them to those books they pretty confidently claim that books are wrong. How do you usually act in such situations? Boz
I tell the young squirt to go back to his books and leave programming to experienced professionals.;P
"...a photo album is like Life, but flat and stuck to pages." - Shog9
-
One recent example would be in "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Sutter and Alexandrescu in item 68 they claim "Assert liberally to document internal assumptions and invariants". However, people at work say assertions contaminate the code and have no value, aspecailly in Test Driven Development (which is wrong by my personal experience while working on several huge software products in XP) They say if you really need it, throw exceptions. No point to aseert for null pointers, etc...
For asserts try the argument that they catch bad data inputs due to coding where as exceptions are meant to catch just that, exceptions at runtime. One is used primarily for debug and dev, where as the other is used primarily in release code to catch those instances that you can't prevent. Such as external data providers. Sure, you can use exceptions to catch bad input, but really if the input is due to say forgetting to initialize a pointer, then well, that's a coding error and this is where asserts shine.
This statement is false.
-
Well if you can't offer convincing explication they are wrong you just have to do the way they ask you to do it. Adaptability is a quality. As much as is "offering convincing argument".
Well, only if its a set coding standard. Say in the case of asserts. I wouldn't not use them just because others didn't see the value, unless there was a standard stating not to use asserts. Which should be compiled out of the release build anyway. So its not even present to bloat the release build.
This statement is false.
-
Hi, There are different c++ books around by Herb Sutter, Meyer etc who preach you to program in certain ways and apply cirtain coding practices. You read the books and get convinced that this is the way should be, as books usually have very good arguments. However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry. Moreover, when you refer them to those books they pretty confidently claim that books are wrong. How do you usually act in such situations? Boz
Most of the books that you quoted are really for your own benefit. Such as Meyer's books. Anyone who says his books are bull didn't read them. They're meant to save you some trouble, and go towards your own programming practice to make you more of a professional. If they don't accept it, that's their limitation. Heh... Meyer is mostly speaking to legality of C++ and what the compiler does behind your back and what to watch out for. If you want to have some fun... pull out some items, and challenge em'. Don't know if your environment supports that type of fun or not, but...
This statement is false.
-
Hi, There are different c++ books around by Herb Sutter, Meyer etc who preach you to program in certain ways and apply cirtain coding practices. You read the books and get convinced that this is the way should be, as books usually have very good arguments. However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry. Moreover, when you refer them to those books they pretty confidently claim that books are wrong. How do you usually act in such situations? Boz
While there are many clearly erroneous ways to program, there is no one right way. At best you can present many good suggestions, some of which directly contradict each other. Ironically, your examples, Sutter and Meyers, sometimes do exactly that. They also tend to exagerate, as do us all, the importance of those things they prefer. You should also remember that Sutter, Meyers, Eckel, Liberty, etc. are all self-appointed "experts". Many of these authors haven't worked on large projects in years. As a result, I find their advice sometimes tends to be academic, rather than practical. Also realize that the writers in question are popular partly because they are so good at phrasing their arguments. While I can, for example, explain in detail why some of Meyers suggestions are complete crap, there are others where I can only say "He's wrong, trust me." (To be fair, I find most of his suggestions quite good, especially from his first book, even if I don't always follow his advice.) My suggestion is to read these books, get real life experience, then read then again and formulate your own conclusions. If someone disagrees with you, make a grounded technical argument of your point, with code examples if possible. If they still disagree with you, get over it; odds are neither of you is in the absolute right.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
One recent example would be in "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Sutter and Alexandrescu in item 68 they claim "Assert liberally to document internal assumptions and invariants". However, people at work say assertions contaminate the code and have no value, aspecailly in Test Driven Development (which is wrong by my personal experience while working on several huge software products in XP) They say if you really need it, throw exceptions. No point to aseert for null pointers, etc...
I agree with the two previous comments. ASSERTs are good. Exceptions are for bad input, hardware errors, etc... ASSERTs are for catching programming errors. But if you want reliable code, you also need to expect bad programming therefore
ASSERT( pMem != NULL);is not good enough. You need to do thisif ( pMem == NULL ) { ASSERT(false); return; }The thing is to find a way to balance reliability, performance AND readability! An art form in itself! -
One recent example would be in "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Sutter and Alexandrescu in item 68 they claim "Assert liberally to document internal assumptions and invariants". However, people at work say assertions contaminate the code and have no value, aspecailly in Test Driven Development (which is wrong by my personal experience while working on several huge software products in XP) They say if you really need it, throw exceptions. No point to aseert for null pointers, etc...
Your coworkers are idiots, or fresh out of academia. :)
-- When you see the robot, drink!
-
You can't just go with one idea or style, or just listen to one source (even Stroustrup says that, mentioning that you should read more than just his or anyone's single book to get a good outlook) I look at it like this: C++ supports many paradigms, and you have to choose which one fits the problem best. Similarly, I think that it is important to have an adaptive style that can change depending on the problem at hand, readability issues, performance issues, etc. If programming has taught me one thing it is to be flexible and open-minded. So look at what the other people are saying objectively and decide for yourself if they have a good point, because they may very well have a damn good one. I hate clichés, but there's more than one way to skin a cat. On the other hand, their ideas may not be so good. There could also be platform issues or other factors that have influenced the way these people program. Just keeping an open mind is, IMHO, the best thing you can do.
Photonman007 wrote:
there's more than one way to skin a cat
Now I'm curious. How many ways are there to skin a cat?
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Hi, There are different c++ books around by Herb Sutter, Meyer etc who preach you to program in certain ways and apply cirtain coding practices. You read the books and get convinced that this is the way should be, as books usually have very good arguments. However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry. Moreover, when you refer them to those books they pretty confidently claim that books are wrong. How do you usually act in such situations? Boz
People who refuse to consider adopting coding styles designed to improve maintainability and reduce the likelyhood of subtle (or not so subtle!) bugs being spotted early are badly misguided. I usually try to lead by example, and when I find a bug that could have been prevented by adopting defensive coding practices I'll make sure I point out how it could be avoided at virtually no cost at the outset. A decent code analysis tool can be an asset here - I use PC-Lint with a very strict warning policy on new code, and its not unknown for it to identify 400,000 or so issues in a large solution (say 80 projects or so). Needless to say many of those will be noise, but there are often a significant number of "nasties" when you dig deeper into the results.
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
Hi, There are different c++ books around by Herb Sutter, Meyer etc who preach you to program in certain ways and apply cirtain coding practices. You read the books and get convinced that this is the way should be, as books usually have very good arguments. However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry. Moreover, when you refer them to those books they pretty confidently claim that books are wrong. How do you usually act in such situations? Boz
It's a personal thing so don't take it personally. Elaine :rose:
-
I tell the young squirt to go back to his books and leave programming to experienced professionals.;P
"...a photo album is like Life, but flat and stuck to pages." - Shog9
OK Grandad ;P
-
Hi, There are different c++ books around by Herb Sutter, Meyer etc who preach you to program in certain ways and apply cirtain coding practices. You read the books and get convinced that this is the way should be, as books usually have very good arguments. However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry. Moreover, when you refer them to those books they pretty confidently claim that books are wrong. How do you usually act in such situations? Boz
I would contend that having a consistent standard is more important than what that standard is. So, if I disagree, I would argue and expect to say what's on my mind. I would argue based on what I have come to think is right, not based on what book I happened to read last. If I lost, I would accept it, and toe the line, to make sure that there was a consistent coding standard in place where I worked.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Hi, There are different c++ books around by Herb Sutter, Meyer etc who preach you to program in certain ways and apply cirtain coding practices. You read the books and get convinced that this is the way should be, as books usually have very good arguments. However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry. Moreover, when you refer them to those books they pretty confidently claim that books are wrong. How do you usually act in such situations? Boz
borlip wrote:
However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry.
Well, who are these people? If they ARE your sr people and have set the standard for your enviroment. Listen to them, it does make it easier for others to follow what has been done. If they ARE the ones who decide to pay you. Case closed.
borlip wrote:
How do you usually act in such situations?
I wish I could send them to Roger.
"Yes I know the voices are not real. But they have some pretty good ideas."
-
While there are many clearly erroneous ways to program, there is no one right way. At best you can present many good suggestions, some of which directly contradict each other. Ironically, your examples, Sutter and Meyers, sometimes do exactly that. They also tend to exagerate, as do us all, the importance of those things they prefer. You should also remember that Sutter, Meyers, Eckel, Liberty, etc. are all self-appointed "experts". Many of these authors haven't worked on large projects in years. As a result, I find their advice sometimes tends to be academic, rather than practical. Also realize that the writers in question are popular partly because they are so good at phrasing their arguments. While I can, for example, explain in detail why some of Meyers suggestions are complete crap, there are others where I can only say "He's wrong, trust me." (To be fair, I find most of his suggestions quite good, especially from his first book, even if I don't always follow his advice.) My suggestion is to read these books, get real life experience, then read then again and formulate your own conclusions. If someone disagrees with you, make a grounded technical argument of your point, with code examples if possible. If they still disagree with you, get over it; odds are neither of you is in the absolute right.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
My suggestion is to read these books, get real life experience, then read then again and formulate your own conclusions.
So true.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table. Shameless Plug - Distributed Database Transactions in .NET using COM+
-
Photonman007 wrote:
there's more than one way to skin a cat
Now I'm curious. How many ways are there to skin a cat?
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Hi, There are different c++ books around by Herb Sutter, Meyer etc who preach you to program in certain ways and apply cirtain coding practices. You read the books and get convinced that this is the way should be, as books usually have very good arguments. However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry. Moreover, when you refer them to those books they pretty confidently claim that books are wrong. How do you usually act in such situations? Boz
What really needs to be done is two things: use version control use a bug tracker then: when a bug occurs in someone's code, track the author and the fix. After a reasonable amount of time, see whose code has the most bugs, and analyze what the bugs were. Come up with some way of factoring out code complexity, and look at whether testing, asserts, comments, smaller methods, etc., resulted in fewer bugs. Until you get empirical (sp?) data showing who the bad programmers are and who the good ones are, and what mistakes the bad ones are making, any book, any best practice, is simply someone's opinion. Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
One recent example would be in "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Sutter and Alexandrescu in item 68 they claim "Assert liberally to document internal assumptions and invariants". However, people at work say assertions contaminate the code and have no value, aspecailly in Test Driven Development (which is wrong by my personal experience while working on several huge software products in XP) They say if you really need it, throw exceptions. No point to aseert for null pointers, etc...
I used to have that the attitude that ASSERTs were contamination when I was young, big ego'd, and naive. I've since learned they protect coders from misusing code snippets or classes without bogging down the release build on performance critical areas. One example would be an XML DOM walker. Your class has a public entry member function with the others private. The entry function does an "if" to check the validity of the pointers passed in, it in turn calls a private function, that calls a private function etc... No need to check the pointers in the subsequent calls since this kills your performance and this is a time critical situation. However, there is no protection from some programmer deciding that he/she can make your class more efficient by adding another public entry point that touches your privates (that didn't sound so good, anyway...). Oops, they forgot to check one of the inputs. Your ASSERTs on down the line will inform them of their folly (assuming they aren't also the kind of programmer that claims debug builds are for wimps):|
-- modified at 10:15 Saturday 22nd July, 2006
-
What really needs to be done is two things: use version control use a bug tracker then: when a bug occurs in someone's code, track the author and the fix. After a reasonable amount of time, see whose code has the most bugs, and analyze what the bugs were. Come up with some way of factoring out code complexity, and look at whether testing, asserts, comments, smaller methods, etc., resulted in fewer bugs. Until you get empirical (sp?) data showing who the bad programmers are and who the good ones are, and what mistakes the bad ones are making, any book, any best practice, is simply someone's opinion. Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
Hi, There are different c++ books around by Herb Sutter, Meyer etc who preach you to program in certain ways and apply cirtain coding practices. You read the books and get convinced that this is the way should be, as books usually have very good arguments. However, later, at work place you meet people who don't necessary read those books and definetely have their strong openions as they appear to be quite senior in the industry. Moreover, when you refer them to those books they pretty confidently claim that books are wrong. How do you usually act in such situations? Boz
Every workplace has situations where you have to prove your methodology is correct beyond simply quoting a book or article regardless of the author. That's even more the case at places like Microsoft where things are extremely competitive and many of those authors work here and have competing opinions. I feel your pain however as when I was younger I would do the same thing - read a book by a noted "expert" and feel like "Wow! I've learned something and now can go spread the word." Problem is that most times - unless you're the accepted guru in which case you don't have to worry about quoting others - you're going to have to prove your case. Therefore, my advice would be that when your read an opinion, play devil's advocate in your mind. In other words, instead of merely accepting the author's word, actually make a point of trying to disagree with what he/she has to say. Challenge what you're reading and come up with oposing theories. See if the author addresses those concerns. Test where you think the author's opinions are wrong. When you do that, you'll be much better prepared to respond to others that want to disagree with you because you will have already gone down that path. The ability to intellectually defend your arguments will not only increase your credibility, but eventually it will create an environment where you're not challenged as often as people will know that you've already done your homework and verified that your statements are valid.
Hit & Run Poster Warning: If you want me to reply, you'll need to email me directly as I rarely have time to continually check back for responses. Tom Archer (blog) Program Manager - Windows SDK Headers, Libraries & Tools MICROSOFT
-- modified at 12:32 Saturday 22nd July, 2006