If I'm building private utility functions, should they be held to the same rigorous standards in terms of handling invalid data as public functions?  Example:If I'm writing code to calculate the length of a linked list, and the list being passed is one created by my own code, should it be checked for loops if my code does not create linked lists with loops in the 1st place?
Should private functions be held to the same standards as public functions?
interfaces;functions;encapsulation
Naturally, private methods have just as much to gain as public methods do, from checking to make sure that every single bit of their input is correct. Generally, no programmer would ever be asking themselves the question of whether more checks are better than fewer checks, (duh!) if it was not for performance concerns. Now, when it comes to checking for invalid stuff there are two types of checks that you can perform:Production-time checks, (in short, runtime checks) which happen both on development and on production environments. (Out there on the field.)Development-time-only assertions, (in short, assertions) which happen only in development environments and are skipped on production environments.Assertions have the mind-bogglingly useful characteristic of not incurring any performance penalty on production environments, so they can be used very liberally.  Go ahead and assert everything you can, it does not affect performance. On the contrary, asserting everything is good for robustness, it is good for debugging, it is good for documentation, it is good for keeping the state complexity of your program down; in short, it is the best thing since sliced bread.  So:The question you should always be askingis not should I assert this?but is there anything I forgot to assert?So, in a well designed system, both private methods and public methods check everything there is to check, the only difference being the following:All (well, almost all) of the checks performed by private methods are assertions.Many of the checks performed by public methods are runtime checks, (not assertions,) if the public interface of the object demands so. Generally, these checks are for things that may conceivably happen under normal usage and they are not necessarily bugs.For example, if you are coding a File class, then a failure to open the file is generally not a bug, so it should be checked against and generate an exception even on production. On the other hand, if someone passes your public file-open method a null filename, that is a bug in the caller's code, so the check for a null filename can be an assertion.And generally, every single thing which gets checked with a runtime check in a public method can also be checked again in a private method, but this time with an assertion, since all input ought to have already been validated by the public methods, so anything bad reaching a private method means you have a bug in your code.So, in general:Nothing should ever go unchecked, either in public or in private methods.Assertions are free, so use them liberally.DISCLAIMER: Since this is an interview question, please bear in mind that the above may, and may not, be what the interviewer would like to hear from you.  In such cases it is best to prefix your answer with a disclaimer like Well, I would of course follow whatever discipline is generally used in the house, but if it was completely up to me, then I would ...