4 ms·
Your original function definition here: def find_xy_coordinate_of_dogs_cats_and_baboons_in_picture(picture: Picture) -> List[XYCoordinates]: Can be made bet
by pitay 6y ago
Your original function definition here:
def find_xy_coordinate_of_dogs_cats_and_baboons_in_picture(picture: Picture) -> List[XYCoordinates]:
Can be made better by turning it into this:
def find_dogs_cats_and_baboons(picture: Picture) -> List[XYCoord]:
Reasoning:
'xy_coordinate_of_' taken out because XY coordinates are already in the return type. '_in_picture' taken out because the information is already in the 'picture: Picture' parameter. The return type 'List[XYCoordinates]' changed to 'List[XYCoord]' because Coord is well known as an abbreviation for a coordinate and having XY in front of it makes it completely obvious. Removed the 's' from the end of the return type because it is already contained in a list and shouldn't be pluralised. It would be pluralised if you are returning a list of lists of coordinates.
There are problems with having huge function names, especially if other programmers need to use the functions you write in their code. One is the amount of screen space needed to use your function, this bites when the could be many functions with long names used in a single expression, long names can be harder to understand in that context. There are reasons that mathematical operators in programming languages are usually one character, things like '+ * - /', it should be obvious the problems people writing in that language would have if the operator names were replaced with things like 'multiply'. Now imagine mathematics being written in a verbose English style, it is not done this way because of all the extra effort it would take to write it, and all the extra effort it would take to understand it.
- Geminidog 6y agoThe other part of my argument is that your refactoring didn't really do anything. Think about it. Making it shorter did absolutely nothing other then save some precious microseconds during reading. Another thing I would argue is that my version of the function saves time. You got rid of xy from the name so now this can only be derived from a type signature definition. If someone encounters this function being called in the wild they will have to follow it in order to derive the xy nature of the return value. But that point is irrelevant in the grander scheme of things. My main point is that the differences between either naming convention has basically no logical significance at all. A better way to illustrate it: find_xy_coordinate_of_dogs_cats_and_baboons_in_picture find_the_xy_coordinates_of_dogs_cats_and_baboons_in_a_picture the extra grammar I added does zero damage to the code or meaning it doesn't hurt. In fact a weird thing occurs when communicating with the English language instead of code. In English we prefer the bottom way, in code we prefer the top. Both are mediums of communication yet we prefer two contradictory approaches. But in general people prefer reading English over code so the English style of verbosity is in fact provably better. I'm saying because of this contradiction, long ass function names aren't actually hurting anyone... while at the same time the extra info helps communicating much more concepts. > One is the amount of screen space needed to use your function, this bites when the could be many functions with long names used in a single expression ............. Others have used the math argument. I'll post my replies to those rather then rewrite everything. https://news.ycombinator.com/item?id=25476030 https://news.ycombinator.com/item?id=25476030 https://news.ycombinator.com/item?id=25476474 https://news.ycombinator.com/item?id=25476474