Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
2Activity
0 of .
Results for:
No results containing your search query
P. 1
Erlang Programming Style Guide

Erlang Programming Style Guide

Ratings: (0)|Views: 1,334|Likes:

More info:

Published by: Dmitrii 'Mamut' Dimandt on Jul 30, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

07/30/2012

pdf

text

original

 
How-To Documentation/Programming StyleGuide
Contents
1 Coding Standards1.1 Style1.1.1 File Structure1.1.1.1 Headers1.1.1.2 Compiler Attributes1.1.1.3 Record Definitions1.1.1.4 Function Definitions1.1.1.5 Comments1.1.2 Indentation1.1.3 Naming1.1.4 Hiding thethreaded state1.1.5 Size of Aggregates1.1.5.1 Modules1.1.5.2 Functions1.1.6 Performance1.3 UTVCoding Standards forTesters and Test Developers1.4 Document Approval
Coding Standards
We follow the Erlang Programming Rules and Conventions[1], with some localadditions (documented on this page). In particular, Section 8 of that document isentirely superseded by this page, and should be ignored.The reader may wish to consult [2, 3] for further discussion of programming style indeclarative languages. Well-formatted example programs are available at [4].[1] http://www.erlang.se/doc/programming_rules.shtml[2] http://norvig.com/luv-slides.ps[3] http://www.ai.uga.edu/mc/plcoding.pdf We follow an Agile development methodology which uses the best practices of all theflavours of agile be it XP or Scrum or Kanban. We believe that a key feature of agiledevelopment is to do testing and development in parallel. Therefore developers arerequired to write unit test cases and do exploratory testing while developing.
 
Also, if you (as a tester, developer or anyone else) find a module or a feature which islacking in unit- and functional test cases, it should be considered a bug and reported.
Style
File Structure
Headers
The file header should include at least the creation date (copyright), and a shortdescription of the purpose of the file. Other EDoc tags should be used as needed.
%%%=============================================================================%%% @doc One-line description of this module.%%% More detailed commentary here.%%% ...%%%%%% @copyright 2012 %%%%%% @reference%%% ...%%%%%% @end%%%=============================================================================
Compiler Attributes
Typical files contain the module, export, and include_lib (do not use -include() !)declarations.Exported definitions should be listed alphabetically. If necessary, separate exportdeclarations should be used for API exports, internal exports (apply), and testexports.
-module(quux).%% API-export([ bar/2, baz/2, frob/4...]).%% RPC-export([twiddle/1]).-include_lib("...").
Record Definitions
Use type annotations for record fields.
-record(quux,{ foo :: [integer()], bar :: ok | error, baz :: _ }).
 
Local type definitions can increase readability.
-type values() :: [integer()].-type tag() :: ok | error.-record(quux,{ foo :: values(), bar :: tag(), baz :: _ }).
Some comments on restrictions that you cannot express in the type system will beappreciated.
Function Definitions
All non-trivial functions should be annotated with a type specification and doc-comment (stating what the high-level purpose of the function is). An Eunit testfollowing the definition may be appropriate.
-spec frob(...) -> ...%% @doc ...frob() ->...
In particular, exported (API) functions must always be documented in this way.Groups of related functions should be preceded by a block comment which listsassumptions, invariants, side effects, etc. if applicable.Horizontal separators should be used to identify groups of related functions within asource file.
%%=============================================================================
Or, if further (sub-)grouping is desired:
%%-----------------------------------------------------------------------------
Comments
The number of '%' preceding a comment indicates the scope of the comment.Three '%'s are used for comments which apply to the entire source file; normally, thismeans the file header, but one could imagine something along the lines of:
%%%%%% Manually optimized code, do not touch.%%%
Emacs erlang-mode will enforce that such comments do not get indented beyond thefirst column. However, it is not mandatory to use '%%%' at the file scope; '%%'

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->