People default to documentation as the best way to write clear code but documentation is a no win task. It's never kept up to date, it's never clear enough and

People default to documentation as the best way to write clear code but documentation is a no win task. It's never kept up to date, it's never clear enough and of course it's time consuming. I favor the building house approach. Generally, describe what you want to accomplish in a simple language outline. Create a blueprint in the same idea as a house builder would get to build a house and write code that self documents. 1) Descriptive names for whatever you need to name. Long names are ok. 2) No monolithic code. Break it up. 3) Choose clarity over brevity 4) No magic numbers, don't use hacks 5) No cute coding, coders want to show how smart they are by writing code that does a lot within a few lines. It might be fun for the coder but it's useless for long term production code. 6) Code as if a newbie will read your code. Rework if you need to speed up the code. 7) Always code as if you expect someone else will read your code. This will keep you from doing quick "temp" changes that will never get fixed. 8) Follow an established coding style. Don't reinvent the wheel 9) Sometimes there is no choice; use in-code comments as needed but don't over use them since you will need to update them later. Most of all, talk to your other code partners and decide the best style that works for the group. Don't be a one man coding machine. Work with your team. It might seem like you are doing a lot of work for some one else's benefit but I guarantee that you are not. Something that happens a lot is that you'll need to rework your code a few months later and you will have no clue what you did. Writing clear code will help you immensely as you try to figure out what you did and what you need to do to fix the problems.