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
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
-
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!Exactly right. Those who just insert
ASSERT( pMem != NULL);would remove the air-bags from a car after the manufacturer is finished testing and are ready to sell you the car. (i.e. they don't realize that a lot (most?) problems occur "in the field" and NOT in debug mode).