Chris Nelson While learning to write good (better) code is a life-long journey, I think that there are three significant events in my career:First, while employed in a Fortune 100 company, my group all took training in structured design (the "Yourdon" methodology, FWIW). That taught me the importance of loose coupling, well defined interfaces, and code reviews.Second, I had the good fortune to read "Software Tools" by Kernighan & Plauger [1]. I regard this as possibly the single best source on software engineering. (Bryan Oakley sez a big AMEN to that. It had a bigger impact on my coding skills than any thing else, by a long shot)Third, as part of my MS studies in Computer Science, I took a course on "provably correct systems". While I initially thought that the course would be interesting, though abstract and useless, it may be the single course that has most influenced my coding style.That said, I endorse reading good code and code reviews as important parts of the on-going process of learning to write better code.
Arjen Markus I have read a fair number of books, for instance Kernighan and Pike's The Practice of Programming (which I highly recommend), but the only way (as far as I can see) to improve the quality of the code you write is: keep it simple, keep it clear, do not try to be smart, and above all: learn from other people's coding habits.Oh, and be keen on learning a better style!
Mark Roseman Having people write thorough automated tests for their code (using e.g. tcltest) also results in a dramatic increase in code quality. It forces thinking about error handling, corner cases, appropriate factoring and modularity, and maintainability.
One place to start might be with making sure that the quality of source code that you produce is good. This can be summed up by two words: readability and testability.
NEM IIRC I read in The Art of UNIX Programming by Eric Raymond to avoid premature optimisation. This is advice well worth following. It's all too easy to start coding something thinking that it has to be super-efficient, only to end up with a mess of code. Get something simple working first and then profile to see if anything really needs a speed up. This also can be extended to choice of tools. Using a language like Tcl can help you get the code working quickly and reliably, but you can then move to C anything that needs to be faster.DKF - It is the policy of the Core Maintainers to try to help code that is implemented obviously to go fast.
PT By reading good code. The more code you read - the more likely it is that you will encounter some good code. Learn from it and apply to your own.
EKB Andy Hunt and Dave Thomas [2] offer the DRY principle: Don't Repeat Yourself. I think they say something like, "every piece of information should have a single authoritative location in the code."
[Reference to style sheet [3].]
