Get in the habit of compiling with the highest warning level and with all warnings treated as errors

i actually use second highest warning level, so i don't get 5 billion "yo dude! i'm in-lining this!" warnings. inline is the only warning i get at level 5, so i just kicked it back down to level 4. really i ought to suppress the inline warning and kick it back up to level 5.

i don't treat warnings as errors. that way you can have unused variables in a routine you're writing and still see if it compiles. but in general, the code is written so it generates no warnings (except inline warnings).

and finally, i develop in release mode only. if it works in release mode, it'll work in the final version, which is all that really matters. i've experienced and heard of too many cases like this where incorrect code works in debug but not release mode. so long ago i said to heck with debug mode all together.

for debugging, i use trace variables i can assign values to and then display. for optimization, i use hi-rez timers and the trace variables to time sections of code and display the results.

no debug mode, no debugger, no profiler. its not the usual way of doing things, but it avoids debug vs release mode bugs. its been years since i had a bug complex enough that it even tempted me to use a debugger. and i can hook up a timer to a section of code faster than the profiler can even load! but of all the things i do, clean simple straightforward code is the #1 weapon vs bugs.

Turn on warnings as errors + highest level warnings. Like Sean pointed out, you'll catch a ton of bugs this way before you even spend the time loading up your game to see if it broke. Plus warnings as errors will prevent you from forgetting about warnings in a file that compiled - since the compiler won't re-build a file that only built with non-erroring warnings.

The only inline-related I'm aware of is some compilers will tell you they aren't inlining something you declared inline. But you probably shouldn't be declaring anything inline anyway, since it doesn't do what most people think it does (it allows ODR violations, but doesn't actually inline your code).

I don't know how you even work on anything larger then hello world without a debugger... It's so much easier to knock out almost all of your bugs in debug mode and then only concentrate on stuff that shows up in release in release.

And please, use a profiler. Sticking timers in your code not only doesn't measure what you think it does, but changes the code, thereby changing how fast it runs, how the compiler optimizes it, and either exposing or hiding threading issues and the like. Timers also can't tell you why things are slow, like repeated Load-Hit-Stores or cache misses due to algorithm design or object layout - both things a good profiler can easily show you.