AppendixB - [ViewingHints[ExerciseSolutions[Volume2[FreeNewsletter[Seminars[SeminarsonCDROM[Consulting ThinkinginC,2nded.Volume1

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
Viewing Hints  ] [  Exercise Solutions  ] [  Volume 2  ] [  Free Newsletter  ]  Seminars  ] [  Seminars on CD ROM  ] [  Consulting  ]  Thinking in C++, 2nd ed. Volume 1 ©2000 by Bruce Eckel Previous Chapter  ] [  Table of Contents  ] [  Index  ] [  Next Chapter  ]  B: Programming Guidelines This appendix is a collection of suggestions for C++ programming. They’ve been  assembled over the course of my teaching and programming experience and also from the insights of friends including Dan Saks (co-author with Tom Plum of  C++  Programming Guidelines , Plum Hall, 1991), Scott Meyers (author of  Effective C++ , 2 nd  edition,  Addison-Wesley, 1998), and Rob Murray (author of  , Addison-Wesley,  1993). Also, many of the tips are summarized from the pages of  Thinking in C++ 1. First make it work, then make it fast. This is true even if you are certain that a piece of code  is really important and that it will be a principal bottleneck in your system. Don’t do it. Get  the system going first with as simple a design as possible. Then if it isn’t going fast enough,  profile it. You’ll almost always discover that “your” bottleneck isn’t the problem. Save your  time for the really important stuff. 2. Elegance always pays off. It’s not a frivolous pursuit. Not only does it give you a program  that’s easier to build and debug, but it’s also easier to understand and maintain, and that’s  where the financial value lies. This point can take some experience to believe, because it can  seem that while you’re making a piece of code elegant, you’re not being productive. The  productivity comes when the code seamlessly integrates into your system, and even more so  when the code or system is modified. 3. Remember the “divide and conquer” principle. If the problem you’re looking at is too  confusing, try to imagine what the basic operation of the program would be, given the  existence of a magic “piece” that handles the hard parts. That “piece” is an object – write the  code that uses the object, then look at the object and encapsulate  its  hard parts into other  objects, etc. 4. Don’t automatically rewrite all your existing C code in C++ unless you need to significantly  change its functionality (that is, don’t fix it if it isn’t broken).  Recompiling  C in C++ is a  valuable activity because it may reveal hidden bugs. However, taking C code that works fine  and rewriting it in C++ may not be the best use of your time, unless the C++ version will  provide a lot of opportunities for reuse as a class. 5. If you do have a large body of C code that needs changing, first isolate the parts of the code 
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 08/10/2011 for the course IT 331 taught by Professor Nevermind during the Spring '11 term at King Abdulaziz University.

Page1 / 8

AppendixB - [ViewingHints[ExerciseSolutions[Volume2[FreeNewsletter[Seminars[SeminarsonCDROM[Consulting ThinkinginC,2nded.Volume1

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online