Clear and descriptive function names, concise and non-clever code, and a judicious use of well-named and concise helper functions are all way more valuable than

Clear and descriptive function names, concise and non-clever code, and a judicious use of well-named and concise helper functions are all way more valuable than docstrings. IMHO docstrings should be used as a last resort if the problem domain is truly complex enough to warrant it. Docstrings for trivial, well-named functions just get in the way, and if you feel the need to add a docstring to a complex function just after you've defined it, then I think that might be a hint that you should refactor the code to make it more clear and readable instead. An ns docstring that describes the intent of the api and docstrings for the major public interface functions are a good idea, but a blanket "docstring for every function" rule is a crutch to make up for unreadable, poorly-written code.