| I'd suggest you read Code Complete. It clocks in around 1000 pages and you probably don't have to read every single corner, but it would be for the best. Code Complete documents several best practices in coding based on internal reviews of large coding projects and publications. The point of the book is that your code will have fewer bugs and be easier to maintain. Priorities for coding go something like this: 1. make it work 2. optimize for maintenance (ie, make it easy to
read) 3. optimize for flexibility/speed (only if necessary!!!!) You should not be chasing complexity from one corner to the next; complexity should nearly always be pushed down and sequestered where it can't infect other code. Simple, readable code is the primary goal. Perhaps it was Knuth? who said programmers should enjoy reading code on the weekend. I couldn't disagree more! Good code should have the opposite qualities of a good book. Every single step along the way should be perfectly obvious as if no other way existed; plot twists in code are bad! Elegance is good, while cleverness tends to be bad. Working on existing code is much harder than writing new code. What hope do you have with maintenance if you write something at the limits of your comprehension? About 70-80% of the lifetime of any work on given code is actually in maintenance, not in writing it. Optimize for this. Documenting is not necessarily helpful, either. You should not document shit as being shit; instead, you should change the bad code! Other things are mentioned too, like function length, number of arguments to functions, variable span length, and variable pass through. Really, give it a read. |
thx