Monad naming conventions

What is considered (as close to) standard convention for monadic variables?

e.g. would you expect a variable of type Either[User] to be named val user or val maybeUser or something else?

By extension would you just pick a logical prefix for the given wrapper? I am leaning toward maybeUser but when there are many consecutive variables like this I do think it starts to look messy.

I’m not aware of an authoritative convention. I’d just use the simple name, i.e. user. It usually should be clear what context is in effect - type prefixes/suffixes would just smell like (Systems) Hungarian notation to me. (And I certainly wouldn’t call an Either a “maybe”. :wink: )

The only exception is when I’m using a “wrapped” and “unwrapped” variable in the same method, e.g.

val userOpt = ???
userOpt.fold(???){ user => ??? }
3 Likes

In general, I would avoid having variables rather I would try to have methods and chain the calls; that way I can use the plain name inside the lambdas. Since is not always possible to not have intermediate variables, in those cases I would add a postfix of the effect if the name would be reused as shown by @sangamon
Something like:

def getData(key: String): IO[List[Data]] =
  getFileFromKey(key).flatMap { path =>
    getLines(readFile(path)).evalMap { line =>
      val result = line.split(',').toList match {
        case fooRaw :: barRaw :: Nil =>
          (parseFoo(fooRaw), parseBar(barRaw)).parMapN((foo, bar) => Data(foo, bar))

        case Nil =>
          Left(...)
      }

      IO.fromEither(result)
    }.compile.toList
  }

However, this is just my taste, not a standard.

1 Like

I do find that having a naming convention to disambiguate optional vs value-typed vars is a good thing. I have personally adopted using a “?" suffix for optional values. I also use "fut” for futures. So a future of optional would be “fut_xyz_?”.

Brian Maso

Yeah, I often (but inconsistently) use the Opt suffix, and sometimes a Fut suffix, if and only if it seems to help readability.