# What naming conventions are used for functions? [closed]

I thought there were patterns to how functions were named, but after looking carefully it seems I can always find exceptions. For instance

• FindThreshold = Action + Object
• SetAlphaChannel = Action + Object
• ReplaceImageValue = Action + Object

but... ImageResize = Object + Action, and why not ImageBinarize instead of Binarize?

## closed as off-topic by m_goldberg, MarcoB, dr.blochwave, Öskå, ilianAug 7 '15 at 22:21

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "The question is out of scope for this site. The answer to this question requires either advice from Wolfram support or the services of a professional consultant." – m_goldberg, MarcoB, dr.blochwave, Öskå, ilian
If this question can be reworded to fit the rules in the help center, please edit the question.

• There are some I find inconsistent. There's Binarize vs the non-existent ImageBinarize. There's the inconsistent pairs FromCharacterCode/ToCharacterCode vs FromRomanNumeral/RomanNumeral. Several "conversion" functions are ToThing, and several are just Thing: ToString, ToUpperCase vs LetterNumber and SparseArray. (In my mind, SparseArray is a conversion function, since the InputForm of a SparseArray object is of a very different format to the form in which one would usually input it.) – Patrick Stevens Aug 7 '15 at 15:10
• And why FindPeaks but PeakDetect? Perhaps consistency is the hobgoblin of small minds... – bill s Aug 7 '15 at 15:10
• @bills, it does make a kind of sense. FindThing finds a thing (perhaps numerically) and returns the thing and its location. ThingDetect returns the original object but where the thing is highlighted. – Patrick Stevens Aug 7 '15 at 15:14
• @bills … although it might be A New Kind of Sense. – Patrick Stevens Aug 7 '15 at 15:20
• I think this is a great question and would vote to re-open it. Understanding the logic and principles that have gone into System names can IMO be of great assistance in being able to correctly guess a new/recalled function but also in designing your code. Perhaps it could be narrowed down to a request for some small set of principles used in such naming? – Ronald Monson Aug 13 '15 at 0:12

You'll find plenty of exceptions if you keep looking — e.g. MapThread (action-action), FileExtension (object-object), NIntegrate, NSolve (Hungarian-like), etc.
• Compose, Convolve, Histogram, Apply, 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... HistogramOfImage? ConvolveWithImage? 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. ImageHistogram, ImageDimensions, 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 ImageCrop, ImageTrim, ImageResize, ImageData, etc. The noun/verb conveys the meaning succinctly and can be used with other data types just as easily (e.g. StringTrim).
• Then finally you come to specialized functions which really have no use cases other than in image processing — SetAlphaChannel, RemoveAlphaChannel, Opening, 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.