You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+5-2Lines changed: 5 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -272,11 +272,14 @@ Erlang syntax is horrible amirite? So you might as well make the best of it, rig
272
272
273
273
***
274
274
##### 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.
276
276
277
277
*Examples*: [state](src/state)
278
278
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.
0 commit comments