Variables name convention

Hi all

I have following function definition:

  def request(:get, bUri, bUser, bPassword, mHttpHeaders \\ %{}) when is_binary(bUri)
                                                                 and is_binary(bUser)
                                                                 and is_binary(bPassword)
    lAuth = [basic_auth: {bUser, bPassword}]
    mHeaders = Map.merge(mHttpHeaders, %{"Accept" => "application/json"})
    {:ok, %HTTPoison.Response{status_code: 200, headers: bHeaders, body: bBody}} = HTTPoison.get(bUri, mHeaders, [hackney: lAuth])
    [bHeaders: bHeaders, body: bBody]

as you can see, I name the parameters as follow:

bUri, bUser, bPassword, mHttpHeaders

b stays for binary and m for map.

I want to know, how do you find the name convention mentioned above. In my opinion, it is more clear, which datatype I have to pass to the function.


It’s not bad, but could be more explicit.
Citing Zen of Python here: Explicit is better than implicit

In this case, if I was a new developer who was just assigned to continue the work you left behind, I would have to go through git logs and/or contact you in order to understand what b or m stands for.
That in the case when you haven’t put a nice @doc.

Say that I am that new developer I mentioned above, you just explained me that b and m stands for, but what does lAuth mean?
“Is it a typo? Maybe he meant kAuth?”, that’s what I would ask myself.
It’s quite confussing.

I like to be as explicit as possible, this is most likely because I’ve been an avid Python lover before switching to Elixir, so in this case I would use binaryUri instead of bUri and mapHttpHeaders instead of mHttpHeaders.

It might seem a bit excessive but it might also help you in the long run, when you come back to the project months after not working on it or, as I’ve already mentioned, passing the project to somebody else.

lAuth, l stays for list.

Why it is excessive? For example, I would give the project to someone else and the developer would see clearly, which type does the function parameter expect.

I do not like this kind of notation, what will you use as prefix when you accept a struct? Is it m because it’s a map beneath or is it special to that kind of struct?

Also when you have a function which accepts a string or a charlist?

We had to use these kind of notation during Pascal lectures and to be honest, the pre fixing rule made it harder to use some types because we had to look up that prefix to use first from the courses rules, while at the same time auto completion was unusable because we had to remember at least type and prefix before we were able to type and ask the completion for the full name.

As a conclusion I think this is a burden rather than help because of the things mentioned above and prefer to name things after what they are.

1 Like

That’s what @spec is for.

1 Like

Whether you like Hungarian Notation or not (there can be arguments made for its proper use), variable naming convention in Elixir is that you use snake_case, so your example would be:

def request(:get, b_uri, b_user, b_password, m_http_headers \\ %{}) ...

With a simple typespec, and avoiding to re-state that information in the variable names, it could look like this instead:

@spec request(:get, String.t, String.t, String.t, %{optional(any) => any}) :: list
def request(:get, uri, user, password, http_headers \\ %{}) ...

Now it can also be properly checked by Dialyzer (via Dialyxir for example).

A more involved use of typespecs would be to define your own types, be more specific with allowed map / list contents, etc… maybe something like this:

@type uri :: String.t
@type user :: String.t
@type password :: String.t
@type http_headers :: %{optional(String.t) => String.t)
@type response :: [headers: http_headers, body: String.t]

# ... more code that uses the types we defined ...

@spec request(:get, uri, user, password, http_headers) :: response
def request(:get, uri, user, password, http_headers \\ %{}) ...

Ok guys, you have convinced me. I will change it.


@jwarlander give you really good response.
I want to add one more link to @lexmag Elixir Style Guide that you should also know. There are many rules that could be helpful in styling code. There is for example rule about snake_case naming that @jwarlander explains.
Another good tip for you may be also use credo.