• Write clean code the first time through. Don't write messy code and promise yourself that you'll "clean it up later".
• Recognize that clean code is better than fast code. It's easy for clean code to be made fast, but hard for fast code to be made clean.
• Counter tip: Don't be so obsessed with clean code that your project's progress stalls.
• Avoid macroes, except when they make your code easier, safer, and cleaner.
• Avoid globals, except when they make your code easier, safer, and cleaner.
• Avoid gotos, except when they make your code easier, safer, and cleaner.
• Avoid people that say macroes, globals, and gotos are perfectly fine.
• Avoid people that say macroes, globals, and gotos are never allowed.
• Listen to people that say macroes, globals, and gotos should be rarely* used, but who recognize exceptions.
• Use RAII, Single Responsibility Principle, and other similar concepts.
• Don't embed content into code - load content from file or something similar.
• Create and use a consistent coding style for your code.
• Use the C++11 smart pointers and std::make_shared(). (use Boost's versions if you can't use C++11)
• Avoid calling 'new' and 'delete' yourself, except in the rare situations** where they are required.
• Don't re-invent the wheel, unless it's a small wheel, isn't in the standard library, and won't take you long.
• Make your code as self-documenting as possible, so it can be easily understood without comments.
• Comment the code it anyway.
• Finish the projects and features you start.
• After you learn to finish the projects or you start, then learn to shoot the projects or features that need to die.
• Worry about writing poor code. Aim for high quality code, or at least good code.
• Don't worry about writing perfect code.
• Really. Don't worry about writing perfect code.

*90% of the time, a global shouldn't be a global, 95% of the time, a macro should be a template or a regular function, 99.9% of the time, a goto is being misused. 100% of these percentages are made up, but illustrate a point anyway. =)

**I find that it's rare, but not extremely rare. For performance reasons, probably 19 out of 20 of my dynamic allocations should be smart pointers - but I suppose that would vary from project to project. The vast majority allocations should be on the stack, and neither smart pointers nor raw allocations.

Lots of good points in the previous posts. I'll second the point of designing ahead of the code. Don't implement any features you don't really need, and know what you do need before you start implementing stuff :) A 100% detailed design upfront would be nice, but not usually possible. But you at least need an overall game design, and a decent amount of full detailed stuff plotted out before you get coding.

For example, you might have a few levels planned out for a side scroller, with various platform and enemy types in them. Once you code all that up, you have all those components to mix and match in new, not-pre-planned levels, and maybe think of ideas for some more things to add. But you need those first levels designed before you start coding, or you risk falling into the trap of "engine" coding, which often results in lots of those unnecessary features :)

Also, use a coding style appropriate to the complexity of the game. Full C++/OO/RAII/smart pointer style is great for most things, but maybe a little overboard for Pac Man. If your game is similar to something done on SNES or earlier, chances are it was written in assembly with little if any heap allocation (usually using statically allocated pools for things that are dynamic in nature, but have a maximum number that can be on screen at a given time), and probably wouldn't run into many difficulties coding it in C.

And when commenting code, don't go overboard. Usually it will do to give a quick plain-English overview of what a function is trying to accomplish, or a block of code in longer functions. Only comment line by line if you're doing something particularly confusing, such as highly optimized code.

Quality content creation is time consuming. Background graphics, animations, sound effects, music, level design. But don't involve other people in your project until you have the design worked out well enough that a) they'll have something moving around on screen soon, and b) you're relatively confident that the project is not going to fizzle out due to excessive complexity or simply not being as much fun to play as you thought it would.

Be aware that 50% of the production time is finishing the last 10% of the game. If it doesn't look "almost done", you've got a long way to go :) But sometimes the transition from looking like a bunch of separate components into being a cohesive whole game can happen pretty much overnight.

I think an object oriented language is the way to go for organization and maintenance (not speed though but it's fast enough for 99% of the code).

- Encapsulate as much as you can. I end up re-factoring my code all the time. To think you'll get it right the first time every time, or that you won't change your mind is silly, and the more you have things encapsulated the easier it'll be to re-factor things around without breaking the things that rely on the code. It also allows for experimenting with new ideas without breaking existing code. Even if you think something is small, encapsulate it because chances are you'll come back and make it more complex eventually and doing this can really make your life easier later.

- Make self containing code as much as possible. The more your code relies on each other the harder it'll be to make changes without breaking a bunch of stuff. This again allows for easier changes that don't break as much code if any. I like using event programming for this so that my objects fire events and other objects can subscribe to these events if they want. This way my objects aren't tightly coupled together (ie the HUD object doesn't need to directly know about the Player object), and don't rely on polling systems which waste time.

- Always make sure your code compiles each day that you are done with it. Don't leave compile errors overnight. Logical errors are OK to leave, but be sure to note them.

- I'll contradict Servant's comment and say, never use goto, global's, or macro's. In my 15 years of programming I've never used goto outside of first learning it. It's simply not needed. Globals took longer for me to realize their danger but eventually I have seen the harm they cause and haven't used one myself (libraries you use might) for probably the last 8 years. Stick to a singleton if you need something like a global. Macro's start out making your code easier and then you start abusing them and they actually end up making your code harder to read & maintain.

- The biggest thing I think is to make your functions small! They should be visible on about 1 "screen". Any bigger than that and it's most likely doing too much and should be split. It will also be harder to maintain than a small specific function. This is important, as it's all to common to see new programmers putting so many things into giant functions. Don't do it! This is worth repeating. Practice doing this until it's second nature. This is a big one.