   Simple C++ Efficiancy Stuff - list your own!
  I thought I''d start this to help people be better efficiant in their code. It helps with readability, helps get you a job, and so forth. I don''t have much, but these help me & so it might help you. Feel free to share your own ways.Braces: Keep them lined up together. Otherwise, it''s harder to know what code is inside of them. aka..if (A == 3){   cout << "Congrats." << endl;}Another thing I found was to capitalize your variables. It''s easier to see in the source code. That''s about it too. aka..Player.GetHisAge(22);int Age = 22;   http://phil.webula.netAIM: wuZZup189 
  I guess I could share my style as well.Braces : use Kernighan & Ritchie style.Variables : do not capitalize the first letter of variables, only the following ones (and do not use underscores).Also, add spaces inside brackets.if( A == 3 ) {[indent] cout << "Congrats." << endl;}Namespace::Class myObject;myObject.doSomething( arguments );  Also, use as few "break" and "continue" as possible. Use conditionals and the loop''s parameters as often as possible instead.   Victor Nicollet, INT13 game programmer ;  Use the standard C++ library. Use proven third-party libraries. Don''t waste your time reinventing the wheel (like, say, linked lists). Put your efforts where you''ll get the greatest payback.   “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”    — Brian W. Kernighan (C programming language co-inventor);quote:Original post by Fruny   Use the standard C++ library. Use proven third-party libraries. Don't waste your time reinventing the wheel (like, say, linked lists). Put your efforts where you'll get the greatest payback.   “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”    — Brian W. Kernighan (C programming language co-inventor) Just one damn minute. I made my own version of a doubly linked list a little while ago, and it was a damn good way to jump into building a class. I tend to have a problem with following that idea of yours though. I tend to feel that if I don't try to "reinvent" certain things that I'll not have solid enough experience to invent some things of my own. Sort of a need to want to know everything from the bottom up. Thats my problem then.   [edited by - nervo on February 15, 2004 3:07:36 AM];  New Rule: Let people speak their mind on efficiancy. No one has to agree with each other. Only the compiler does... (lol)   http://phil.webula.netAIM: wuZZup189 ;  I always do the following:All Tabs are 4 spaces, every level of brace is lined up together and the lines within are tabbed once.All variables are done with camel-case, such as myVarAll Functions are done with intial caps, such as MyFunctionAll classes are also with initial caps.Abstract classes are prepended with a lower-case a, Implementation classes are prepended with a lower-case i, Container classes are prepended with a lower-case c,and Factory classes are prepended with a lower-case f.Variables are prepended by type using hungarian style of notation.Private Member variables are prepended by m_ before the previous notations.Static functions are prepended with ST where possible.Const's are prepended with _.All of parenthesis have a space before and after them, such as MyFunction ( myVar ) ;.If you're using VStudio .NET or greater:  everything that can use XML uses XML.Macros, Enumerations, and #defines are all caps and use Underscores to seperate words, like MY_FOOLISH_MACRO or #FLAG_PARAMETER_ONEI've found these practices suit me really well.  I'm sure I do other things too, but I can't think of them.   [edited by - ShadowWolf on February 15, 2004 3:13:44 AM];  He's talking about coding efficiency, not about any learning process. Just remember that your toy code is probably not production-ready.Knowing how to write a linked list probably will not land you a job (not knowing how to write a linked list will definitely   keep you from landing a job). You will be, however, expected to know how and when to use one, as well as when not to, and what the alternatives are.As for style, what matters is to be adaptable. Your employer's coding standards may differ from your own. Three guesses as to which you'll have to use. Learn to recognize valuable code and interesting problems.  “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”    — Brian W. Kernighan (C programming language co-inventor) [edited by - Fruny on February 15, 2004 3:16:49 AM];  Don't use the hungarian notation religously.I find it normally makes code harder to read, its geared to telling about telling the reader about types rather then use and was for a time when ide's could not give that much info on types, better to use informative variable names.Also i've been doing recently is post fixing _i, _o, _io on function parameters and find it helps a lot with readability._i for input (should be const always)_o for output (eg pointers and references)_io for input and output   [edited by - PantherBoy on February 15, 2004 5:41:50 AM];quote:Original post by PantherBoy  Don''t use the hungarian notation religously.Agreed, for the most part hungarian notation smells, descriptive varible names are generaly much better, you also dont get ''type change'' problems, where your float fVar becomes an int fVar, so you either have to change the fVar to iVar (annoying) or you just leave it and then later confusion accurespre-fixing member vars with m_ can be a good idea, i''m still weighting that one up;  a uni prof used to tell us, "a successful software developer requires three things:  faith, hope and clarity"i've always liked that! i try to make my code readable (to me, at least) and lavish it with comments.another stickler point i have is consistancy. like consistantly using the same type of variable and function naming, the same layout and program structures, etc.---craig(at)cod3rz(dot)net   [edited by - craigatcod3rzdotnet on February 15, 2004 10:02:03 AM]