ScottPletcher (3/1/2013)

---

Jeff Moden (3/1/2013)

---

Eugene Elutin (2/28/2013)

---

This cut down number of CPU cycles when performing multiplication as it takes less number of bit-moves for multiplying smaller numbers - I should accept that it's hard to measure with existing technology :hehe: (plus it doesn't use some strange number of 22800):

selectdateadd(month, (@YearParam - 1900)*12 + @MonthParam- 1, 0) AS BOM

selectdateadd(month, (@YearParam - 1900)*12 + @MonthParam, -1) AS EOM

I guess I'll have to retest on that. In multiple different threads, Michael and Peter showed that controlling the order of execution within the formula with parenthesis performed worse but that was a long time ago and could stand a revisit.

None the less, even if it were a tiny bit slower, it's a much better "readability" solution than using character based conversions to do the same thing (which is what my main point was) if someone really wanted to make that small trade off. I typically won't make that trade off. I'll include a comment for clarity, instead.

That code is much better since it's inherently understandable.

Yes, you can comment the "magic number" code, but it would take developers a considerable amount of time to wade thru the comments before they could begin addressing the real code issue that caused them to look at the code in the first place.

With mutliple hundreds of developers where I've been at, they simply won't all be excellent. It just won't happen. So unless data volumes are massive, or genuinely may become massive, or the performance difference is truly significant, more straightforward code works vastly better overall.

The major exception is triggers: triggers are always coded as efficiently as possible, period; use comments as needed to clarify the code. Since trigger coding is limited to only DBAs or, when absolutely necessary, top developers, this is not an issue anyway.