I could write an endless amount of debugging code to handle the various components of input for a function, check that the correct data types are used, make sure things are decendants of the proper prototype objects, the data is within a certain value range or set... The list could go on and on. But also of course I can use documentation comment APIs to generate good documentation on the expected input and usage. My question is, how far/in-depth should I go as far as debugging/checking input for code users versus expecting them to read the funtion / method's documentation for proper use? We could say That's up to whoever's in charge but I'm interested in best  practice for maximum efficiency. 
Debug function input vs expecting code users to read the documentation - How far do I go?
design;architecture;documentation;error detection
Focusing on writing efficient code without actually defining efficiency is a common trap developers fall into.Efficiency isn't always reducing the number of CPU cycles required to accomplish a task.  In fact, for most programmers, in most cases, obsessing over shaving CPU cycles is a complete waste of time.Where Efficiency = minimizing CPU cyclesThe majority of business software contains trivial logic.  Imagine spending 30 minutes shaving a few CPU cycles off your code.  Let's just say you had a good day and shaved off a 2000 cycles.  Your typical 2GHz CPU will go through 2,000,000,000 cycles every second which means your 2000 cycles saved amount to 0.000001 seconds or 1 microsecond saved.Your application would need to run that optimized code 30,000,000 times before you break even on your time investment.In all my time in the business software world, I can't think of one instance where that initial 30 minute investment would have been paid off before I left that role for another job.Where Efficiency = time saved IN GENERALOn the other hand, if you define efficiency in terms of time saved in general then your ROI sky rockets.So, in this scenario, time saved includes (but is not limited to) the following:Your time testing your APIAPI Consumer's time debugging issues with your APIYour time debugging issues with your API ConsumerYour time handling calls about a brittle and broken API (no, the consumer didn't read your documentation)With this definition of efficiency, a little bit of defensive programming goes a long way.  Making your API fail early and fail hard on bad input data requires very little upfront time and saves you and your consumers' a boatload of downstream time.  The big thing to remember is that your time and your API consumer's time is much more valuable (read: expensive) than CPU time.Other domainsThere are however domains where efficiency can mean minimizing CPU cycles.  But, keep in mind that those domains are fewer and fewer nowadays.Two that come to mind are coding for realtime systems and high volume data analysis.TL;DRSo, unless you know for sure that you need to shave off CPU cycles, and better approach would be code in such a way that you save yourself and others as much time as possible.  In the API world you can accomplish this with clear code contracts and defensive programming.