Those of us who are responsible for groups of production computers, whether client or server class, are familiar with the conundrum of having to adopt some logical and appropriate naming system for them. Different companies of different sizes have historically adopted anything from the names of the seven dwarves to a simple alphanumeric numbering scheme.
Best practices for file naming Menu How you organize and name your files will have a big impact on your ability to find those files later and to understand what they contain. You should be consistent and descriptive in naming and organizing files so that it is obvious where to find specific data and what the files contain.
- And how good are you at following them could decide the longevity of your career in Software Development. Since I code in Python, so I’ll be talking about the Python naming conventions in this post.
- Use naming to help you design the program Pretend there's a rule saying 'you can never write a void function', then think about all the steps your program makes to transform input into output, then chose names for those steps so you could make a written sentence with them. These are now your function names and the sentence is your program's.
- These best practices will not just improve readability of your code; you will learn to create quality software. The topics can be broadly divided into two categories; one is naming convention and second is the best practices to design a class. Naming Conventions- Avoid ambiguous and small names which are hard to understand.
In an ideal world, a naming convention should allow you to ascertain useful information describing the target host or hosts. Integrating a certain amount of logic into a naming system will allow you to address any specific subgroup of your managed environment, like querying a database for a subset of information using the appropriate wildcards. This is especially useful, for example, in applying policies or distributing software in some automated manner.
In this article, I will discuss the qualities I feel a good naming convention should have, examples and pros and cons of the kinds of information I have historically found useful to include in such a system, some of the potential technical limitations that exist and will conclude by providing one possible naming convention scenario. I should also point out that, for the sake of completeness, some of the points I am about to make actually contradict each other. An ideal naming convention for your particular situation will most probably require you to pick and choose certain elements of this article while ignoring others.
When to consider implementing a naming convention
A structured naming convention will be most useful in a large, dynamic environment. Large environments are usually more complex and therefore require its administrators to be more organized. Of course, if you are managing only a handful of computers, a naming convention may not be critical, but you may still need to give it some thought.
If the environment you manage is small but highly dynamic or called upon to grow within the foreseeable future, there may be a case to plan ahead and establish a system that meets your needs today while providing room to grow. It's sometimes hard to predict the future, so if you have any hesitation, it would be more conservative to adopt something that may seem overkill at first so that you don't regret it later. A few hours of thought, research and planning might save you from having to rename every computer at your company, and that's in the best case scenario where you can agree on a standard before the first computer is even deployed.
Most of us will, at one point in time, question the existing standard (if there is one) and how well it meets your current needs. You may even decide to bite the bullet and rename every computer, either all at once or by attrition (by adopting the new standard 'going forward' and live with two standards until all computers have been migrated to the new convention) in order to conform to newly adopted standards. The key is determining what makes up a good naming convention to begin with/
Effective naming conventions I have used in the past usually have at least some of the following qualities:
Parsability
Parsability refers to the ability to parse the naming convention for meaning. Basically, your naming convention should be made up of combinations of acronyms that represent actual information that someone reading any given computer name might like to be aware of.
Another benefit of 'parsability' is that, given a structured convention, automation and programming can easily be built around it so that computers can be categorized more easily. An easily 'parsable' computer naming convention would be made up of the following characteristics:
A set number of characters for each informational component
Each possible value for each informational component should already be identified and documented before the convention is adopted but other values can also be defined later should new needs arise. For example, if the first two letters of the naming convention should represent the country where the asset is located, two letter acronyms for all countries with company offices should be established.
If new offices are later opened in a new country, a new, unique two letter acronym can then be added. This characteristic also has the added bonus of making it easy to target a specific population based on any informational component. Indeed, since each component is made up of a set number of characters, the right number of wildcards can be used to ignore any informational component not required for a given query.
An overall consistent number of characters for all computer names
Consistency is always easier to plan for at any level, so if all computer names are of the same length, they should programmatically be easier to deal with. If a consistent number of characters is impossible, then the variable length component or components should be placed in the right most positions so that the prefix remains predictable and meaningful, while the variable length information can be isolated by eliminating all characters before a certain position.
![Naming Naming](/uploads/1/3/3/2/133274285/450802392.jpg)
Informational Component 'Permanence'
This characteristic basically means that the informational components you choose to include in your computer naming convention should strike a balance between their potential usefulness to stakeholders and the overhead created by their level of 'permanence'. For example, should you choose to use the computer office location as a part of the name, the computer would need to be renamed anytime the computer moves to a new office. How much of a problem that is depends on how dynamic this information tends to be for your environment. Ideally, a computer's name shouldn't have to change over the course of its production lifetime or at least until it is recycled and redeployed.
Logic, consistency, and intuition
A good naming convention should also strive to achieve a certain level of logic so that stakeholders can intuitively deal with computer names. This can be achieved by attempting to maximize the following qualities of your naming convention:
Drill down approach
It is preferable to make each component a subset of a previous one (apart from the first of course, which would set the tone). For example, if a naming convention were used that was strictly based on geographical location, it would make sense to use a structure such as Country, Site, Building, Office, etc. rather than something like Office, Country, Building, Site.
Consistent Number of characters per piece of information
Also, if at all possible, a naming convention using the same number of letters for each informational component contained within it would make it more intuitive to work with. Using the geographical location example again, you can see how a stakeholder dealing with a name starting with 'US' which he/she correctly assumes refers to location, might intuitively look to the next two letters as the following piece of information in the chain relating to the asset's location.
Reuse of existing information
If there are any existing, widely used systems within your company that already use acronyms such as the ones needed for your naming convention, you should look for ways to bank on their existing visibility to build extra intuitiveness into your system.
Data That Describes the PC, not the employee
Information contained in the naming convention should also be aimed at describing the computer itself rather than its user. Node names pertain to the actual computing asset and some of its attributes are already dynamic enough. Adding data pertaining to the owner would add a separate dimension that would only increase the risk and frequency of changes to the asset's name. The connection to the employee, which represents a separate entity, should already be documented in the asset tracking system anyway and that's where it should be managed.
Minimize the use of non meaningful characters
At one point, it does become necessary to assign a numbering scheme to any defined prefix if the prefix itself cannot insure that the asset can be uniquely identified. However necessary, this practice should be minimized as much as possible to insure that the naming convention is as intuitive and meaningful as possible. Also, it would be preferable that the prefix be made of letters (or even acronyms, if space allows), followed by numerical characters to make it obvious that the meaningful part of the name is made up strictly of letters, while the numbers have no actual meaning.
Here's a list of components you can and should try to include in your naming convention:
- Operating Environment - Possible values for such an attribute include test, development or production. Computers would need to be renamed before moving from one environment to another, which shouldn't be a problem since a computer would rarely 'graduate' from one environment to the other without being at least renamed, if not completely rebuilt.
- Location - Information could also be included regarding the computer's location. Possible informational components could include:
- Country
- Site/City
- Building
- Office
Country and site are not very likely to change for a given asset and provide an easy way to programmatically obtain numbers on the quantity of deployed computers per country / site. Building and office locations are likely to change relatively often which would probably create excessive overhead in having to rename the computer too often.
- Usage Type - Possible values include Office, Lab or Kiosk/Public computers. This component would allow targeting of computers based on their intended use within the company.
- Company Division / Department - Indicates the company division the asset is associated with. Whatever your company's structure, it may be a good idea to include something to that effect within the naming convention since different divisions/departments have different needs and being able to isolate all relevant computers in a single stroke can be very useful.
- Employee's Username - This component could potentially make it easier to identify the computer's user on the fly. However, it can constitute a major security risk. A DNS scan of your corporate network (which, most of the time, can be performed without any kind of network authentication) could potentially reveal the usernames of everyone in the company, and you know one of them probably has a really simple password. With username conventions most often containing at least part of the person's name, high profile accounts can become easier to target. Also, not only does this information pertain to the user and not the PC, but if your usernames don't all have the same length, this would mean introducing a variable length informational component.
- Employee Employment Type - Potential values include contractor, temporary or permanent employment types. This component could allow us to target computers based on the employment type of the owner. It should be evaluated whether such a categorization is required since this is information pertaining to the employee, not the computer and should be avoided if possible. This component can also bring about the need to change the computer name if the employee's status should change over time.
- Platform - This component specifies the operating system used on the asset, such as Microsoft Windows or Linux. This component will only be useful if you support multiple platforms. Otherwise, it can be a waste of precious host name characters.
- HW Portability - This component is basically made up of a character or abbreviation with two possible values, desktop or laptop, or something similar, indicating whether or not the computer is likely to change locations on a regular basis. This allows targeting of portable computers as opposed to non portable / desktop computers and could help explain why certain computers move around so much. For example, if a desktop computer is scanned on a network segment that does not correspond to the one recorded in the asset's documented location, this could be proactively addressed.
- Client / Server - So far, in this article, I have mentioned components that are mostly useful for workstation class computers. You may want your convention to cover your server farm as well, but this may become problematic as the information you want provided by the naming convention may vary from one platform to another. Server naming conventions will typically make some reference to the server's main task which is usually unnecessary on the client side.
There a lot of components you can include as part of your naming convention. That doesn't mean that you should include them. In some cases, there may be limitations or technical considerations that will control your naming convention. Here are some of them:
- Maximum length of host names (DNS, Microsoft, etc.) - Computer names lengths are traditionally limited to 14 characters, which is where certain types of systems usually start having problems dealing with host names. It should be noted that this limitation is mostly imposed by older technologies and protocols which are no longer widely used, such as NetBIOS. How relevant this limitation is to you will depend on whether or not you are still expected to support such legacy technologies in your particular environment.
- No Special Characters - Given that special characters basically represent some form of punctuation, they basically amount to a waste of space for a computer name, especially since there are a limited number of characters you can use. Also, some systems frown on such a practice and allowing them into your naming convention could cause unforeseen issues in the future. The only situation in which the use of separator type characters might be useful would be for readability purposes where a naming convention uses components of different lengths that, combined, don't come anywhere near making up a name that may potentially be too long.
After all of this theoretical discussion, let's put some of this information into play. Here is a naming convention that might make sense for a large company:
DDCCSSUPOXXXX
Division (D) - Country (C) - Site (S) - Usage Type (U) - Portability (P) - Operating Environment (O) - Numbering Scheme (XXXX)
I personally like this convention because it provides me with a lot of information I want to know about a computer on a routine basis. Also, once the meaning of the different acronyms has been assimilated by support staff, they can translate the computer name very easily into a meaningful sentence. One example, using this convention, would be: 'Manufacturing desktop computer located in Boston, U.S.A. used for production office work' while the actual name of the computer might be something like 'MAUSBOODP0001' or 'Research laptop computer located in London, England used for testing in a lab environment' for a node name like 'RDENLDLLT0001'.
Active1 year, 1 month ago
A long time ago I have read an article (I believe a blog entry) which put me on the 'right' track on naming objects: Be very very scrupulous about naming things in your program.
For example if my application was (as a typical business app) handling users, companies and addresses I'd have a
User
, a Company
and an Address
domain class - and probably somewhere a UserManager
, a CompanyManager
and an AddressManager
would pop up that handles those things. https://dirrenew967.weebly.com/adobe-master-collection-cs5-key.html.So can you tell what those
UserManager
, CompanyManager
and AddressManager
do? No, because Manager is a very very generic term that fits to anything you can do with your domain objects.The article I read recommended using very specific names. If it was a C++ application and the
UserManager
's job was allocating and freeing users from the heap it would not manage the users but guard their birth and death. Hmm, maybe we could call this a UserShepherd
.Or maybe the
UserManager
's job is to examine each User object's data and sign the data cryptographically. Then we'd have a UserRecordsClerk
.Now that this idea stuck with me I try to apply it. And find this simple idea amazingly hard.
I can describe what the classes do and (as long as I don't slip into quick & dirty coding) the classes I write do exactly one thing. What I miss to go from that description to the names is a kind of catalogue of names, a vocabulary that maps the concepts to names.
Ultimately I'd like to have something like a pattern catalogue in my mind (frequently design patterns easily provide the object names, e.g. https://dirrenew967.weebly.com/windows-xp-iso-file-download-64-bit.html. a factory)
- Factory - Creates other objects (naming taken from the design pattern)
- Shepherd - A shepherd handles the lifetime of objects, their creation and shutdown
- Synchronizer - Copies data between two or more objects (or object hierarchies)
- Nanny - Helps objects reach 'usable' state after creation - for example by wiring to other objects
- etc etc.
So, how do you handle that issue? Do you have a fixed vocabulary, do you invent new names on the fly or do you consider naming things not-so-important or wrong?
P.S.: I'm also interested in links to articles and blogs discussing the issue. As a start, here is the original article that got me thinking about it: Naming Java Classes without a 'Manager'
Update: Summary of answers
Here's a little summary of what I learned from this question in the meantime.
- Try not to create new metaphors (Nanny)
- Have a look at what other frameworks do
Further articles/books on this topic:
- Book: Design Patterns: Elements of Reusable Object-Oriented Software (Hardcover)
- Book: Patterns of Enterprise Application Architecture (Hardcover)
- Book: Implementation Patterns (Paperback)
And a current list of name prefixes/suffixes I collected (subjectively!) from the answers:
- Coordinator
- Builder
- Writer
- Reader
- Handler
- Container
- Protocol
- Target
- Converter
- Controller
- View
- Factory
- Entity
- Bucket
And a good tip for the road:
Don't get naming paralysis. Yes, names are very important but they're not important enough to waste huge amounts of time on. If you can't think up a good name in 10 minutes, move on.
closed as not constructive by casperOneJul 26 '12 at 12:15
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
13 Answers
https://dirrenew967.weebly.com/shockwave-player-64-bit-download.html. I asked a similar question, but where possible I try to copy the names already in the .NET framework, and I look for ideas in the Java and Android frameworks.
It seems
Helper
, Manager
, and Util
are the unavoidable nouns you attach for coordinating classes that contain no state and are generally procedural and static. An alternative is Coordinator
.You could get particularly purple prosey with the names and go for things like
Minder
, Overseer
, Supervisor
, Administrator
, and Master
, but as I said I prefer keeping it like the framework names you're used to.Some other common suffixes (if that is the correct term) you also find in the .NET framework are:
Builder
Writer
Reader
Handler
Container
You can take a look at source-code-wordle.de, I have analyzed there the most frequently used suffixes of class names of the .NET framework and some other libraries.
The top 20 are:
- attribute
- type
- helper
- collection
- converter
- handler
- info
- provider
- exception
- service
- element
- manager
- node
- option
- factory
- context
- item
- designer
- base
- editor
I'm all for good names, and I often write about the importance of taking great care when choosing names for things. For this very same reason, I am wary of metaphors when naming things. In the original question, 'factory' and 'synchronizer' look like good names for what they seem to mean. However, 'shepherd' and 'nanny' are not, because they are based on metaphors. A class in your code can't be literally a nanny; you call it a nanny because it looks after some other things very much like a real-life nanny looks after babies or kids. That's OK in informal speech, but not OK (in my opinion) for naming classes in code that will have to be maintained by who knows whom who knows when.
Software Build Naming Conventions
Why? Because metaphors are culture dependent and often individual dependent as well. To you, naming a class 'nanny' can be very clear, but maybe it's not that clear to somebody else. We shouldn't rely on that, unless you're writing code that is only for personal use.
In any case, convention can make or break a metaphor. The use of 'factory' itself is based on a metaphor, but one that has been around for quite a while and is currently fairly well known in the programming world, so I would say it's safe to use. However, 'nanny' and 'shepherd' are unacceptable.
We could do without any
xxxFactory
, xxxManager
or xxxRepository
classes if we modeled the real world correctly:;-)
It sounds like a slippery slope to something that'd be posted on thedailywtf.com, 'ManagerOfPeopleWhoHaveMortgages', etc.
I suppose it's right that one monolithic Manager class is not good design, but using 'Manager' is not bad. Instead of UserManager we might break it down to UserAccountManager, UserProfileManager, UserSecurityManager, etc.
'Manager' is a good word because it clearly shows a class is not representing a real-world 'thing'. 'AccountsClerk' - how am I supposed to tell if that's a class which manages user data, or represents someone who is an Accounts Clerk for their job?
Peter Mortensen14.5k1919 gold badges8989 silver badges118118 bronze badges
Mr. BoyMr. Boy23.4k7474 gold badges253253 silver badges480480 bronze badges
Since you're interested in articles in this area, you might be interested in Steve Yegge's opinion article 'Execution in the Kingdom of Nouns':
When I find myself thinking about using
Manager
or Helper
in a class name, I consider it a code smell that means I haven't found the right abstraction yet and/or I'm violating the single responsibility principle, so refactoring and putting more effort into design often makes naming much easier. Free television series episodes.But even well-designed classes don't (always) name themselves, and your choices partly depend on whether you're creating business model classes or technical infrastructure classes.
Software Naming Conventions
Business model classes can be hard, because they're different for every domain. There are some terms I use a lot, like
Policy
for strategy classes within a domain (e.g., LateRentalPolicy
), but these usually flow from trying to create a 'ubiquitous language' that you can share with business users, designing and naming classes so they model real-world ideas, objects, actions, and events.Technical infrastructure classes are a bit easier, because they describe domains we know really well. I prefer to incorporate design pattern names into the class names, like
InsertUserCommand,
CustomerRepository,
or SapAdapter.
I understand the concern about communicating implementation instead of intent, but design patterns marry these two aspects of class design - at least when you're dealing with infrastructure, where you want the implementation design to be transparent even while you're hiding the details.Being au fait with patterns as defined by (say) the GOF book, and naming objects after these gets me a long way in naming classes, organising them and communicating intent. Most people will understand this nomenclature (or at least a major part of it).
Brian AgnewBrian Agnew236k3434 gold badges295295 silver badges407407 bronze badges
If I cannot come up with a more concrete name for my class than XyzManager this would be a point for me to reconsider whether this is really functionality that belongs together in a class, i.e. an architectural 'code smell'.
I think the most important thing to keep in mind is: is the name descriptive enough? Can you tell by looking at the name what the Class is supposed to do? Using words like 'Manager', 'Service' or 'Handler' in your class names can be considered too generic, but since a lot of programmers use them it also helps understanding what the class is for.
I myself have been using the facade-pattern a lot (at least, I think that's what it is called). I could have a
User
class that describes just one user, and a Users
class that keeps track of my 'collection of users'. I don't call the class a UserManager
because I don't like managers in real-life and I don't want to be reminded of them :) Simply using the plural form helps me understand what the class does.DroozleDroozle
Specific to C#, I found 'Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries' to have lots of good information on the logic of naming.
As far as finding those more specific words though, I often use a thesaurus and jump through related words to try and find a good one. I try not to spend to much time with it though, as I progress through development I come up with better names, or sometimes realize that
alx9rSuchAndSuchManager
should really be broken up into multiple classes, and then the name of that deprecated class becomes a non-issue.1,81722 gold badges1818 silver badges4141 bronze badges
AaronLSAaronLS28.5k1616 gold badges123123 silver badges178178 bronze badges
I believe the critical thing here is to be consistent within the sphere of your code's visibility, i.e. as long as everyone who needs to look at/work on your code understands your naming convention then that should be fine, even if you decide to call them 'CompanyThingamabob' and 'UserDoohickey'. The first stop, if you work for a company, is to see if there is a company convention for naming. If there isn't or you don't work for a company then create your own using terms that make sense to you, pass it around a few trusted colleagues/friends who at least code casually, and incorporate any feedback that makes sense.
Applying someone else's convention, even when it's widely accepted, if it doesn't leap off the page at you is a bit of a mistake in my book. First and foremost I need to understand my code without reference to other documentation but at the same time it needs to be generic enough that it's no incomprehensible to someone else in the same field in the same industry.
Jim Ferrans22.6k1010 gold badges4949 silver badges8181 bronze badges
LazarusLazarus33.8k44 gold badges3737 silver badges5252 bronze badges
I'd consider the patterns you are using for your system, the naming conventions / cataloguing / grouping of classes of tends to be defined by the pattern used. Personally, I stick to these naming conventions as they are the most likely way for another person to be able to pick up my code and run with it.
For example UserRecordsClerk might be better explained as extending a generic RecordsClerk interface that both UserRecordsClerk and CompanyRecordsClerk implement and then specialise on, meaning one can look at the methods in the interface to see what the its subclasses do / are generally for.
See a book such as Design Patterns for info, it's an excellent book and might help you clear up where you're aiming to be with your code - if you aren't already using it! ;o)
I reckon so long as your pattern is well chosen and used as far as is appropriate, then pretty uninventive straightforward class names should suffice!
CarolineCaroline77033 gold badges1010 silver badges2828 bronze badges