Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Not specific code writing practices. Please also include reasoning.

My start:

  • use GCC or Clang
    • gcc because it is unchallenged in the amount of static checking it can do (both against standards and general errors)
    • clang cause it has such pretty and meaningful error messages
  • when compiling C code using GCC use -Wall -Wextra -Wwrite-strings -Werror
    • in 99,99% the warning is a valid error
  • when compiling C++ code using GCC use -Wall -Wextra -Weffc++ -Werror
    • you could skip -Weffc++ (cause it can be confusing)
  • always code against a standard C (C89, C99), C++ (C++98, C++0x)
    • while compilers change, standards don't, coding against a standard gives at least some level of assurance that the code will also compile in the next version of the compiler or even a different compiler/platform
  • make sure that the compiler checks your code against standard (-std=c99 -pedantic for C99, -std=ansi -pedantic for C++98 in GCC)
    • cause automatic checking always good
  • use valgrind or a similar tool to check for runtime errors (memory, threads, ...)
    • free bug catching
  • never duplicate functionality of the standard libraries (if there is a bug in your compiler, make a temporary patch, wrapper, ...)
    • there is no chance that your code will be better then the code maintained by hundreds of people and tested by tenths of thousands
  • make sure that you actually fix all bugs that are reported by automatic tools (GCC, valgrind)
    • the errors might not cause your program to crash now, but they will
  • never follow recommendations that include "never use feature X"
    • such recommendations are usually outdated, exaggerated or oversimplified
share

locked by World Engineer 23 hours ago

This question's answer is a collaborative effort: if you see something that can be improved, just edit to improve it! No additional answers can be added here

closed as too broad by Thomas Owens Jul 18 '13 at 22:03

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
I find those advises very useful. Have no idea how this thread has 0 upvotes with 400+ views. –  Kolyunya Jul 19 '13 at 6:52

1 Answer 1

Learn C++ from a book

Unfortunately, most freely available C++ resources are complete garbage.

Use the "Resource Acquisition Is Initialization" idiom (RAII)

This takes care of 90% of your memory management problems. The other 10% can be taken care of with smart pointers (which themselves depend on RAII). Even though the language is not garbage-collected, I've never had to use a delete statement or some kind of DestroyXXX() or ReleaseXXX() or CloseXXX() function in application code - they're always somewhere deep in library/wrapper code.

It's the reason why std::vector allows for dynamic arrays without new or delete and fstream allows for manipulation of files without needing fopen() or fclose() in application code - it's all been taken care of.

Compile with aggressive optimization when you test

(e.g. GCC's -O3 switch). This will often uncover bugs arising from subtle things like violation of [strict aliasing rules][1]. By doing so, you become aware of such issues, and your program will work properly in the presence of such optimizations.

Test on a PowerPC (or other big-endian machine) from time to time

Better yet, test on a 64-bit PowerPC if you can get your hands on one. Things you can learn by doing so:

  • When reading a binary file, you have to pack/unpack 16-bit, 32-bit, 64-bit, etc. words a byte at a time, or use some sort of endian-aware byte-swapping mechanism.
  • char is not always signed. On PowerPC Linux, GCC defaults to unsigned char. This isn't an endianness issue, but it's a subtlety I picked up on while testing on both x86 and PowerPC.
  • Big endian won't let you get away with long n = ...; printf("%d", n);
  • 64-bit big endian won't let you get away with:

    curl_easy_setopt(handle, CURLOPT_TIMEOUT, 1);
    

    See if you can spot the bug.

Always pay attention to recommendations that say "never use feature X"

  • Such recommendations are typically based on the experience of lots of skilled people over a significant period of time.
  • If you choose to disregard such recommendations, make sure that you really understand them and the rationale behind them, before you disregard them.
  • If you choose to ignore them out of hand, don't be surprised if people criticize your code.
share
3  
There is such a thing as a bad C++ book (e.g. anything by Herbert Schildt), and there are C++ online resources that are quite good (stuff by people who actually know what they're talking about, like GotW, C++ FAQ Lite, and of course Stack Overflow). But generally, you're right. –  In silico Nov 24 '10 at 0:47
    
would you mind explaining more on what it does and why do you recommend it as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange –  gnat Jul 16 '13 at 9:21
3  
@gnat: You.. don't know what a book does? –  Lightness Races in Orbit Jul 17 '13 at 17:44
    
(But, yes, this probably should have been a comment.) –  Lightness Races in Orbit Jul 17 '13 at 17:44
    
@LightnessRacesinOrbit well since I didn't read it, I sure don't. That's why I ask to explain more, fair enough? ...if you are standing at 100 Main St. and you ask where 98 Main St. is... "I'll direct you to a tourism information booth, and they will be able to provide you with your answer and much more!" –  gnat Jul 17 '13 at 17:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.