When reviewing code, everyone picks on different things. This is a good thing, provided that code reviewers move around frequently and everyone gets to benefit from the resulting sharing of knowledge.

Here's a bunch of anti-patterns that have bitten teams and companies that I've worked with in the past, and some ways to avoid them. This is by no means a complete list; it's simply the ones that keep jumping out at me and, more so, the ones that tend to cause pain later rather than sooner with a corresponding degree of compound interest on the original technical debt.

Always picking the same code reviewer.

Asking the guy next to you for a code review is great; just don't do it all the time. That one guy next to you will always pick on the same things, and will likely miss (or simply not value) other points that another reviewer might pick up.

The guy next to you is also probably going to become familiar with the code you're working on. Again, this is often a good thing but it also means that your code, while obvious to you and your favourite reviewer, might become impenetrable to others without your realising it.

Additional "using" Statements

"Using" statements, especially when highlighted by your favourite diff tool, are a good (and simple) indicator of increased class coupling. This isn't always a bad thing, but should always be studied rather than glossed over.

This should also be your cue to check whether the new code has dependencies on concrete classes in the newly-used namespace, or whether someone's been clever and has coded to an interface.

using System;
using System.Text;
using My.Useful.Namespace;
using My.Specific.Namespace.That.I.Shouldnt.Know.About; // one of these things is not like the other...

Pointless Safe Casts

This is a complete pet hate of mine, as many times I've spent ages tracking down some random NullReferenceException or Debug.Assert( ... != null) failure because someone's used a safe cast and then blithely assumed that the result will be non-null.

// BAD!! This is a NullReferenceException waiting to happen!
ISpecificThingy specificThingy = thingy as ISpecificThingy;
specificThingy.DoSomething();

// GOOD. This will (correctly) throw an InvalidCastException at the point of the error, rather
// than allowing a null value to propagate along the code path and trip someone up later.
ISpecificThingy specificThingy = (ISpecificThingy)thingy;
specificThingy.DoSomething();

Non-thread-safe Collection Modification

This probably won't bite you, but it will bite someone else who has to come along three months later and figure out why there's some random, non-deterministic explosion. That person, however, will probably kick you, so it all balances out in the end.

// BAD! This is not thread-safe, and is an ArgumentException (item with same key...) waiting to happen.
public void Remember(string k, string v)
{
if (!_strings.ContainsKey(k))
{
_strings[k] = v;
}
}

// BETTER. This is thread-safe and won't explode. What's missing, though?
public void Remember(string k, string v)
{
if (!_strings.ContainsKey(k))
{
lock (_strings)
{
if (!_strings.ContainsKey(k))
{
_strings[k] = v;
}
}
}
}

// GOOD
public void Remember(string k, string v)
{
#region Argument Checking

// ... actually check arguments, here :)

#endregion

if (!_strings.ContainsKey(k))
{
lock (_strings) // careful, though - when locking on arbitrary objects, it's easy to create deadlocks.
{
if (!_strings.ContainsKey(k))
{
_strings[k] = v;
}
}
}
}

Catching NullReferenceExceptions

It's just bad. Please don't do it - and never let your name be associated with a review of code that does.

try
{
myFoo.Bar.OtherProperty.DoSomething();
}
catch(NullReferenceException)
{
// Hi. I'm so utterly lazy that I can't be bothered to null-check things, *or* to
// de-couple my classes so that I don't *have* to null-check so many things.
//
// Please beat me around the head with a stick.
}

Mapping Symbol Names to Strings

// BAD!
string fooTypeName = foo.GetType().FullName;
if (fooTypeName.Contains("Widget"))
{
// we have a widget!
widgets.Add(foo);
}

// BETTER
WidgetBase widget = foo as WidgetBase;
if (widget != null)
{
widgets.Add(widget);
}

// GOOD
IWidget widget = foo as IWidget;
if (widget != null)
{
widgets.Add(widget);
}
This is easy to avoid in the example above, but less easy to avoid when messing with types and type names without having an instance to safe-cast. Use Type.GetType("your_class_name") and .IsSubClassOf() instead.
Not an issue in C#? Fine, then. Wait until you have to inter-operate with JavaScript, and then see how you go about retro-fitting subtype checks to your entire codebase :)