Similar questions have been answered before. See http://stackoverflow.com/questions/550861/improving-code-readability for example.
Readable code is code that clearly communicates its intention to the reader. Code that is not readable takes longer to understand and increases the likelihood of defects.
Some things that increase readability:
- Use whitespace to separate disparate areas of code. For example, indent code blocks like "if" statements. Leave blank lines between methods/functions or related lines of code within a method/function. This allows the brain to segregate the code even before the characters are read.
- Use meaningful variable and method/function/class names. Follow the standard practice for the language and use terms from the problem domain if possible. The meaning and use of something should be evident from its name. Names should also be consistent (GetX(), GetY() and GetZ() rather than get_X(), LoadYFromDatabase() and getVar(Fields.Z));
- Comment effectively. Avoid obvious comments ("The GetX() method returns the current value of x"). Comments should say what the code intends to do, how it relates to other parts of the code and any assumptions ("Argument "a" cannot be null. The code throws an exception if a is null").
- Following established design patterns for the language, library or problem space. For example, avoid repeating code (called DRY or Don't Repeat Yourself). This wastes time as the reader tries to look for differences or find the correct piece of code to fix.
- Keep it Simple (KISS principle). For example, avoid premature or unnecessary optimization. Optimization has its place but code can often be optimized without impacting readability.
Arguably the single most important aspect is consistency. It is easier to understand code if the reader knows what to expect and where to look. If the project uses conflicting variable naming and commenting styles, for example, the reader has to waste mental effort learning new styles and context switching.
The code's author may be a poor judge of readability since they may be invested in the code or be too deep in the problem to take a step back and look at it through others' eyes. Code reviews help here.
Remember that not all code is going to be readable all the time. Developers often have to write code in a hurry when they are tired using unfamiliar libraries. Poor readability should be treated like technical debt and refactored.