dialyzer:erlang代码分析器

Erlang是一种“动态”语言，这会带来一个问题，单元测试不足以证明我写的代码是否足够正确。很难发现动态语言类型错用的问题。静态类型语言倒是很容易找到此类错误，但是Erlang是“动态的”。例如，length/1函数只能处理类型为列表（list）的参数，如果传入的不是列表，比如传入一个atom就会出错，但是程序中这样的代码是能够通过编译的，运气好的话会有一个警告，运气差的话只能在运行时发现出错。例如以下代码能成功的编译，也不会有警告，但是显然代码是有问题的，这个问题只能在运行时（foo函数被调用时）才能发现：

bar(List) ->abc.foo() ->V1 = bar([]),io:format("length: ~p~n", [length(V1)]).  %% 这里V1必须是list才行，但是编译时是没法知道的，只有运行时才会发现这个错误

同样的例子，exit/2函数的第一个参数必须是Pid，如果不是也能顺利通过编译，这样只能在运行时才会被发现此外，我自己写的函数，比如bar函数，可能业务逻辑决定了传入的参数必须是list，返回的参数也应该是list，如果不是，那调用者肯定错误的使用了此函数。在动态语言中很难做到对参数类型和返回类型的限制。也就是说，对库的接口的错误理解和错误使用是Erlang这样的动态语言常见问题。为此设计了一套合约语言（contract language），有了合约（contract），dialyzer能够很容易的检测到误用的接口有两种建立合约的方式，一种是在注释里使用@spec这样的annotation，另一种是spec声明
例如规定bar函数只能接收atom或整数，只能返回atom的list：

-type bar_thing() :: atom() | integer().  %% 类型声明：定义bar函数能接收的参数类型-type ret_thing() :: [atom()].  %% 类型声明：定义bar函数的返回类型-spec bar(bar_thing()) -> ret_thing(). %% 函数合约：bar函数的参数和返回值

或者

-spec bar(Arg::atom()|integer()) -> [atom()].

另一种是使用annotation的方式，（注意注释中spec要以点号结束annotation，不然无效）：

%% @spec bar(Arg::atom()|integer()) -> [atom()].

正如注释一样，annotation不会影响编译。不过，违反了合约（contact）依然能顺利编译通过，但是我们现在就可以通过dialyzer工具分析源代码找出所有违反合约的代码
dialyzer --src -c test1.erl 可以一次分析工程中的所有文件
dialyzer --src -I ./include -c *.erl
但是可能会有太多的警告信息了，也可以一个文件一个文件的分析，处理起来容易一点注1：使用dialyzer工具前需要先构建plt：

dialyzer --build_plt -r $OTP_HOME/lib/kernel-2.12.4/ebin/$OTP_HOME/lib/stdlib-1.15.4/ebin/$OTP_HOME/lib/mnesia-4.4.5/ebin （或者其它更多的模块）

这一过程耗时很长（大概5分多钟），成功后会在我的home目录下创建一个叫.dialyzer_plt的文件
注2：有个万能类型any()可以代表任意的数据类型；
注3：可以将多个文件中用到的类型（比如pos()）集中到一个erl文件中（比如m.erl），通过m:pos()使用该类型；或者将该类型集中到头文件hrl中，使用时包含进来。
注4：typer工具可以列出所有声明的合约总结：

可以通过确定某种编程规范以及使用Dialyzer这样的工具分析代码是否正确，克服动态语言的弱点。声明和合约一般不影响编译和运行。所以编译通过不一定代表合约有效，还需要dialyzer工具分析

以下是键入dialyzer --help之后的帮助文档

Usage: dialyzer [--help] [--version] [--shell] [--quiet] [--verbose]
        [-pa dir]* [--plt plt] [--plts plt*] [-Ddefine]*
                [-I include_dir]* [--output_plt file] [-Wwarn]*
                [--src] [--gui | --wx] [files_or_dirs] [-r dirs]
                [--apps applications] [-o outfile]
        [--build_plt] [--add_to_plt] [--remove_from_plt]
        [--check_plt] [--no_check_plt] [--plt_info] [--get_warnings]
                [--no_native] [--fullpath]
Options:
  files_or_dirs (for backwards compatibility also as: -c files_or_dirs)
      Use Dialyzer from the command line to detect defects in the
      specified files or directories containing .erl or .beam files,
      depending on the type of the analysis.
  -r dirs
      Same as the previous but the specified directories are searched
      recursively for subdirectories containing .erl or .beam files in
      them, depending on the type of analysis.
  --apps applications
      Option typically used when building or modifying a plt as in:
        dialyzer --build_plt --apps erts kernel stdlib mnesia ...
      to conveniently refer to library applications corresponding to the
      Erlang/OTP installation. However, the option is general and can also
      be used during analysis in order to refer to Erlang/OTP applications.
      In addition, file or directory names can also be included, as in:
        dialyzer --apps inets ssl ./ebin ../other_lib/ebin/my_module.beam
  -o outfile (or --output outfile)
      When using Dialyzer from the command line, send the analysis
      results to the specified outfile rather than to stdout.
  --raw
      When using Dialyzer from the command line, output the raw analysis
      results (Erlang terms) instead of the formatted result.
      The raw format is easier to post-process (for instance, to filter
      warnings or to output HTML pages).
  --src
      Override the default, which is to analyze BEAM files, and
      analyze starting from Erlang source code instead.
  -Dname (or -Dname=value)
      When analyzing from source, pass the define to Dialyzer. (**)
  -I include_dir
      When analyzing from source, pass the include_dir to Dialyzer. (**)
  -pa dir
      Include dir in the path for Erlang (useful when analyzing files
      that have '-include_lib()' directives).
  --output_plt file
      Store the plt at the specified file after building it.
  --plt plt
      Use the specified plt as the initial plt (if the plt was built
      during setup the files will be checked for consistency).
  --plts plt*
      Merge the specified plts to create the initial plt -- requires
      that the plts are disjoint (i.e., do not have any module
      appearing in more than one plt).
      The plts are created in the usual way:
        dialyzer --build_plt --output_plt plt_1 files_to_include
        ...
        dialyzer --build_plt --output_plt plt_n files_to_include
      and then can be used in either of the following ways:
        dialyzer files_to_analyze --plts plt_1 ... plt_n
      or:
        dialyzer --plts plt_1 ... plt_n -- files_to_analyze
      (Note the -- delimiter in the second case)
  -Wwarn
      A family of options which selectively turn on/off warnings
      (for help on the names of warnings use dialyzer -Whelp).
  --shell
      Do not disable the Erlang shell while running the GUI.
  --version (or -v)
      Print the Dialyzer version and some more information and exit.
  --help (or -h)
      Print this message and exit.
  --quiet (or -q)
      Make Dialyzer a bit more quiet.
  --verbose
      Make Dialyzer a bit more verbose.
  --build_plt
      The analysis starts from an empty plt and creates a new one from the
      files specified with -c and -r. Only works for beam files.
      Use --plt(s) or --output_plt to override the default plt location.
  --add_to_plt
      The plt is extended to also include the files specified with -c and -r.
      Use --plt(s) to specify which plt to start from, and --output_plt to
      specify where to put the plt. Note that the analysis might include
      files from the plt if they depend on the new files.
      This option only works with beam files.
  --remove_from_plt
      The information from the files specified with -c and -r is removed
      from the plt. Note that this may cause a re-analysis of the remaining
      dependent files.
  --check_plt
      Check the plt for consistency and rebuild it if it is not up-to-date.
      Actually, this option is of rare use as it is on by default.
  --no_check_plt (or -n)
      Skip the plt check when running Dialyzer. Useful when working with
      installed plts that never change.
  --plt_info
      Make Dialyzer print information about the plt and then quit. The plt
      can be specified with --plt(s).
  --get_warnings
      Make Dialyzer emit warnings even when manipulating the plt. Warnings
      are only emitted for files that are actually analyzed.
  --dump_callgraph file
      Dump the call graph into the specified file whose format is determined
      by the file name extension. Supported extensions are: raw, dot, and ps.
      If something else is used as file name extension, default format '.raw'
      will be used.
  --no_native (or -nn)
      Bypass the native code compilation of some key files that Dialyzer
      heuristically performs when dialyzing many files; this avoids the
      compilation time but it may result in (much) longer analysis time.
  --fullpath
      Display the full path names of files for which warnings are emitted.
  --gui
      Use the gs-based GUI.
  --wx
      Use the wx-based GUI.

Note:
  * denotes that multiple occurrences of these options are possible.
 ** options -D and -I work both from command-line and in the Dialyzer GUI;
    the syntax of defines and includes is the same as that used by "erlc".

Warning options:
  -Wno_return
     Suppress warnings for functions that will never return a value.
  -Wno_unused
     Suppress warnings for unused functions.
  -Wno_improper_lists
     Suppress warnings for construction of improper lists.
  -Wno_tuple_as_fun
     Suppress warnings for using tuples instead of funs.
  -Wno_fun_app
     Suppress warnings for fun applications that will fail.
  -Wno_match
     Suppress warnings for patterns that are unused or cannot match.
  -Wno_opaque
     Suppress warnings for violations of opaqueness of data types.
  -Wno_behaviours
     Suppress warnings about behaviour callbacks which drift from the published
     recommended interfaces.
  -Wno_undefined_callbacks
     Suppress warnings about behaviours that have no -callback attributes for
     their callbacks.
  -Wunmatched_returns ***
     Include warnings for function calls which ignore a structured return
     value or do not match against one of many possible return value(s).
  -Werror_handling ***
     Include warnings for functions that only return by means of an exception.
  -Wrace_conditions ***
     Include warnings for possible race conditions.
  -Wunderspecs ***
     Warn about underspecified functions
     (those whose -spec is strictly more allowing than the success typing).

The following options are also available but their use is not recommended:
(they are mostly for Dialyzer developers and internal debugging)
  -Woverspecs ***
     Warn about overspecified functions
     (those whose -spec is strictly less allowing than the success typing).
  -Wspecdiffs ***
     Warn when the -spec is different than the success typing.

*** Identifies options that turn on warnings rather than turning them off.

The exit status of the command line version is:
  0 - No problems were encountered during the analysis and no
      warnings were emitted.
  1 - Problems were encountered during the analysis.
  2 - No problems were encountered, but warnings were emitted.

转载:http://cryolite.iteye.com/blog/259877