How do you proactively guard against errors of omission?

Question

I'll preface this with I don't know if anyone else who's been programming as long as I have actually has this problem, but at the very least, the answer might help someone with less xp.

I just stared at this code for 5 minutes, thinking I was losing my mind that it didn't work:

    var usedNames = new HashSet<string>();
    Func<string, string> l = (s) =>
        {
            for (int i = 0; ; i++)
            {
                var next = (s + i).TrimEnd('0');
                if (!usedNames.Contains(next))
                {
                    return next;
                }
            }
        };

Finally I noticed I forgot to add the used name to the hash set.

Similarly, I've spent minutes upon minutes over omitting context.SaveChanges().

I think I get so distracted by the details that I'm thinking about that some really small details become invisible to me - it's almost at the level of mental block.

Are there tactics to prevent this?

update: a side effect of asking this was fixing the error it would have for i > 9 (Thanks!)

    var usedNames = new HashSet<string>();
    Func<string, string> name = (s) =>
        {
            string result = s;
            if(usedNames.Contains(s))
                for (int i = 1; ; result = s + i++)
                    if (!usedNames.Contains(result))
                        break;
            usedNames.Add(result);
            return result;
        };

Answer 1

A unit test likely would've / should've caught this omission.

Assert.AreEqual("NEXT", obj.GetNextName("NEXT"));
Assert.AreEqual("NEXT1", obj.GetNextName("NEXT"));

It would also catch the likely bug you'll have when i = 10.

...
Assert.AreEqual("NEXT9", obj.GetNextName("NEXT"));
/* your TrimEnd call could be a bug */
Assert.AreEqual("NEXT10", obj.GetNextName("NEXT"));  

Test-driven development is proactive by its definition. In your example, you would immediately see that it wasn't working as designed and you would get feedback as to what it was returning.

Answer 2

You could ask someone else to look over your code.

Answer 3

Experience is the best defense here.
Over time, you should become more adept at spotting these omissions from the observed behavior.
(You should also become more adept at not making them in the first place)

Stepping through the code line-by-line in the debugger should also highlight what's missing.

Answer 4

I personally find it helpful to describe my methods in comments before writing the implementation code. That way, if I forget something, or if someone else picks it up in two weeks time, they will know what was 'supposed' to happen and should be able to implement it themselves without needing to some and ask me!

E.g

MyMethod() {
    //setup vars

    //perform complex function

    //set flag for something or other

    //save changes
}

It won't prevent the 'I've made an error in the algorithm' type issues, unless you really go low level with the commenting, but it should prevent the 'forgotten to save changes' type errors.