New `erl_files_strict` (+hrl +beam) rule: `{elvis_style, no_process_dict_usage}`

[paulo-ferraz-oliveira]

Name

no_process_dict_usage

Brief Description

Use of Erlang’s process dictionary should be avoided.

Problematic code

put(Key, Value)

...

get(Key)

Correct code

Here is an alternative that uses the process state, too, but in a more explicit manner.

gen_server:cast(self(), {update_pd, {Key, Value}})

Rationale

Updating the process dictionary isn't, by itself, a bad practice, but it should nonetheless be used with care. This rule will warn you to make a decision on whether your implementation could be reworked or not.

Some problems occurring from using the process dictionary:

• Hidden State
• Hard to Test
• Poor Traceability
• Breaks Functional Paradigm
• Concurrency Hazards
• ...

[elbrujohalcon]

@paulo-ferraz-oliveira can this be achieved by adding these functions to the no_call options?
🤔
I wonder if the problem there is that no_call doesn't catch not-fully-qualified calls… and this shouldn't be turned into a bug in that regard.
If I add {erlang, get, 1}, {erlang, put, 2} to my no_call's configuration, I would expect it to emit a warning on put(key, value) and get(key).

Which makes this ticket related to #430