Skip to content

Commit 8d98719

Browse files
author
Brujo Benavides
committed
Upgrade rule for named states
1 parent bffab69 commit 8d98719

File tree

2 files changed

+10
-7
lines changed

2 files changed

+10
-7
lines changed

README.md

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -272,11 +272,14 @@ Erlang syntax is horrible amirite? So you might as well make the best of it, rig
272272

273273
***
274274
##### Explicit state should be explicitly named
275-
> Name your state records ``#state`` and use ``-type state():: #state{}`` in all your OTP modules.
275+
> Name your state records ``#mod_state`` and use ``-type state():: #mod_state{}`` in all your modules that implement OTP behaviors.
276276
277277
*Examples*: [state](src/state)
278278

279-
*Reasoning*: OTP behaviours implementations usually require a state, and if it always have the same name it makes it more clearly recognizable. Defining a type for it, helps _dialyzer_ detect leaks (where an internal type as the state is used outside of the module).
279+
*Reasoning*: OTP behaviours implementations usually require a state, and if it has a recognizable name it makes it more easily identifiable. Defining a type for it, helps _dialyzer_ detect leaks (where an internal type as the state is used outside of the module).
280+
The usage of the module prefix in the record name has the goal of distinguishing different state tuples while debugging: Since records are just tuples when one is dumped into the shell it is easier to read `{good_state, att1, attr2}` than `{state, attr1, attr2, attr3}` or `{state, attr1, att2}`.
281+
At a glance you know that the tuple/record can be found in the `good.erl`module.
282+
280283

281284
***
282285
##### Don't use _Ignored variables

src/state/good.erl

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -6,9 +6,9 @@
66
-export([init/1, terminate/2, code_change/3,
77
handle_call/3, handle_cast/2, handle_info/2]).
88

9-
-record(state, {value :: pos_integer()}).
9+
-record(good_state, {value :: pos_integer()}).
1010

11-
-type state() :: #state{}.
11+
-type state() :: #good_state{}.
1212

1313
-spec start(pos_integer()) -> {ok, pid()}.
1414
start(InitialValue) ->
@@ -22,16 +22,16 @@ increment() -> gen_server:cast(?MODULE, increment).
2222

2323

2424
-spec init(pos_integer()) -> {'ok', state()}.
25-
init(InitialValue) -> {ok, #state{value = InitialValue}}.
25+
init(InitialValue) -> {ok, #good_state{value = InitialValue}}.
2626

2727
-spec handle_call(retrieve, {pid(), term()}, state()) ->
2828
{'reply', pos_integer(), state()}.
2929
handle_call(retrieve, _From, State) ->
30-
{reply, State#state.value, State}.
30+
{reply, State#good_state.value, State}.
3131

3232
-spec handle_cast(increment, state()) -> {'noreply', state()}.
3333
handle_cast(increment, State) ->
34-
{noreply, State#state{value = State#state.value + 1}}.
34+
{noreply, State#good_state{value = State#good_state.value + 1}}.
3535

3636
-spec handle_info(any(), state()) -> {'noreply', state()}.
3737
handle_info(_Msg, State) -> {noreply, State}.

0 commit comments

Comments
 (0)