A lot of things are more effective when you have someone else there to keep you accountable. I started paying closer attention to my finances when I opened up a joint checking account with my wife. I never miss a gym workout when I set-up a time to go with someone else. In that same spirit, you have a greater likelihood of doing the little things and writing good code when you sit down with a peer and review it. You might think a little longer about that !important declaration or class named .thingamajigs when your peers are combing through to make sure it makes sense and is free of errors that will plague your project.

One big focus on our team over the past year has been collaboration. A responsive workflow requires all sorts of disciplines and the closer we can integrate UI designers, front-end developers and UX, the better the end product will ultimately be. In the spirit of, "the sum is greater than its parts" here's no better way to think of solutions than to get an extra pair of eyes on it.

Avoid fixing the same bugs over and over again

On the front-end, with content management systems and templates, once a layout or component is created, its likely to be reproduced in other places. This reuse is important and finding code issues early will save a lot of time in the long run. Paul Irish helped author Roundarch Isobar's front-end code standards and best practices, where three pillars of front-end development are established:

Separation of presentation, content, and behavior. Markup should be well-formed, semantically correct and generally valid. JavaScript should progressively enhance the experience

What this does is lays a groundwork that allows you to focus your priorities. Its practical, for instance, writing generally valid code but not stringently enforcing W3C validation (which is a great tool, but I don't know anyone who obsesses over it anymore). The point is to have code that works and that others can understand. With that, other things start to fall into place, like performance and maintainability.

People take shortcuts; it is important to be efficient with your time, and equally important to build something maintainable and cohesive. A code review is a great gut-check to make sure your code is semantic and fundamentally sound.

Fundamentals

Getting back to basics is one of the easiest things to do when reviewing others' code. It's like practicing for a sport, you hammer home the foundational skills so you don't even have to think about them and can focus on other areas of your game.

In Shay Howe's Guide to HTML & CSS he spends some time breaking down simple best practices to ensure you are writing good code. Here are some highlights and how to apply them to your peer reviews.

HTML:

Write standards compliant markup If you are a fan of Sublime Text, SublimeLinter is great for catching errors (HTML, CSS, javascript and a lot of other languages).

Make use of semantic elements Check to make sure elements used are the right ones, for example don't use two <br/> tags when you should have a <p> tag in there.

Separate content from style Inline styles are really for HTML emails and WYSIWYG editors only, and both of those are out of necessity.

Avoid a case of div-itis Look for areas where less code can be used. This is especially a challenge when working with CMS's, but there are always options to cut down on superfluous markup.



CSS:

Organize code with comments This will help the next person who looks at your CSS and for your future self down the line.

Indent selectors Better readibility when editing your code.

Write CSS with multi-line spacing Really a preference here, just make sure a consistent pattern is used.

Modularize styles for reuse SMACSS - SMACSS is great conceptually, even if you don't fully subscribe to the exact structure explained by Jonathan Snook, the philosophy is useful.

Use shorthand properties when available TRBL (Top, right, bottom, left). Cuts down on style properties, easier to maintain.



Continually Refactor Code

Over time websites continue to grow and grow, leaving behind quite a bit of cruft. Remember to remove old code and styles as necessary when editing a page. Also take the time to evaluate code after you write it, looking for ways to condense and make it more manageable.

Shay does an awesome job of giving you a great foundation for writing good front-end code. One problem is, don't always have the option to continually refactor your projects. Some are on short timelines, others are constantly adding features and you don't have time to breath. But if you do a little bit everyday, you will be in much better shape.

Check your browser support before you get too far down the road

I've always subscribed to the support the current version and its previous release school of thought. With Internet Explorer, that's not always possible. Google recently dropped support for IE9 in Google Apps, which is an encouraging sign. Sometimes, depending on your audience or your project's goals, spending days debugging IE isn't important enough to allocate time against it. Other times, it's mission critical. It's important to have a clear dialogue about this before digging in.

Ask questions

Here are some things to consider when doing a front-end code review.

DRY (Don't repeat yourself), see if you can find spots that are repeated and look for ways to simplify.

Look at the project holistically, does it seem slow? Take a look at Google's Web Performance Best Practices.

It's easy to get defensive when you are in the trenches and an outsider comes in and gives advice. It's important to get constructive criticism so you can battle test your work.

Tweet