On 25 Nov 2011 21:44:41 Dean Michael Berris wrote:
function, it ceases to be a nameless function. The *utility* of having a function defined inside another function is marginal at best because they're absolutely better outside any other functions in all aspects: readability, maintainability, and functionality.
One of the many (often contradictory) heuristics for writing readable, maintainable code is to put declarations near the site of use. If you have a function-like predicate that is only used in one or two places, declaring it right before use makes it more likely that it will be kept in sync with any changes to the calling code. That can also make it easier for someone else (including the future you) to read and fully understand the code later, as less backscrolling/cross-referencing/memorization is required to fully understand what's going on. This is exactly the reason that literate programming tools normally provide (and encourage) a mechanism to interrupt the exposition of the calling function to define a callee, and then return to the parent. Like all other wisdom in this discipline, it's not absolute, but local functions can be a more useful organization tool than defining helper functions at namespace scope.
There's *no* practical reason to put a lambda in a named variable when the point of lambda's are so that you can define them in-line. I would
If they're stored in named variables, you can (more cleanly) switch between two (or more) different predicates based on a runtime condition. You can also put them in an array or container and select based on some key (e.g. for an event handler) or iterate over a subset (e.g. repeating some for_each() loop with several different evaluation metrics.) Furthermore, giving something a name is an opportunity to communicate something about your intent to a future reader--- if "_1 < _2 ? _1 : _2" is named "select_max" then I can suspect a problem; if it's anonymous I might not. These are all the same reasons we put function pointers and function objects in named variables and containers--- sometimes it makes sense to organize the referent functions at namespace scope, and sometimes it doesn't.