-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethinking method names for sample/population #2
Comments
Good suggestion, thanks. I would not do it though, here are the reasons:
Thanks for your input. Have a good one! |
👍 |
I just remembered another point that I forgot to bring up. I'm not quite sure your method names fit the naming conventions Apple uses. Personally I'd rename
to
or perhaps
Up to you. |
|
@NathanJang good point about naming, I need to think about it. |
@Schemetrical yes it is a good alternative, thank you. In this particular case I still prefer to keep information of "what the function does" in its name, and not to split it into the function name and parameter name. I described my motivations above. |
|
Now I am rethinking this and I am starting to like it. It does play beautifully with Swift parameters. The name of the parameter, population or sample, actually describes the data we pass into. And the parameter name still remains a part of the function name. Beautiful. |
Yep, and this is basically what Apple is doing while converting UIKit methods to swift with constructors too, doing |
Have you considered using an enum or a boolean instead of 2 separate implementations for some methods?
For instance
public static func variance(values: [Double], type: DataType) -> Double?
withDataType.Sample
or somethingor
public static func variance(values: [Double], isSample: Bool) -> Double?
and checking for it in the implementation instead of copy-pasting 2 very similar implementations.
The text was updated successfully, but these errors were encountered: