4 ms·

Disagree. Particularly since named arguments are part of the function name and in languages where you use named arguments you will often have very expressive ov

Disagree. Particularly since named arguments are part of the function name and in languages where you use named arguments you will often have very expressive overloaded function names. You might have 3 related functions like so: getStudent(datastore: DS, byId: number) getStudent(datastore: DS, byAssessmentId: number) getStudent(datastore: DS, firstName: string, lastName: string, birthdate: date) Without named parameters, you are stuck with function names like: getStudentById, or relying on convention for naming parameters and often wind up with duplicate names or not knowing if a function is out there because your idea of naming is different from someone else's. Intellisense picks this up too and suggests the 3 different names. Works fantastic.

kingdomcome50 6y ago
I'm honestly curious what you see as the issue with "getStudentBy"-type function names. Could you expand on that? Of course I understand a name could become rather verbose in your last case, but I'm not satisfied that it would be much of an issue in practice.
- ogre_codes 6y ago
  See above.
  - kingdomcome50 6y ago
    Hmmm... I see where you are going there, but I don't understand how named arguments solve the problem[0] you have outlined. That is, a problem of discoverability. Like what, precisely, does the autocomplete show in your editor when you type `getStudent` vs `getStudentBy` that makes the former so much better? In either case you are left to disambiguate either the correct overload or the correct method unless... well... you already know there is an overload that accepts the data you happen to be working with. Presumably you would also then know the correct method name. I suppose it's possible to start typing your named parameters directly and the editor "fills in" name you are going for? But that poses nearly the same problem again: "Wait... is it 'nationality' or 'country'? Did we decide on 'lastname' or 'surname'?" I agree the `getStudentByCountryAndName` isn't a great signature, and that wrapping all of the args into a single DTO like `StudentInfo` is not so great either. But I can honestly say, I have never once run into a problem of finding a method in the wild! Even if we had numerous `getStudentBy`-type functions all with similar signatures/names it probably wouldn't take more than a few seconds to narrow down to the one of interest. I also find, from a consumer perspective, named-parameters to be less ergonomic. I like that when I type `getStudentById(` my editor boldens the argument I am meant to pass next. I don't have to decide which parameter I am going to pass next... my editor just walks me through the function (maybe I'm just lazy!) To be clear, I am not arguing against named-parameters. Though I dislike that they broaden the public surface of functions, I suppose I would rather at least have the option to use them than not at all. I just don't really see, in a practical sense, how they would improve a code-base beyond some fairly niche scenarios that are probably a code smell anyway. [0] It seems to me your argument is more aimed towards overloading than named-parameters in particular, but I will accept that there is significant overlap in this space.
    - ogre_codes 6y ago
      I think a better question is: Why would you want a function that gets students to be called anything other than `getStudent`? Fundamentally, the simpler, easier to parse your function name is, the more readable and editable your code is. I definitely think overloading functions is more interesting/ important than named parameters. But named parameters are useful both for overloaded functions and for optional parameters where you might not know what the 3rd/ 4th parameter might be. One pattern I see frequently in languages which lack named parameters is instead of using optional parameters, people pass objects with optional properties. This is used a ton in Javascript/ Typescript. If the language supported proper named & optional parameters, it wouldn't be an issue.
laumars 6y ago
I get overloading is a popular way of writing DRY code but I’ve never been a fan of overloading either. You might dislike getSomethingBySomething style function names but it’s no different to the examples you’ve given in terms of readability but with the bonus of having fewer surprises.
- ogre_codes 6y ago
  Should I look for the function called: `getStudentByClassRoomFirstNameLastName` or is it `getStudentByClassRoomLastNameFirstName`, or `getStudentByClassRoomFullName` since you sort that way. They you have to deal with optional parameters, do you have an extra argument for that or is there a `getStudentByClassRoomFirstNameLastNameMiddleName` function out there? Now you are scanning the auto-complete code trying to figure out which function you need to call. If you have named parameters, this just works: `getStudent(classRoom: 15, firstName: "Mary", lastName: "Jane")` `getStudent(classRoom: 15, firstName: "Mary", lastName: "Jane", middle: "Anne")` It can call the same function with optional parameters, or 2 different functions and you don't care from the calling side because the syntax is the same and always makes sense. (slight tangent) Far better with overloading in general is being able to have 2 methods with the same name which return the same thing but have different types of inputs. Like in Elixir, you can have an API callback be `handle(apiResult)`, then have 2 functions, one which handles the error and one which handles the success. Zero logic written to filter out bad-calls, it's just the same method with different types (the Error result type and the Success result type). Vastly simplifies and cleans up that kind of code.
  - dmitriid 6y ago
    Even better is Elixir's Ecto or Linq Students |> Students.Repo.get_by(first_name: "Ryan") from s in Students where firstName = "X" select s Students.AsEnumerable().Select(s => s).Where(s => s.Name == "X") etc.
    - ogre_codes 6y ago
      Elixir is what I was thinking of for much of the above, unfortunately, I only used it fairly briefly and so I was going largely on memory and some of that is likely more Swift than Elixir which shares some of that. I really loved using Elixir, very frustrating going back to TypeScript after that.

kingdomcome50 6y ago

I'm honestly curious what you see as the issue with "getStudentBy"-type function names. Could you expand on that? Of course I understand a name could become rather verbose in your last case, but I'm not satisfied that it would be much of an issue in practice.

ogre_codes 6y ago
See above.
- kingdomcome50 6y ago
  Hmmm... I see where you are going there, but I don't understand how named arguments solve the problem[0] you have outlined. That is, a problem of discoverability. Like what, precisely, does the autocomplete show in your editor when you type `getStudent` vs `getStudentBy` that makes the former so much better? In either case you are left to disambiguate either the correct overload or the correct method unless... well... you already know there is an overload that accepts the data you happen to be working with. Presumably you would also then know the correct method name. I suppose it's possible to start typing your named parameters directly and the editor "fills in" name you are going for? But that poses nearly the same problem again: "Wait... is it 'nationality' or 'country'? Did we decide on 'lastname' or 'surname'?" I agree the `getStudentByCountryAndName` isn't a great signature, and that wrapping all of the args into a single DTO like `StudentInfo` is not so great either. But I can honestly say, I have never once run into a problem of finding a method in the wild! Even if we had numerous `getStudentBy`-type functions all with similar signatures/names it probably wouldn't take more than a few seconds to narrow down to the one of interest. I also find, from a consumer perspective, named-parameters to be less ergonomic. I like that when I type `getStudentById(` my editor boldens the argument I am meant to pass next. I don't have to decide which parameter I am going to pass next... my editor just walks me through the function (maybe I'm just lazy!) To be clear, I am not arguing against named-parameters. Though I dislike that they broaden the public surface of functions, I suppose I would rather at least have the option to use them than not at all. I just don't really see, in a practical sense, how they would improve a code-base beyond some fairly niche scenarios that are probably a code smell anyway. [0] It seems to me your argument is more aimed towards overloading than named-parameters in particular, but I will accept that there is significant overlap in this space.
  - ogre_codes 6y ago
    I think a better question is: Why would you want a function that gets students to be called anything other than `getStudent`? Fundamentally, the simpler, easier to parse your function name is, the more readable and editable your code is. I definitely think overloading functions is more interesting/ important than named parameters. But named parameters are useful both for overloaded functions and for optional parameters where you might not know what the 3rd/ 4th parameter might be. One pattern I see frequently in languages which lack named parameters is instead of using optional parameters, people pass objects with optional properties. This is used a ton in Javascript/ Typescript. If the language supported proper named & optional parameters, it wouldn't be an issue.

laumars 6y ago

I get overloading is a popular way of writing DRY code but I’ve never been a fan of overloading either. You might dislike getSomethingBySomething style function names but it’s no different to the examples you’ve given in terms of readability but with the bonus of having fewer surprises.

ogre_codes 6y ago
Should I look for the function called: `getStudentByClassRoomFirstNameLastName` or is it `getStudentByClassRoomLastNameFirstName`, or `getStudentByClassRoomFullName` since you sort that way. They you have to deal with optional parameters, do you have an extra argument for that or is there a `getStudentByClassRoomFirstNameLastNameMiddleName` function out there? Now you are scanning the auto-complete code trying to figure out which function you need to call. If you have named parameters, this just works: `getStudent(classRoom: 15, firstName: "Mary", lastName: "Jane")` `getStudent(classRoom: 15, firstName: "Mary", lastName: "Jane", middle: "Anne")` It can call the same function with optional parameters, or 2 different functions and you don't care from the calling side because the syntax is the same and always makes sense. (slight tangent) Far better with overloading in general is being able to have 2 methods with the same name which return the same thing but have different types of inputs. Like in Elixir, you can have an API callback be `handle(apiResult)`, then have 2 functions, one which handles the error and one which handles the success. Zero logic written to filter out bad-calls, it's just the same method with different types (the Error result type and the Success result type). Vastly simplifies and cleans up that kind of code.
- dmitriid 6y ago
  Even better is Elixir's Ecto or Linq Students |> Students.Repo.get_by(first_name: "Ryan") from s in Students where firstName = "X" select s Students.AsEnumerable().Select(s => s).Where(s => s.Name == "X") etc.
  - ogre_codes 6y ago
    Elixir is what I was thinking of for much of the above, unfortunately, I only used it fairly briefly and so I was going largely on memory and some of that is likely more Swift than Elixir which shares some of that. I really loved using Elixir, very frustrating going back to TypeScript after that.