[GuB-42]

> find_xy_coordinate_of_dogs_cats_and_baboons_in_picture(picture: Picture) -> List[XYCoordinates]

It is redundant. It doesn't need the "xy_coordinate" because that is the return type. Furthermore it is wrong, it should be "xy_coordinates", with an "s". Or it shouldn't return a list.

The "in_picture" part is also redundant, it takes a Picture argument so why mention it?

Note: these arguments depend on whether you language supports polymorphism or not. In C for instance, you often have no choice.

The "dogs_cats_and_baboons" part is fine as long as it really is what you are looking for. If your intent is to find any animal and you implementation only finds dogs cats and baboons now, then you should call it "animals" with maybe a comment clarifying that point.

The problem with long fonction names is that they produce long lines. Long lines are terrible. Not as bad as they used to, thanks to large, wide screens but still, I hate having my editor window unnecessary large or have a horizontal scroll bar.

[minot]

I think the point is that you should use Longer names where possible.

Powershell’s Set-Location is better than shell’s cd.

Invoke-Webrequest is better than curl.

npm install —-global is better than npm i -g.

There was a need for names to be short forty years ago. We don’t have that anymore.

You might know that you’re dealing with x, y coordinates but how do I know there is no z?

Senior developers tell me to fix the problem in the correct spot. We can have aliases but the default should be long names.