3 ms·

I'd be more than annoyed if I saw someone name a function "xxInteger()" because it returns an integer. I don't actually think the first example was that bad, m

I'd be more than annoyed if I saw someone name a function "xxInteger()" because it returns an integer. I don't actually think the first example was that bad, modulo some context. Sometimes even knowing the type for this kind of thing isn't super important to understand what the code is doing; ala opaque types.

Avernar 11y ago
I agree. When the return type changes now you'd have to change every spot it's called regardless if the return value is used or not. This would be very annoying if you don't have a refactor function in your IDE or if the ammount of changes crosses a company policy trigering a full program test taking days of your time, etc. The original function name was named poorly however.
takeawayandrun 11y ago
What exactly is annoying? I always want my variable names to be as long and descriptive as possible. We're no longer in the teletype era and our monitors are huge. With autocomplete there is no reason to keep variable names short
- CamperBob2 11y ago
  Visual clutter bothers some people more than others. It bothers me a lot.
- tomjen3 11y ago
  Thats the only acceptable way to write code, but it doesn't mean that names can't be too expressive, for example I wouldn't accept nameing like this: > RandomizeArrayPositionUsingFisherYatesShuffle Since the algorithm detail is something I don't want to think about when I use it and something that the implementer should be able to change without changing the contract.
egoots 11y ago
I agree. More so in that example where the explicit int return type was used. One can certainly argue that the original function name isn't good enough, but I would hate to see "type names" being appended to functions (reminds me of the old hungarian programming notation for variables).
arcticbull 11y ago
Coming from the Apple ecosystem, descriptive names are par for the course. Most code I end up with is written by autocomplete anyways, so writability is less relevant to me. However, when I go back and read the code later, I want to know as much of the intent of the piece as possible. Apple publishes some very good guidelines for Objective-C and Swift, the latter here: https://swift.org/documentation/api-design-guidelines/ https://swift.org/documentation/api-design-guidelines/ Generally, I'd name this method according to the role of the result, and not it's type. While "xxInteger()" isn't good, "numberOfXX()" returning an integer type does improve readability and would still be understandable assigned into an auto. Remember, you're not writing code for you, you're writing code for future you. Or worse, for the next guy who comes into the codebase. They should be able to derive your intent without having to figure out what each method signature is, and reading all the API docs due to lack of code readability.

Avernar 11y ago

I agree. When the return type changes now you'd have to change every spot it's called regardless if the return value is used or not. This would be very annoying if you don't have a refactor function in your IDE or if the ammount of changes crosses a company policy trigering a full program test taking days of your time, etc. The original function name was named poorly however.

takeawayandrun 11y ago

What exactly is annoying? I always want my variable names to be as long and descriptive as possible. We're no longer in the teletype era and our monitors are huge. With autocomplete there is no reason to keep variable names short

CamperBob2 11y ago
Visual clutter bothers some people more than others. It bothers me a lot.
tomjen3 11y ago
Thats the only acceptable way to write code, but it doesn't mean that names can't be too expressive, for example I wouldn't accept nameing like this: > RandomizeArrayPositionUsingFisherYatesShuffle Since the algorithm detail is something I don't want to think about when I use it and something that the implementer should be able to change without changing the contract.

egoots 11y ago

I agree. More so in that example where the explicit int return type was used. One can certainly argue that the original function name isn't good enough, but I would hate to see "type names" being appended to functions (reminds me of the old hungarian programming notation for variables).

arcticbull 11y ago

Coming from the Apple ecosystem, descriptive names are par for the course. Most code I end up with is written by autocomplete anyways, so writability is less relevant to me. However, when I go back and read the code later, I want to know as much of the intent of the piece as possible. Apple publishes some very good guidelines for Objective-C and Swift, the latter here: https://swift.org/documentation/api-design-guidelines/ https://swift.org/documentation/api-design-guidelines/ Generally, I'd name this method according to the role of the result, and not it's type. While "xxInteger()" isn't good, "numberOfXX()" returning an integer type does improve readability and would still be understandable assigned into an auto. Remember, you're not writing code for you, you're writing code for future you. Or worse, for the next guy who comes into the codebase. They should be able to derive your intent without having to figure out what each method signature is, and reading all the API docs due to lack of code readability.