Dry parameter names

How often do you see code like this, especially when using dependency injection, single-responsibility principle, and other “good practices”?

class FriendsTimelineReader(userFinder: UserFinder,
   userStatusReader: UserStatusReader,
   statusSecurityFilter: StatusSecurityFilter) {

Note that the parameter names are exact copies of the class name. That’s certainly not DRY!

In Java writing such code is a bit easier than in Scala, since you write the type first, and then the variable name can be auto-completed (the fact that there’s an auto-complete in IDEs indicates that it’s a common pattern). In Scala there’s more typing, but then, less boilerplate around declaring fields/defining a constructor/assigning to fields.

How to avoid that? We can always use cryptic variable names, like “ssf” instead of “statusSecurityFilter“. But then the whole effort of having nicely named classes to make the code readable, which is quite a hard task, goes to waste.

Of course, variable names are very useful, for example when we have to distinguish between the 10 String parameters that our method takes, create an Int counter, etc. But the more we use specialised wrapper-types (and now possibly even more, with Scala 2.10 introducing value classes) to make our code more type-safe, the more fine-grained our services – the more often the variable/parameter names will mirror the class name.

Even when there are a couple of instances of a class, often the parameter name contains some qualifier + the class name (e.g. given a Person class, personAssociator.createFriends(firstPerson, secondPerson)). It would be interesting to see some statistics on how often variable name is a mirror of the class name or a suffix – I suspect it can be a large percentage.

Maybe the next step then in type safety is limiting the complete freedom when naming parameters? Or even, getting rid of the parameter names at all in some cases.

For example. In the snippet from the beginning, we just want to get “an instance” of a UserFinder. Most probably there will ever be only one instance of this class in the system, and certainly one will be used at a time by other classes. So why not let the class express that it wants an instance of a class, without having to name it? Let’s use the indefinite article “a” as a keyword (we don’t really care which instance is passed):

class FriendsTimelineReader(a UserFinder,
  a UserStatusReader,
  a StatusSecurityFilter)

Now, how would you use such a variable inside a class? Let’s use the definite article “the” – the instance that was given to the class, for example:

val user10 = (the UserFinder).findById(10)

Maybe this looks a bit like science-fiction, but wouldn’t it be convenient? Or maybe this problem is already solved by some mechanisms in other languages?


EDIT 27/01/2013: Extending the above to handle qualifiers:

class Friends(a 'first Person, a 'second Person) {
   (the 'first Person).getName()
  • But this isn’t DRY anyhow, you must repeat class name to know what you’re referencing to ;-)

  • Well, eliminating that would lead us to (the class I’m thinking about).doWork() ;)
    Anyway, it’s drier, one repetition less.

  • Well… this CAN already be done even with scala 2.9.x, though I’m not convinced it this isn’t too crazy… Would have to think about it, and about the compile time (?) implications.

    Here’s a quick demo to show how this can be implemented: https://gist.github.com/4645350

  • A good comment here would be: “I’m excited… yet at the same time, terrified by this creature I have written”. ;-)

  • Ah implicits – works of course, though not exactly what I meant ;-).
    The syntax is a “bit” verbose. Though you could define the to work as implicitly (getting the[UserFinder]), implicit is a keyword and would be rather hard to get shortened.

  • See my edit (bottom of the post) on how to support qualifiers. Doesn’t it read nicely? ;)

  • If you’d end up using qualifiers it’s just as repeating as using a well-names variable but carries less meaning with it IMHO. The case without qualifiers seems “easier to swallow”.

    This calls for an entirely different paradigm – separate functions from classes entirely? (Thinking golang again, but haven’t implemented “bigger” things in it yet).

    Other ideas… simply Traits? The “Reader” in this example would implement all dependencies (auth config etc), mix in the *finder etc and be done with it hm.

  • Well, I think the version with qualifiers carries more meaning.
    Compare (the difference would be bigger of course if the class name is longer):
    (a "first" Person) with firstPerson: Person
    The former is more structured:

    • a – we want any instance
    • “first” – arbitrary description
    • Person – of class Person

    I don’t understand the traits comment, can you give an example?


  • @Traits – since the goal is to repeat less of the “blablaFinder.“, the easiest way out is “just traits”, like bellow:

    class A(/*common dependencies*/) extends B with C { // implements dependencies of B and C
    //calls stuffFromC(), no prefix

    Although this raises questions about SRP etc.

    Coming back to the idea of abandoning classes (like go), here’s a paper I’ve read some time ago about “Organizing Programs Without Classes” http://cs.au.dk/~hosc/local/LaSC-4-3-pp223-242.pdf Although the focus of the paper is slightly different it – it’s pretty interesting in itself and gets you thinking :-) Examples are in the self language (imagine like-js). Anyways, there’s a lot of room for experimentation here :-)

    Disclaimer: I have not yet written much in self or go, to feel if it’s a good idea or not – just thinking out loud :-)

  • @Konrad, but then you end up with all methods in one big namespace, which makes it either hard to read, or makes you have to prefix the method names with some context – which essentialy boils down to removing the dot from the invocation ;)

    I’ll take a look at the paper, thanks.

  • Insane and intriguing.

  • Caesar Ralf Franz Hoppen

    It’s a cool idea. This would help in refactoring, where you find a better name for the class you created.

    Another cool stuff is that this kind of naming helps you see if your class doesn’t have more responsabilities than it should, because reading something like ‘the UserDao.doSomeCalculation’ feels strange.

  • Pingback: Don’t repeat yourself | Frank Börncke's <Weblog/>()

  • Very interesting reflections… I have also thought about this myself a couple of times… A possible solution would be to use some kind of (overridable) convention.

    For example:

    class FriendsTimelineReader('userFinder, 'userStatusReader, 'statusSecurityFilter)

    (Or replace the ‘ with some other funky symbol, or remove it – TBD)

    This would mean that the variable name is of the same type as the capitalized camel-case class. It would expand to the original:

    class FriendsTimelineReader(userFinder: UserFinder,
    userStatusReader: UserStatusReader,
    statusSecurityFilter: StatusSecurityFilter)

  • Sure, you could either infer the class name from the parameter name or the other way round. If the inference goes from the parameter names, then it would be easier to make qualifiers (but maybe that’s too magical)

  • Johnicholas

    There’s such a thing as type inference – you write an expression, but don’t annotate it with its type, and the compiler figures out what type the expression is. There obviously should be such a thing as code inference, where you say “figure out what expression goes here, given that it has type Foo”, and the compiler figures it out.

  • Tom Palmer

    I’ve one-upped this in my own language plans (if I ever get it done
    someday without changing plans first). I keep type names syntactically
    separate from variable names so they can both have the same name, and if
    the type is unspecified and not inferrable by initialization, then it
    is assumed that the variable name is also the type name (so no need for
    the “a” and “the” as here). I’m not sure how it would work out in the
    end, but that’s been my current plan anyway.

  • Michael Fairhurst

    Check out the programming language Wake. It has this built in from day one, but with even less typing. Wakelang.com