How easy would it be for me to fix a bug in this code?

Whenever I encounter a new code base I ask myself that question.

Quickly familiarising myself with the code enables me to identify common ground with the developer(s) who created it. I tend to look for the following (in no particular order):

• consistent use of naming conventions
• an aversion to making code complex – adhering to the KISS principle
• unit tests that work out of the box
• a short readme file that describes the project with helpful hints to understanding
• good comments
• use of design patterns where appropriate
• consistent style in comments and code layout
• use of well-known and respected supporting libraries (e.g. Boost, Guava etc)
• presence of language idioms

The more of the above are present then the more confidence I have in the skills and experience of the developers so that when the inevitable WTF?! moment occurs I am much more inclined to look to myself for a lack of understanding of the problem domain than assume that the original developer has made an error.

If you make only one pick, you’re likely doing it wrong. 🙂 Other than that this is essentially a random sampling, a pretty respectable approach to gather information in cases like you describe. For more scientific details on how this could be done, study about Monte Carlo method.

Regarding things to look for, consider finding, studying and tailoring to your specific needs some tried and true code-review checklist.

Some other aspects worth considering when evaluating a project are listed below (check list summarized from my past experience):

• Releases (along with changelog), versioning and publishing discipline
  It’s generally much easier to investigate issues when one can tell bug was found in release 1.2.3, avaiable for download at some URL than oh two years ago someone sent me a mail with attached binary.

• Developer documentation, API reference and code examples
  Helps to avoid efforts wasted on reinventing the wheel and learning basics by trial and error.
  Note these can be also randomly sampled for a quick study.

• Bug tracking
  If there’s no tracking at all, it’s a huge red flag; if there’s one, consider quickly checking it using the same random sampling approach as you do for source code

• Positive feedback
  Find out about project users and try to do a random sampling study of their feedback.

I think this method rather reveals styling skills and the ability of making code readable, but it tells nothing about logical, analytical, problem-solving skills of the developer(s) working on the code.

So when you analyse code this way, you gain information only about how “good” the code looks and whether it is readable or not. But still you have no idea if the code is optimized, if it works well, if it well structured, etc.

The characteristics you pay attention on are very important. They show if the code is readable and maintainable. But there are many programmers who give excellent solutions but don’t really pay attention to comments and styling (which I thinks is much easier to learn than programming itself).

Yes, I think that it’s a good idea. Projects which are poorly written is more likely to get abandoned.

But don’t base your decision just on that. imho source code history and number of committers are a far more important factor.

I think looking at small sections of code is a great way – if it is coded well, variables/classes/methods are named well and it is commented well, then understanding what a small section does and what its purpose is should be easy. If you have great difficulty understanding a small block (like anything brace-to-brace), then it is probably not coded all that well.

unless the samples are many and large, there’s a very good chance you’ll not going to get a good cross section of the codebase. You could end up with either the few good pieces or the few bad apples quite easily.