How do you know you're writing good code?
The biggest clue is when you have to go back and add/modify a feature, is it difficult? Do you constantly break existing functionality when making changes?
If the answer to the above is "yes" then you probably have a poor overall design.
It is (for me at least) a bit difficult to judge a design until it is required to respond to change (within reason of course; some code is just bad and you can tell right away, but even that comes with experience.)
You know you are writing good code when:
- Things are clever, but not too clever
- Algorithms are optimal, both in speed as well as in readability
- Classes, variables, and functions are well-named and make sense without having to think too much
- You come back to it after a weekend off, and you can jump straight in
- Things that will be reused are reusable
- Unit tests are easy to write
For me personally, I think it's when I forget about the code. In other words:
- Bugs rarely occur
- When they do occur, other people resolve them without asking me anything
- Even more important, no one ever asks me anything regarding my code
- People don't have a high rate of WTF/min when reading it
- A lot of new classes in the system start to use my class (high fan-in, as Steve McConnell would call it)
- The code is easy to modify and/or refactor when/if needed, without cursing me (even if it's me - cursing myself!)
- I also love it when I guess just the right amount of abstraction which seems to suit everyone on the team
It's a nice feeling when you open a file you've written a year ago and see all the nice additions to a class, but very few modifications, and - very high fan-in! :)
Of course, these are the things that make me feel like I'm writing good code, but in reality, it's really hard to know. My guess is, if people start making fun of your code more than they're making fun of you, it's time to worry.
I have three golden rules:
- If I feel compelled to copy/paste blocks of code I'm doing something wrong
- If I can't take the whole code in my head I'm doing something wrong
- If someone jumps in and gets lost in my code I'm doing something wrong
Those rules have guided me to do some real architectural improvements, ending up with small, clean, and maintainable classes/methods.
I'd say my main points would be:
- Readability (for you and anyone else who has looked into your code)
- Maintainability (easy to modify)
- Simplicity (not complicating things when there's no need for that)
- Efficiency (of course your code should execute fast)
- Clarity (if your code is self-explanatory, there's no need for comments most of the time, name your methods/properties, etc. sensibly, break the long code down, and never copy & paste a block of code)
I'm not putting Design on this list as I believe good code can be written without sticking to a design pattern as long as it's consistent with your project.
Good MSDN article on this topic: What Makes Good Code Good?
Good Reference : Code Smells