How do I review my own code?

Take a look into the Code Review Stack Exchange site. It is for sharing code from projects you are working on for peer review:

Code Review - Stack Exchange is for sharing code from projects you are working on for peer review. If you are looking for feedback on a specific working piece of code from your project in the following areas…

• Best practices and design pattern usage
• Security issues
• Performance
• Correctness in unanticipated cases

You can also use code static analysis tools to detect certain kind of problems, but they are going to produce false alarms in some cases, and can not suggest how to improve the design.

I agree whit jk-s opinion that single-person review is not as efficient as 2 person review. however you can try to make the best of it:

short term review (shortly after the code was produced)

I am using git as a local repository. Whenever I have finished a feature or fixed a bug I transfer the changes to the repository.

Before i check in I compare what I have changed in my code and rethink:

• do variable/method/classnames still reflect what they are used for?

long term review (6 months after the code was produced)

I ask myself:

• can I describe in one sentense what a class/method/variable does?
• how easy is it to use a class in isolation (whitout the other classes) or write a unittest for?

I've developed several totally different persons in my head. One of them is not even a programmer! We're chatting, discussing latest news and reviewing each other's code.

I strongly recommend my approach.

ps He is not kidding.

First, set your code aside for as long as practical. Work on something else, some other piece of code. Even after a day, you will be amazed at what you will find.

Second, document your code. Many programmers hate to document their code, but make yourself sit down and write out documentation, how to use the code and how it works. By looking at your code in a different way, you will find mistakes.

It has been said that true mastery of a subject is the ability to teach it to someone else. With documentation you are trying to tech someone else your code.

In addition to the useful tools mentioned in other answers, I think modifying your mindset it useful when doing a code review. It's silly, but I say to myself: "I'm putting on my code review hat". I do the same with QA.

Then it's important to limit yourself to that mindset. You're either the reviewer or the reviewee, you can't be both at once. So as a reviewer, I take objective notes to share with the reviewee. I don't change the code while I'm reviewing it, that's not something a reviewer should do.

The formality feels a little absurd at times, but I find when working solo that I'm often pulled in a lot of directions. So I may not necessarily close the review loop before something else comes up - that formality (and really, I'm talking rough notes in a wiki tool), is useful for making sure the review gets done. Likewise with my QA hat on, I add tickets for bugs before I fix them.

Transform this debugging technique to a code review technique: http://en.wikipedia.org/wiki/Rubber_duck_debugging

The concept works wonders for putting you into a proper mindset for working through code as if it were new.

The Personal Software Process technique for reviews might be useful, although it relies on having historical data about your work and quality of products.

You start with historical data about your work products, specifically the number and types of defects. There are various methods of classifying defects, such as this one from a PSP course. You can develop your own, but the idea is that you need to be able to tell what mistakes you are making along the way.

Once you know what mistakes you are making, you can develop a checklist that you can use during a review. This checklist would cover the top mistakes that you are making that you think can best be caught in a review (as opposed to using some other tool). Every time you review a work product, use the checklist and look for those mistakes or errors, document them, and fix them. Periodically revise this checklist from time to time to make sure you are focusing on real, relevant problems in your code.

I would also recommend using tool support when it makes sense. Static analysis tools can help find some defects, and some even support style checking to enforce consistency and good code style. Using an IDE with code completion and syntax highlighting can also help you prevent or detect some problems before you click "build". Unit tests can cover logic problems. And if your project is sufficiently large or complex, continuous integration can combine all of these into a regularly-run process and produce nice reports for you.

Working solo means that unless you trust complete strangers to review code on your behalf, that you will need to look at the way you write your software in order to maintain code quality.

First and foremost, you should have a means to ensure that your code is matching requirements, and second that your code will be relatively easy to change if you decide later that you got something wrong. My suggestion would be to apply a Behaviour Driven Development approach for the following reasons:

1. BDD means writing code test first. This ensures all of your code is covered by tests.
2. BDD is essentially TDD, but with a slightly different focus and "language". What this implies is that you continuously refactor your code as you are working on it, and use your tests to ensure your refactoring efforts continue to ensure that your code satisfies your product spec.
3. BDD language encourages tests to be written in the form of statements that essentially encode requirements as unit tests.

So the idea here, is that your continuous refactoring of code even after you get your tests to pass, means that you are effectively reviewing your own code and using your unit tests as the "extra pair of eyes" which make sure your code doesn't stray from the requirements that are encoded in the tests. Also, high test coverage based around requirements ensures you will be able to change your code in the future without failing the requirements.

The real issue for you will be whether or not you're able to spot potential issues in your code that will indicate a need to refactor. There are several profiling tools on the market that can help you with this, as well as several other tools which are concerned with code quality metrics. These can often tell you many things that code reviews can miss, and are a must when developing projects on your own. In reality however, experience is the key, and once you are in the habit of being merciless in your refactoring, you will likely become much more critical of your own code. If you haven't already, I'd suggest reading Martin Fowler's Refactoring book as a starting point, and looking for a good BDD API that you feel will work for you in whichever language you have chosen to work with.

It seems the common sentiment is that self-review is not effective. I disagree, and I think self-review can catch a lot of issues if done thoroughly.

Here are tips from my few years of experience:

• Have a rough checklist handy. These are things you want to flag while you read your code.
• Take your code review offline. It might sound wasteful, but take printouts that you can annotate and flip back-and-forth, or the digital equivalent of nicely highlighted pdfs synced to an iPad which is then taken offline. Go away from your desk, so that all you do is review your code distraction-free.
• Do it early in the morning, rather than the end of a working day. Fresh pair of eyes is better. In fact, it might help to have been away from the code a day before reviewing it afresh.

Just an FYI - these guidelines were part of recommendations in Oracle a few years ago when I was working there, where the aim was to catch bugs "upstream" before the code went into testing. It helped a lot, although it was considered boring job by a lot of developers.

I can't tell you the number of times I have been explaining something to a code reviewer and the lightbulb in my head turns on and says, "Hey wait a minute." So I often find my own mistakes in the code review that the other person didn't see. So you could try that, just start explaining the code as if there was a person sitting next to you who was trying to understand what you did and why.

Another thing that I find frequently in code reviews is that the developer did not actually follow the requirement. So comparing your code and what it does the the actual requirement is a good check.

We frequently do things like SSIS packages that have similar structural needs - for code reviews I developed a checklist of things to check (is the configuration correct, is logging set up, does it use the metadata database, are the files in the standard location, etc.). You might have some things that would be handy to check every time in a code review as well. Sit down and think about what you would put on a checklist of things you want to make sure to check in your code review (First item, make sure the requirement is met, next item might have something to do with trapping and logging errors). As you make mistakes and correct them, you may add other items to the list (say something like, do I move to the next record in a loop or am I going to endlessly repeat the same first item - it only take one endless loop to teach you to look for that!). This is mostly to keep you from forgetting to do some things that should be done.

Give it 3 months, then go back and look at your code. I promise you, if you can't find something wrong with it (or question who wrote this junk!) you are a better man than I!

I usually print out all my code and sit down in a quiet environment and read through it, I find a lot of typos, issues, things to refactor, cleanup by doing that. It's a good self-check that I think everyone should do.

Whenever I've been in the same situation as yourself, I've tried to solve the problem of "being too close to the code to objectively examine it" by using code review / metric tools. It goes without saying that a tool cannot give the same value as an experienced reviewer, but you can still use them to pinpoint areas of bad design.

One tool that I've found fairly useful in this regard was SourceMonitor. It's a bit simplistic, but it gives a good mid-level opinion of your code, such as the number of methods in a class, and the complexity of each method. I've always felt that this type of information was as important (if not more important than) the enforcement of coding styles via tools like StyleCop, etc (which are important, but are often not the source of the largest problems). Use these tools with the usual disclaimers: know when to break a rule of thumb, and something that is all green in a code metric tool isn't automatically of good quality.

Most of the people tend to consider their code as their own babies and feed them with ego to rather than reality. Just like any other code reviews, review it as you're seeing someone else's code. Completely forget that you've wrote something. Review each line of the code. A check list would helpful for being aesthetics about reviewing own code. Automated tools for code review can help to some extend. I have used some tools like klocwork (commercial software), This is quite useful while you're working in large projects and several developers are working for it. Always focus on defect detection rather than correction.

But a best practice would be, review yourself and later involve at least two other people for review with distinguished roles.

Consider doing a Fagan inspection by yourself - you'll have to adapt the process because you're by yourself, but you should be able to get quite a bit of value out of it. The trick is going to be to find the right "ruleset" to evaluate your code against as a solo dev, and then having the discipline to ask those questions in a critical, analytical, merciless frame of mind each time. I suspect you may want to brainstorm your own 4-5 crucial questions to start with, and then evolving it over time. Some people are against formal inspections because they seem to be so time-intensive... before you decide that they're too expensive, bear in mind all the statistical evidence that doing inspections properly actually reduce project time. Here's a Wikipedia link that you can start further research with:

http://en.wikipedia.org/wiki/Software_inspection

There have been a few books too, e.g. Google for "Software Inspection Process" by Strauss and Ebenau.

Another option is to pay someone to inspect an important project - or perhaps pay them occasionally to do inspections of all your code. This guy's pretty good, we've flown him out a number of times to train our newer devs:

http://www.javaspecialists.eu/

Back in college I was a writing tutor. It has certainly given me some perspectives on coding that I think many developers would never have thought of. One of the most important is to read your code aloud. It doesn't sound like much, but I will give a perfect example that I think everyone can relate to.

Have you ever written an email or a paper, reread multiple times to make sure its correct, then sent it, only to find that you have a glaring spelling error, typo or grammatical error? I just did this yesterday when I asked a client to press the shit key instead of the shift key. When you read in your head - you see what you want to see.

This is a shortcut for the 'just wait a day or a week or a month' suggestions others have made. If you read it aloud you catch the same things. I don't know why it is so effective, but after sitting with hundreds of students and having them read aloud, all I can say is that it works.

Apart from all the recommendations for code review, you can use the tools like PMD and findBug to do first level of sanity for your code.