Usage of parenthesis in `spec`

Questions / Help
1

Background

I few days ago I was checking some code from a co-worker and I was drawn to his usage of spec:

@spec hello(String.t(), String.t(), integer(), map()) :: any()
#function code here ....

We came together and he asked me why my usage of specs was different (I don’t use parenthesis):

# No parenthesis
@spec hello(String.t, String.t, integer, map) :: any

To which I responded:

"Well, the compiler will realize this is a function and will expand it automatically. So in reality, adding the extra parenthesis everywhere just adds more noise to your code without any real value and for functions with many arguments it makes the code harder to read. Also, since I am using the 80 characters per column limit, I find it that doing it this way is more compact while still delivering me the same amount of information. "

To which he replied:

Yeah but … in the official docs they use parenthesis everywhere. Why do they do it then?

Weerrmmmm… I have no idea.

Questions

  1. Do you use parenthesis in your spec calls?
  2. If so, why? (or why not?)
  3. Why does the documentation uses parenthesis every where?
  4. Are there any tangible benefits to using the parenthesis?
  5. What is the community standard on this matter ?
4 Likes
2

I use them in my @specs for the very same reason I use them for zero-arity functions in my code. It removes ambiguity.

If the parens are missing, I’ve always to check whether or not there is a when that describes the item.

2 Likes
3

I noticed that the mix format task will add parentheses for all the Module.type() types like String.t() or GenServer.server(), but does not for basic types like map or integer. So I tent to use the same convention in my code, but I don’t really know the reason. Possibly just consistency with the format of function calls, where the formatter also prefers elems |> Enum.join() to elems |> Enum.join to disambiguate between functions and special forms?

Functionally they should be the same.

5 Likes