[erlang-questions] erlang sucks

Anders Dahlin anders@REDACTED
Wed Apr 2 00:21:56 CEST 2008


The attached will help identifying those "bugs". The majority of the 
code is about a decade old. During the years I've only added new 
expressions as I have happened to use them. It may not cover all the 
additions, but using the verbose flag will tell if it ignores an 
expression.

Usage:
seqvar:check().
seqvar:check(DoFs).
seqvar:check(Options).
seqvar:check(DoFs, Options).

Where:
DoFs = Directory or File | List of Directories and/or Files

Options = [Option]

Option =
recurse - seqvar will recurse through sub directories.
verbose - seqvar will report if it ignores any expressions.
{incl, Fun()} - Include a file only if Fun(File) = true.
{excl, Fun()} - Exclude a file if Fun(File) = true.
{incldir, Fun()} - Include a directory only if Fun(Dir) = true.
{excldir, Fun()} - Exclude a directory if Fun(Dir) = true.
{inclvar, Fun()} - Include a variable only if Fun(Var) = true. Var is an 
atom.
{exclvar, Fun()} - Exclude a variable if Fun(Var) = true. Var is an atom.

If DoFs is omitted, the current directory will be used.


Examples:

  4> seqvar:check("foo.erl", [verbose]).
Checking file "foo.erl"
Line 25: Usage of 'T2', expected 'T4'
Line 32: Usage of 'B1', expected 'B3'
Line 46: Usage of 'Foo1', expected 'Foo2'
Line 47: Usage of 'Baz1', expected 'Baz2'


%% Exclude all variables starting with T
5> F = fun (V) -> case atom_to_list(V) of "T" ++ _ -> true; _ -> false 
end end.

6> seqvar:check("foo.erl", [{exclvar, F}, verbose]).
Checking file "foo.erl"
Line 32: Usage of 'B1', expected 'B3'
Line 46: Usage of 'Foo1', expected 'Foo2'
Line 47: Usage of 'Baz1', expected 'Baz2'


Happy checking - no warranties!
/Anders


attila.rajmund.nohl@REDACTED wrote:
> On Mon, 17 Mar 2008, Kevin Scaldeferri wrote:
> 
>> On Mar 17, 2008, at 6:31 AM, Jani Hakala wrote:
>>
>>> attila.rajmund.nohl@REDACTED writes:
>>>
>>>> I don't think that immutable variables make it easier to write less
>>>> buggier code. On the contrary, I often see code like this:
>>>>
>>>> HR1=f(HugeRecord),
>>>> ...
>>>> g(HR1).
>>>>
>>>> Then someone adds a line to modify the HugeRecord and forgets to
>>>> update
>>>> the call to 'g':
>>>>
>>>> HR1=f(HugeRecord),
>>>> HR2=f2(HR1),
>>>> ...
>>>> g(HR1).
>>>>
>>>> Now we have a stupid bug.
>>>>
>>> The compiler would warn about that
>>>    Warning: variable 'HR2' is unused
>> These examples always feel like people are insisting on writing
>> imperative code in a functional language.  Why not:
>>
>> HR1 = f2(f(HugeRecord)),
>> ...
>> g(HR1)
> 
> Because this is a mock-example, the real code looks more like
> 
> HR1=HugeRecord#hugeRecordType{someField=SomeValue}
> ... code uses HR1
> HR2=HR1#hugeRecordType{someOtherField=SomeOtherValue}
> ... 
> g(HR1), % forgot to update variable name
> h(HR2). % didn't forget to update variable name
> 
> In this case the compiler won't save my a**. I see this kind of code
> change all the time. Every week I see a checkin which only fixes a
> variable name that wasn't updated, so this is not exactly a rare bug.
> 
>  				Bye,NAR
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: seqvar.erl
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080402/bf265276/attachment.ksh>


More information about the erlang-questions mailing list