Content (TL;DR) on tips, tricks, advice, practices for naming things in software/technology
Naming guidance like .NET Framework Guidelines are helpful, but they only help in minor situations and don't really a lot help solve the naming things problem in software.
Detail research results around where some of the pain points in naming are, analyze potential solutions, and provide guidance for making naming things easier.
- There are always exceptions, we can only mitigate their effect
- Purposefulness This means doing this on purpose, or by design.
- Consistency Enough said
- Least Astonishment Building on consistency, where consistency of intuitiveness is important.
These guidelines focus on wording over capitalization. Capitalization is important, but that is an externally-defined style.
- countable noun
- ...coming soon...
- mass noun
- ...coming soon...
- uncountable noun
- ...coming soon...
- collective noun
- ...coming soon...
- deverbal noun
- ...coming soon...
- noun of action
- ...coming soon...
- Zero Derivation Words
- ...cmming soon...
- metonym
- ...coming soon...
- homograph
- ...coming soon...
Compartmentalization Compartmentalize things that can be reasoned about independently of other things; these are the things that require names. One thing that makes naming hard is naming things that have no unique attributes or behavior.
Namespaces suit a couple of needs, both relating to the grouping of types. Grouping types within a namespace should be based on functionality.
Use a pluralized noun for namespaces that group types related by interface A namespace that contains types related by interface should be named with a pluralized noun. One is a grouping of types that implement a specific interface. A Collections suffix signifies the namespace contains types that implement interfaces that allow types to act as collections.
Use a mass deverbal noun for namespaces that group types related by functionality (but different). The other grouping can cause some consternation because the grouping can easily feel subjective. You can also group types by functional usage. This type of grouping can be thought of as capability grouping. In which case the namespace name can be a noun of action or a noun based on a verb. The suffixes "-ion" and "-ing" come into play here. e.g. Processing or Administration.
Use countable nouns or pluralized adjectives for namespaces that classify other namespaces System.Diagnostics.Tracing
Use adjectives or mass nouns to sub-group types related by interface System.Collections.Generic, System.ComponentModel.Composition.
Being successful: Perform grouping on purpose, only group types with similar attributes or similar behavior (randomly grouping types within a namespace is very subjective). Prefer nouns that describe an act or responsibility. Avoid ending in "-ion", avoid words ending in "-tion" or "-sion. A "mass noun" is also called a noncountable noun. Avoid words that function as mass deverbal nouns but often also function as adjectives (need example).
Namespace names should signify how the types in the namespaces are grouped.
See also General
Assemblies are the deployable binary groupings of compiled code. As such, the context of these binaries is generally the file system or URIs. Assemblies often travel in packages and thus have unique constraints that affect naming. Assembly names can be scoped by directory, but that depends on deployment and choices outside of your control (names of 3rd party assemblies and packages).
Prefer Common nouns A common noun is a noun that isn't a proper noun: they are names for general things rather than names that identify specific things.
Being Successful Avoid plural, mass, and collective nouns; as well as words that act as nouns and other parts of speech
See also General
Avoid deverbal nouns for value types (nouns derived from verbs, e.g. -or, -ant, -ar -ian, See also General [Structs]: #structs
Structs often function as value types, avoid deverbal nouns for structs (nouns derived from verbs, e.g. -or, -ant, -ian, -er, etc.)
See also General
Prefer Adjectives Formed From Verbs Adjectives describe attributes of something, like abilities. Not all adjectives describe abilities, but as an interface is a representation of an ability it's name should represent an action. The suffixes -able, -ible, and -ive are important: these suffixes form adjectives from verbs (actions, abilities). -able/-ible are used with verbs for interfaces representing an inherent ability of an implementation (Enumerable in IEnumerable, to represents something that you can enumerate) (or something that has the ability to be enumerated). -ive is used with verbs for interfaces that perform a type of functionality (Transmissive in ITransmissive for something that transmits).
-able/-ible something that can have an action performed on it.
-ive something that performs an action.
See also General
See also General
See also General
Avoid Ambiguity Avoid using words that are prone to misinterpretation or are used to mean many things.
Avoid Zero Derivation Words (Avoid Homographs or Avoid Metonyms) Zero derivation words are when a new "word" (meaning) is created from another word without using derivation (e.g. affixes are common in creating new meanings and words, deriving them from a root word and adding the affix).
Homograph is another name for words spelled the same, but different meaning.
Metonym means a word substituted for another with a different meaning.