The biggest clue for me 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

The code quality test: Have another programmer who has never seen the code read it an explain what each module does to you while you look over their shoulder. The stronger your urge to jump in and explain something the worse the code likely is. If you can calmly sit there with your mouth shut and they don’t need to ask a lot of questions, you are probably good.

For your benefit, here are some general guidelines for when you don’t have a peer handy. They are not absolutes, just “smells”.

Good signs

  • Methods tend to be very short that ideally perform a single task.
  • You have enough information to call methods WITHOUT looking at the body of them.
  • Unit tests are easy to write.

Bad signs

  • Long methods made up of 2-3 sub-tasks that are not broken out into other methods.
  • Methods share data through some means other than their interface.
  • If you change the implementation of one method (but not the interface) you need to change the implementation of other methods.
  • Lots of comments, especially long winded comments.
  • You have code that never runs in your application to provide “future flexibility”
  • Large try/catch blocks
  • You are having a hard time coming up with good method names or they contain the words “OR” and “AND” (e.g. GetInvoiceOrCustomer)
  • Identical or nearly identical blocks of code.

Here is a longer list of code smells that should also be helpful.

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

I have three golden rules:

  1. If I feel compelled to copy/paste blocks of code I’m doing something wrong
  2. If I can’t take the whole code in my head I’m doing something wrong
  3. If someone jumps in and gets lost in my code I’m doing something wrong

Those rules has guided me to do some real architectural improvements, ending up with small, clean and maintainable classes/methods.

Now, how do you know when you’re writing good code?

  • When your classes each serve a single, very clearly defined purpose, separated from other classes with other clearly defined purposes.
  • When your methods are short – ideally under 50 lines and certainly under 100 – and their names clearly define what they do exactly. A method should not do anything but what it’s name implies. If you’re going over 100 lines, or tabbed in very far, you can probably pull something out into it’s own function.
  • When your code provides one way to do something – when it does not provide the option to zig or zag, but instead provides a single linear path for each possible course of action the user may send it down.
  • When you’ve done everything you reasonably can to reduce coupling between classes; so that if Class A depends on Class B, and Class B is removed and Class C is put in it’s place, little to no changes have to be made to Class A. Class A should be as blind as possible to what’s going on in the outside world.
  • When your class, method, and variable names can be read and immediately understood by anyone that comes across the code – there’s no need for ‘pktSize’ when ‘packetSize’ reads much more easliy.

As others have said, essentially, if you’re doing Object-Oriented Programming, and when the time comes to change something you find it like trying to untangle and rewind a ball of yarn, the code isn’t following good Object-Oriented principles.

I highly recommend the book “Clean Code”, if you’re interested in digging a little further into this. It’s a good read for novices and experts alike.

This has been my experience since shifting from the college world of programming to the industry over the last five months:

  • Ease of use is so important that we pay people just to design user Interfaces. Coders often suck at UI design.
  • You find that that getting it to work isn’t enough
  • Optimizations become more critical in real-world scenarios.
  • There are a thousand ways to approach a problem. However, often times the approach does not account for slightly less well-known factors that could adversely affect the performance of your approach such as database authentication, transactions, file I/O, reflection, just to name a random few.
  • Maintainability is a very important aspect of coding. Just because your code is super optimized and super dense … doesn’t mean that it is sexy. Sometimes it is simply labeled as “Hero coding”.
  • Design skills are learned, not inherent. I’m sure there are a few brain children out there, but generally speaking, solid design with respect to real-world problems, is wrought through time, investigation, and most importantly, the imparting of knowledge from your superiors =P
  • Documentation is not an convenience, it is a necessity.
  • The same thing goes for unit testing (this varies from company to company admittedly)

I would suggest that you take an opportunity with an open source project. You will get a chance to see how much you really know if you work along side other programmers bottom line. An open source project is probably the best way to find out based on your background.


‘d say my main points would be:

  • Readability (for you and anyone else who has look 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, never copy & paste a block of code)

I’m not putting Design in this list as I believe a good code can be written without sticking to a design pattern as long as it’s consistent within your project.

Good MSDN article on this topic: What Makes Good Code Good?