Why is it hard to name things?

Asked

Viewed 83 times

4

Reading this question I came across the following sentence:

There are only two hard problems in Computer Science: cache invalidation and naming Things.

-- Phil Karlton

The focus is on the second problem that is to name the things, which seems to be referring to variables, functions or anything else in programming. Of course this can be a kind of "joke" too, seeing that it seems simple to name things xD. However, when we realize, it becomes a somewhat complicated task.

At least for me, it is often complicated to give name to functions and variables, even classes, I always wrap myself in the meaning that that code should pass and makes me think a lot about its interpretation, different from mathematics where the shape helps to visualize patterns.

Here are some examples of names of methods that have become very long and that I have had difficulty naming in the past:

  • EstaNoCaixaAbertoDoDiaAtual(int idBaixaServico)
  • Caixa.ObterIdDoCaixaAbertoNoDia()
  • ExisteRegistroDeAberturaPendente()

And there are even native PHP functions like geoip_time_zone_by_country_and_region or mailparse_determine_best_xfer_encoding which has a somewhat long and complicated name. This may repeat in other languages and libraries, but I will not list them all here.

I could even decrease the names by creating classes or making another kind of separation, which leads me to think that object-oriented programming is to help name things after all (of course it goes much further)And all this verbosity leaves the task of appointment very costly, no doubt it seems.

Against this background, I would like my question answered.

Question

  • Why is it so difficult to name things, is there any way get around this problem?
  • I read your 2x text and I couldn’t get the point. You mean: naming variables, functions, classes? If it is, I humbly and with all due respect, find the easier part of the code.

  • 2

    Putz, I was going to answer this t, but I’m with p last x i yet and I can’t figure out what the variables t, p, x and i are.

  • 1

    Overall, I think the naming process requires that the solution is properly structured; and structuring the solution requires mastery of it; and mastering the solution requires mastery of the problem; and mastering the problem requires being able to understand the name of things;

  • 2

    Just in case, name things after facial hair (Beard, Moustache, Goatee) and delegate to the reviewer find the appropriate name!

1 answer

3

Computation is sometimes about modeling reality, which is extremely complex, in an algorithm, which in the background is arithmetic operations with control flow. Converting reality to code is a completely different challenge from the communication of your solution and the intent of your algorithm. A lot of this communication comes from the name you give things.

Note also that naming things is an activity of design that you do as a program. It is not fundamentally difficult, but creating short and clear names about what you are representing is rather a complex task. Still, it’s a skill that can be trained and enhanced. Reading other people’s code is a good exercise, both to learn and to think about how you could improve.

Suggestions

Another thing, which is a point of debate, is that in my opinion Portuguese is a very verbose language. Naming classes and variables in English leads to a more concise code, because English uses fewer prepositions, has generally shorter words and I feel there is greater standardization, but this is a debatable issue.

Its function is too long because it is very specific. In the following example I also leave the function more flexible to accept a parameter that specifies the day, so it is easier to reuse it in other parts of the code.

- EstaNoCaixaAbertoDoDiaAtual(int idBaixaServico)
+ IsOnOpenCash(int idService, Date date=None)

- Caixa.ObterIdDoCaixaAbertoNoDia()
+ Cash.GetOpenCashId(Date date=None)

Note that I put date=None: Some languages like Python allow you to put standard arguments. Then the call to know if the box is open on the current day would be with only one parameter, equal in the original version. I like to leave so when the function will be mostly called in a condition (e.g. current day), but in some situations not. Then we can explicitly specify the day only in atypical situations. This is ok as long as it is well documented.

Compare the call to these functions in case we want information about the current day:

EstaNoCaixaAbertoDoDiaAtual(42)
IsOnOpenCash(42)

Caixa.ObterIdDoCaixaAbertoNoDia()
Cash.GetOpenCashId()

That’s 28 characters less!

Browser other questions tagged

You are not signed in. Login or sign up in order to post.