Hacker News Reader

Comment by mbo | Hacker News Reader

While I am not a Uncle Bob-style "no comments"er I do love a ridiculous method name. I pay very close attention to that method and the context in which it is called because, well, it must be doing something very weird to deserve a name length like that.

View on HN

That’s exactly why you should save that length only for a method that’s indeed doing something weird. If every method is long, the codebase turns into noise. (IOW I agree)

This doesn’t happen in reality. Your program does so many things that practically speaking short names work for a lot of functions in the program. It’s like English. There are big words and there are small words and usually to communicate a combination of big and small words are used.

Nobody practically communicates with big words. A long function name only pops up when needed.

It happened in the article we’re discussing, and seems to be something Robert advocates for.

Happened in a contrived example.

Contrived perhaps, but it was an example that was supposed to demonstrate the benefits to those long names. In my opinion, it did the opposite.

I used to work this way, but I found that every non-trivial method involves edge-cases and workarounds documenting them the method name destroyed readability.

The only point I was making is that short name signals that nothing unusual is going on, and long name signals that you have to pay extra attention. I never suggest to replace a comment with a long name. Here's my 4 reasons to leave a comment: https://max.engineer/reasons-to-leave-comment Comments are crucial for "why", and additional context. Name shouldn't go beyond "what". More on that here: https://max.engineer/maintainable-code (Check the "What" section that focuses on naming).

There are a few Haskell functions with names like reallyUnsafePtrEquality# or accursedUnutterablePerformIO, and you know something interesting is going on :P

Reply on news.ycombinator.com