Easier for newbies to understand what you're talking about when you complete
the expression with the "efficiency": =IF(N(B2)=0,"",A2/B2)
Better still for newbies to rise above needing to be spoon fed. Still, I suppose
I should have spelled out that I meant this for the first argument to the IF
function.
Also, I question the value of "efficient" coding, particularly on small code
blocks. . . . It also has the negative effect of making the code more
difficult to understand/read when SOMEBODY ELSE has to take over! . . .
Agreed to a point. The advantage of N(B2)=0 compared to OR(B2="",B2=0) is that
if one really must guard against text that appears blank, either zero length
strings or arbitrary strings of ASCII and/or nonbreaking spaces, then what's
really needed is OR(TRIM(SUBSTITUTE(B2,CHAR(160),""))="",B2=0), and at that
point the claimed advantages of spelling out precisely what you're guarding
against would have become rather obscured in the mechanics of doing so. If you
believe that arbitrary strings of spaces aren't commonly used to 'blank' entry
cells, you lack real world experience writing models other people use.
. . . (Remember that year 2000 stuff? How many programmers suddenly were
doing overtime having to make corrections and trying to figure out where on
somebody else's code...man, I really felt for those COBOL dudes!) . . .
Not particularly relevant. The main problem with legacy code and Y2K was finding
the hard-coded 2 position references to years in date fields or stand-alone year
fields. Given the way COBOL variables must be declared, it was always pretty
straightforward to identify date and year variables and fields. What wasn't
always clear was how year was parsed from date fields, and the real work was
table conversion and the new/added logic to handle the converted tables.
By contrast, avoiding divide by zero errors (the central issue in this thread)is
a mainstay of numeric programming. Using N(B2)=0 as a test introduces only the N
function into the standard approach, and the use of the N function to trap text
as well as numbers could (and should) be part of the implementation
documentation for the workbook.
There's the real problem. Few take spreadsheets seriously as programming, so
there's seldom any implementation documentation. Well, if one's going to ignore
software engineering best practices, one needs to get bit in the butt enough
times to change one's mind. So, if there were documentation, use of N here would
be a nonissue.