[erlang-questions] Feedback for my first non-trivial Erlang program
zxq9
zxq9@REDACTED
Tue Dec 15 10:22:25 CET 2015
On 2015年12月15日 火曜日 11:03:05 Dmitry Kolesnikov wrote:
> Hello,
>
> One quick suggestion to get rid of `case`
>
> -define(workingTimeUnits, 60).
> -define(is_working(X, Y), X < Y).
>
> investement(T)
> when ?is_working(T, ?workingTimeUnits) ->
> salary(T) - expenses(T) - transactionFee();
>
> investement(T) ->
> -expenses(T) - tax(expenses(T),T) - transactionFee().
>
>
> I think function level guards improves readability. However, you might implement independent “path” to calculate meetings for working and non-working human beans.
>
What is the advantage of that over this:
-define(?working_time_units, 60).
investment(T) when T < ?working_time_units ->
% blahblah.
??? That sort of frivolous macroization drives me nuts. I totally agree with getting rid of case statements, but there are better ways -- and macroizing guards that rely on more macros is not it.
That said, considering how investment is actually written, I think the case may be the lesser of two evils in terms of readability and multiply-calling the same function:
investments(T) ->
Expenses = expenses(T),
case T < ?working_time_units of
true -> salary(T) - Expenses - transaction_fee();
false -> -Expenses - tax(Expenses, T) - transaction_fee()
end.
or
investment(T) when T < ?working_time_units ->
salary(T) - expenses(T) - transaction_fee();
investment(T) ->
Expenses = expenses(T),
-Expenses - tax(Expenses, T) - transaction_fee().
I actually think the first version reads slightly better (juuust barely, if only that Expenses is a fixed symbol throughout now), but the second will be easier to glance at a trace and know exactly what is going on.
-Craig
More information about the erlang-questions
mailing list