I’ve seen a wide and impressive variety of inventive user entries. N(..) and TRIM(..) functions are much underused when it comes to addressing such inventiveness.

I screwed up my ISERROR point. I meant to add that using ISERROR to trap expected conditions such as no values to average often leads to ignoring more serious errors. For example,

=IF(ISERROR(AVERAGE(SomeRange)),”",AVERAGE(SomeRange))

traps no numbers in SomeRange, but it also traps error values in SomeRange as well as trapping corruption (#REF!) or deletion (#NAME?) of SomeRange or even, if SomeRange is defined as an intersection, #NULL!. ISERROR usually traps too much, and it certainly hides bugs early on and lets them grow into real monsters.

N(..). Hmm, let’s see. I’m involved in maintaining a model which has over 405,000 formulas across 114 worksheets. use of N() – zero. Plenty of A1>0 and A1=”" though.

Thanks God someone who agree’s with me. Data Validation in Excel sucks! Thank you Harlan.

There are still too many instances of mixed user entry and formula results in the same worksheet, but the main thing I haven’t seen is SheetChange event handlers trapping and undoing cut and paste operations and displaying warnings about why it’s bad and why it’s not allowed. Of course it’d be much, Much, MUCH better for MSFT to provide a protection setting that converted cut and paste operations into copy and paste: this could be done with a SheetChange event handler, recording the post-paste values or formulas in the destination range (and maybe also the formatting), undoing the paste operation and setting CutCopyMode to False, then replacing the stored post-paste values or formulas in the destination range. Excel should provide a protection mode to do this automatically.

There are also too many spreadsheets that rely on Excel’s laughably weak Data Validation functionality. Data validation doesn’t process pasted values, which means it’s unreliable in a multitasking environment such as any version of Windows since Windows 1.x. SheetChange and SheetCalculate and/or validation formulas in ancillary cells or as defined names are necessary for robust data validation. Some models I’ve seen do use macro-driven final validation, fewer use robust interactive validation.

Finally, there’s overuse of ISERROR. The proper way to test that a cell contains a positive value isn’t X99>0 because that’s true if the nice user enters an apostrophe or a space char (or any other string) in X99 (unless you want beg for trouble by using 123 transition formula evaluation), it’s N(X99)>0. How many times do the rest of you see N(..) being used in production spreadsheets?

I don’t know about the rest of you, but in my experience cut and paste, ineffective user entry validation and failing to allow for Excel’s, er, ability to make order comparisons between values of different types have been responsible for about as many runtime errors as off-by-one indexing and incorrect references in formulas. But I haven’t seen much effort to control for these potential problems.