Where can a self-teacher learn general good programming habits and conventions?

Question

A few mistakes and general childishness in early adulthood have left me in a situation where I work a menial job, with no possibility (in the near future) of attending school. I aspire to one day work in the programming field (gaming specifically), after proving myself on the indie end of things.

I've gotten very confident in C++, java, and python, and I find I'm able to solve any problem I want either from previous experience, or from scouring the web for help. The solutions work, and with each attempt they become more readable, maintainable, and extensible. But this is because I'm learning from mistakes and bad programming and design habits I feel I might have avoided with actual schooling.

General tips like: "if it's hard to read or getting long, or you're writing it twice, it should be in one or more functions." or "design all your classes before you start coding, so you don't have to rewrite classes later when you discover an unforeseen dependency"

Is there a good book or website for learning general good programming practices and design habits?

Also, naming and format conventions. I realize sometimes development houses have their own conventions, but things like "Classes in python usually have the first letter of each word capitalized". I'd like to be able to show some source code to a potential employer, and be prepared when for what's expected on a team. Is there some central database of naming and formatting conventions somewhere?

Also, feel free to give any thoughts on whether or not the self-teach, garner some indie sales, use them as your resume' route is realistic

Answer 1

The Pragmatic Programmer

Answer 2

Code Complete (2nd Ed) by Steve McConnell

Answer 3

[As well as the books previously mentioned]: Read a lot of code. First read some code by the masters - Beautiful Code is a good place to start. Then slowly start to read just 'code', but as you do that, you need to get increasingly critical of what you read. A lot of the code out there in the wild is really awful, and so you need to learn to see the difference. If you want to get a sense for what is really bad, go ahead and read the Daily WTF, as well as looking into Code Smells (2 links).

Answer 4

i would also suggest to go ahead and try to contribute to any open source project that is active and has at least some experienced programmers (as opposed to ones started by 2 newbies like you mentioned).

the process of reading the open source code itself, making a contribution/patch and the reviews of the submitted patch is a great experience i'd recommend.

Answer 5

I would suggest you start by emulating the standard libraries of your language. For example, when you write C++ code, then "good" code will be recognized by being as generic as possible, using objects where necessary, and free functions whenever a member function is not required. The naming convention of your standard library is also a great place to start, since everybody must at least be familar with such conventions.

If you can replace your compiler's default STL implementation depending on nothing but the CRT, and it works, then you're at least on your way to being able to conform to good designs.

I don't personally have experience with Python (and none useful in Java), but I'd run the same advice- write your own implementations of all possible modules/functionality.

Answer 6

Jeff Atwood (one of the creators of this site) has written a blog post about the virtue of open source experience.

Two short quotes from his post:

If you're looking to polish your programming chops, what could possibly be better, more job-worthy experience than immersing yourself in a real live open source software project?

But:

It's disheartening to hear so many prospective employers completely disregard experience on open source projects.

Go read it, and read some of his other posts on the subject (this maybe).

As to your main question, Jeff's post about "learning on the battlefield" should be inspirational too.