4 ms·

The argument is that at some point the length of the name is detrimental to readability, in the same way that a run-on sentence is detrimental to the readabilit

by throwaway201103 6y ago

The argument is that at some point the length of the name is detrimental to readability, in the same way that a run-on sentence is detrimental to the readability of prose. I thought it was quite clear and your 16 paragraph response didn't touch on that at all. Or if you did, it was lost in the noise.

Geminidog 6y ago
Oh I thought it was obvious that you don't want to rename a function after a 300 word paragraph. I didn't realize we need to get into that kind of semantics. My argument is that a sentence long function name of 10 words roughly is still a good function name. There's no hard rule here. Judgement is still qualitative The main point that I was arguing for is that this: find_xy_coordinate_of_dogs_cats_and_baboons_in_picture is a perfectly good function name. The poster I responded to disagrees with me and I was responding to that specifically.
- 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 ago
    The 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

Geminidog 6y ago

Oh I thought it was obvious that you don't want to rename a function after a 300 word paragraph. I didn't realize we need to get into that kind of semantics. My argument is that a sentence long function name of 10 words roughly is still a good function name. There's no hard rule here. Judgement is still qualitative The main point that I was arguing for is that this: find_xy_coordinate_of_dogs_cats_and_baboons_in_picture is a perfectly good function name. The poster I responded to disagrees with me and I was responding to that specifically.

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 ago
  The 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