3 ms·
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. (I
by hakunin 2y ago
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)
- ninetyninenine 2y agoThis 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.
- hakunin 2y agoIt happened in the article we’re discussing, and seems to be something Robert advocates for.
- ninetyninenine 2y agoHappened in a contrived example.
- kristiandupont 2y agoContrived perhaps, but it was an example that was supposed to demonstrate the benefits to those long names. In my opinion, it did the opposite.
- Pxtl 2y agoI 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.
- hakunin 2y agoThe 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 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 https://max.engineer/maintainable-code (Check the "What" section that focuses on naming).