3 ms·

I used to like how overloading lets you call it sort instead of sortRectsByArea but over the years came to the opposite conclusion. Very short and generic names

by _yosefk 10y ago

I used to like how overloading lets you call it sort instead of sortRectsByArea but over the years came to the opposite conclusion. Very short and generic names are great for locals or for truly generic functions but generally a function name shouldn't be too generic IMO, both because grep has its uses regardless of IDE support and because it makes it less necessary to look up definitions. mergeTableCells is better than merge even if you know it's passed a list<TableCell> because merge could be merging the cells or the cell contents or who knows what else, and because looking up the type of the argument costs in itself (as it's not always a local declared right near the call and even if it is, the type might not be spelled out in the declaration.) Also, reusing names through overloading without providing actual polymorphism, either run time or compile time, is IMO bad, as in I don't get what's there to like. If one open function gets a file name and another gets a username and a password, what's so great in that they have the same name?

xapata 10y ago
Rather than ``sortRectsByArea`` I'd rather have a generic ``sort`` that supports a Schwartzian transform, like Python's ``sorted(stuff, key=transform)``. Function or method names that postfix the mode onto the verb, like "parse_from_file", are usually an indication that the design could be improved by creating a consistent interface for the various modes. Sometimes it's better to provide a handful of modes, but I always double-check when I see myself writing names like that. [0] https://en.wikipedia.org/wiki/Schwartzian_transform https://en.wikipedia.org/wiki/Schwartzian_transform [1] https://docs.python.org/3/library/functions.html#sorted https://docs.python.org/3/library/functions.html#sorted
- marcosdumay 10y ago
  That depends a lot on your actual architecture and domain. Some times, you need parse_from_file, and nothing else. Other times it's worth parametrizing everything and just assembly generic code at the top level.

by _yosefk 10y ago

xapata 10y ago

Rather than ``sortRectsByArea`` I'd rather have a generic ``sort`` that supports a Schwartzian transform, like Python's ``sorted(stuff, key=transform)``. Function or method names that postfix the mode onto the verb, like "parse_from_file", are usually an indication that the design could be improved by creating a consistent interface for the various modes. Sometimes it's better to provide a handful of modes, but I always double-check when I see myself writing names like that. [0] https://en.wikipedia.org/wiki/Schwartzian_transform https://en.wikipedia.org/wiki/Schwartzian_transform [1] https://docs.python.org/3/library/functions.html#sorted https://docs.python.org/3/library/functions.html#sorted

marcosdumay 10y ago
That depends a lot on your actual architecture and domain. Some times, you need parse_from_file, and nothing else. Other times it's worth parametrizing everything and just assembly generic code at the top level.