Hacker News Reader

Comment by tmikaeld | Hacker News Reader

I like the logic of this, but it goes against all books that i've read to keep it short. Why do we need to keep it short?

View on HN

In this case it's a symptom of poor cohesion and separation of concerns. If you find you're having to give very long names for things, it's worth looking for a way to decompose it into separate things that each do one simple thing. Then more than likely writing the code that composes the separate objects with the right operations will be the perfect substitute for the long name, and it will also be easier to maintain, since you won't have to update both the variable name and the logic that uses it; rewriting the actual expression or logic where it is used will take care of both tasks in one. This is what I usually take from the principle of letting the code itself be your documentation, where reasonable.

Who says reverseListAndAddOneToEachElement isn't defined via the composition of smaller "separate things that each do one simple thing?" The naming convention still stands as it is not a "symptom of poor cohesion and separation of concerns."

We need to expend effort to keep names short, while it is easy to let them become long. 'Keep it short' is shorthand for 'do not forget to expend effort towards keeping names from becoming long'. It's easy to unthinkingly come up with 'company_people'. It takes effort to reduce it to 'employees'.

It's actually not just 'short', but 'short and simple'.

I think it's the other way around. Programmers instinctively want to keep names elegant, similar to how they structure their code. IMO they actually have to kind of step out of their comfort zone if they want to write an ugly (but clear) name.

You shouldn't try to make it short on purpose because that will obscure the meaning of the variable. But long name by itself could be systematic error in abstraction (BananaSingletonFactoryFactoryCacheFactory comes to mind). At the very least, reading long name will also take a lot more mental power to understand.

Of course, if the meaning makes no sense it shouldn't be long.

But if the longer name provide meaning, shouldn't we use it if it's a complex thing and the words bring value?

Easier to keep short names in programmers memory and less chance of spelling mistakes.

in my case spelling mistakes are handled by the the editor or IDE.

And how would an ide know that n0cars should be nocars

An editor probably not know this but an IDE would. The IDE actually partially understands your code. If your function definition was (in python):

   def nocars

but you called the function with:

   n0cars()

The ide would highlight n0cars because it could not find the definition. The IDE literally destroys the possibility of making trivial mistakes like this in a non-compiled language.

Of course this depends on the ide. I use pycharm which not only checks for mistakes like these, but it highlights and automatically formats code to fit within PEP guidelines. The whole IDE actually attempts to fit your programming universe within the app, including debugging, and even connecting to a database.

It does come at a cost, however. Pycharm is heavy app and can be slow at times. It's also a complex tool to learn, but I wouldn't say it's more complex than learning vim or sublime.

I was referring to a variable not a function and as you say IDE's can have heavy over head not every one can afford a full copy of visual studio or a system powerful enough to run eclipse

Visual Studio Community Edition, there you go -> https://www.visualstudio.com/en-us/products/visual-studio-co...

Agreed Eclipse is a hog that should be lead to the slaughter. But an acceptable dev machine can be had for $250 at Best Buy.

Reply on news.ycombinator.com