You'll find plenty of exceptions if you keep looking — e.g.
NSolve (Hungarian-like), etc.
I've always felt it's better to be more pragmatic about things like naming conventions as it allows for flexibility in the language design. I dare say it even improves readability at times, because it allows the designer to pause and reflect on how a symbol might be used and how it appears when read in code (as opposed to sticking to a naming dogma). In the case of image processing functions, I suppose the thought process was something like this:
Dimensions are generically named functions that are also meaningful in the image processing context. But rather than overload these existing (possibly heavily optimized) functions to work on
_Image, it makes sense to create separate symbols. So...
ApplyOnImage? A bit too verbose, even for Mathematica, and doesn't evoke the same simplicity as the parent functions.
You then start using a prefix to common functions that immediately convey to the user what it does (because you're already familiar with the verb/noun) and what it acts on (the prefix) e.g.
ImageConvolve, etc. This also helps disambiguate context specific uses of the noun/verb from generic ones.
- Once you do this, you've now already established sort of a soft convention that seems to fit well, so you then extend the idea to other symbols (but not necessarily based on pre-existing ones) such as
ImageData, etc. The noun/verb conveys the meaning succinctly and can be used with other data types just as easily (e.g.
- Then finally you come to specialized functions which really have no use cases other than in image processing —
Closing, etc. And now you've broken your own convention. And that's OK.
Could they have added an
Image- prefix to all of these specialized functions for consistency? Yes. Should they have? Probably not, since it adds no additional information. Is it more readable as a result of not sticking to the rules? I would argue yes. If one must insist on consistency, then insisting on local consistency (within a specific package/functionality/group of functions) is better than insisting on global consistency.