Creative terminology

Too often I use soft words such as node, property, children (etc.), and I'm afraid that someone else will be hard to understand my code simply because the part names are undefined, ordinary words.

How to find declaration names for classes and components to make them more memorable?

I especially have problems with universal tools that do not have a real description, except for their rather general functional purpose. I would like to know if other creative ways have been found to name things, and not just call them their usefulness, like AnonymousFunctionWrapperCallerExecutorFactory .

+6
language-agnostic terminology
source share
8 answers

I actually have no answer, but three things that you think about.

  • The late Phil Carleton famously said: “There are only two difficult problems in computer science:“ Lack of cache and naming. ”Thus, the fact that you are having problems with good names is absolutely normal and even expected.
  • OTOH, having problems with naming things, can also be a sign of poor design. (And yes, I understand very well that No. 1 and No. 2 contradict each other. Or maybe you need to think that this is more like balancing each other.) For example, if a thing has too many responsibilities, with a good name. (See all the Service, Utilities, Model, and Manager classes in poor OO constructs. Here’s an example of Google Code Search for “ManagerFactoryFactory . )
  • In addition, your names should appear in subject jargon used by subject experts. If you cannot find an expert in the subject, this is a sign that you are now worried about code that you should not worry about. (In principle, the code that implements your main business domain should be implemented and well designed, the code in the additional domains should be implemented and designed so-so, and all other code should not be implemented or developed at all, but bought from a vendor where what you buy is their main business domain. [Please interpret “buy” and “provider” liberally. Free software developed for the community is just great.])

As for No. 3 above, you mentioned in another comment that you are currently working on implementing a tree data structure. If your company does not sell tree-like data structures, this is not part of your primary domain. And the reason you have trouble finding good names may be because you are working outside your primary domain. Now, “selling data tree structures” may seem silly, but there are companies that do it. For example, the BCL team is inside the Microsoft developer unit: they actually sell (well, for certain definitions of "sell", anyway) the .NET Framework base class libraries, which include, among other things, tree-like data structures. But note that, for example, the Microsoft C ++ compiler team actually (literally) buys its STL from a third-party provider - they believe that their main domain is written by compilers, and they leave the libraries of the company that believes that the STL files to be written use their main domain, (And indeed, AFAIK, this company does nothing but write and sell STL implementations. This is their only product.)

If, however, selling tree-like data structures is your primary domain, then the names you provided are just fine. These are the names that subject matter experts (programmers, in this case) use when talking about a domain of tree-like data structures.

+3
source share

It’s hard to answer. I find them only because they seem "suitable."

However, I know that I find that in principle it is impossible to move around writing code if something is not named correctly and it is "good." If it is not named correctly, it is difficult for me to use it, and the code is usually confused.

I'm not too worried that something is “catchy,” only “accurate.”

As you know, I sat, thinking aloud about what to call something. Take your time and make sure you're really happy with the name. don't be afraid to use simple / simple words.

+4
source share

The use of “metaphors” is a common theme in flexible (and figurative) literature.

"Children" (in your question) is an example of a metaphor that is widely used and for good reason.

So, I would recommend using metaphors, provided that they are applicable, and not a fragment of the imagination.

Metaphors are everywhere in computing. From files to errors to pointers to threads ... you cannot escape them.

+3
source share

I believe that for standardization and communication it is useful to use common vocals, as in the same case for design patterns. I have a problem with a programmer who "invents" his own conditions, and I do not understand his understanding. (He continued to use the term “orchestration events” instead of “scripts” or “FCFS process.” Kudos for creativity!)

Those general dictionaries describe the material we are used to. A node is a point somewhere on a chart, in a tree, or something. One way should be domain specific. If we make a display problem, instead of "node", we can use "location". It helps in a way, at least for me. Therefore, I believe that it is necessary to balance the ability to communicate with other programmers and at the same time keep the descriptor specific enough to help me remember what it does.

+2
source share

I think node, children and property are great names. I already guess about your classes, just their "soft" names:

  • Node - this class is part of the object graph.
  • children - this variable contains a list of nodes belonging to the containing node.

I don’t think that "node" is either indefinite or common, and if you are coding a common data structure, it is possible that you have common names! (With that said, if you are coding a tree, you can use something like TreeNode to emphasize that node is part of the tree.) One way to make life for developers who will use your API is to follow the naming conventions of your platform built into libraries. If all calls are node a node, and the iterator is an iterator, this makes life easier.

+2
source share

Names that reflect the purpose of a class, method, or property are more memorable than creative ones. Modern IDEs make it easier to use longer names, so consider them to be descriptive. Acquiring creativity will not help how to get accurate information.

+1
source share

I recommend choosing nouns from a specific application domain. For example. if you put cars in a tree, call the class of the node class - the fact that it is also a node should be obvious from the API. In addition, do not try to be too general in your implementation - do not put all the car attributes in a hash table with property names, but create separate attributes for make, color, etc.

+1
source share

Many languages ​​and coding styles like to use all kinds of descriptive prefixes. There are no clear types in PHP, so this can help a lot. Instead of doing

 $isAvailable = true; 

to try

 $bool_isAvailable = true; 

This is admittedly a pain, but usually well worth the time.

I also like to use long names to describe things. This may seem strange, but it’s usually easier to remember, especially when I return to refactoring my code.

 $leftNode->properties < $leftTreeNode->arrayOfNodeProperties; 

And if all else fails. Why not retreat into a continuous thematic program of Star Wars.

 $luke->lightsaber($darth[$ewoks]); 

And finally, in college, I named my classes after my professor, and then my class methods were all I wanted to do to make this breakthrough.

 $Kube->canEat($myShorts, $withKetchup); 
-one
source share

All Articles