This is closely related to the post on code formatting.
Code can be readable, but still not easily understood. Maybe it reads well but is misleading. Maybe you took the time to pick a good name for that variable, but the way it’s used and what it means has changed, but the name hasn’t. That’s [...]
From the department of redundancy department, IT coder division:
Duplication is probably the single, most important thing to banish from your code. Duplication can take several forms:
textual
This is the simplest and often the easiest to find. This is when you have sections of code that are identical or nearly so. This is often a result of [...]
Are you a fad-follower? Do you always use the latest new development environment simply because it’s this year’s model? Here’s my axiom:
Application architecture is less than optimum if it dogmatically conforms to a trendy framework at the cost of following good design/implementation practices.
For example, is it correct to be inflexible and use private fields and [...]
Code should be easy to read. Code should be convenient to read, not convenient to write.
There are several things involved here. Choosing good names that are self-explanatory is a good place to start. Strive for simple solutions, even if they are more verbose or inefficient. Whether inefficiency is a problem won’t be known until profiling [...]
OK, so you decide to add tests to your code. That typically isn’t so easy. The odds are that your code wasn’t designed and/or implemented to be easily testable. That means you will have to make changes to it to make it testable without breaking any of it (this is usually called refactoring these days). [...]
Read more...Does your code work? How do you know? Can you prove it?
If you don’t have tests for your code, it sucks. And I mean comprehensive, fine grained, programmer tests (aka something like unit tests), as well as higher level functional and integration tests. Tests that are automated. Tests that are run routinely. With the programmer [...]