[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