C++ professional disagreements at 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
-
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
-
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
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".
-
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
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.
-
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:
I look at it like this: C++ supports many paradigms, and you have to choose which one fits the problem best.
I think what he meant was coding standards, like advoid puting using statement in header files, etc.
======================================= A goal without a plan remains a dream. =======================================
-
Photonman007 wrote:
I look at it like this: C++ supports many paradigms, and you have to choose which one fits the problem best.
I think what he meant was coding standards, like advoid puting using statement in header files, etc.
======================================= A goal without a plan remains a dream. =======================================
Oh, I realize that, I was analogizing.
-
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...
-
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
Tell them to write a book.
Steve
-
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