this is adapted from credo here
- Consistency.ExceptionNames
- Consistency.LineEndings
- Consistency.SpaceAroundOperators
- Consistency.SpaceInParentheses
- Consistency.TabsOrSpaces
- Design.TagFIXME
- Design.TagTODO
- Readability.FunctionNames
- Readability.LargeNumbers
- Readability.MaxLineLength
- Readability.ModuleAttributeNames
- Readability.ModuleDoc
- Readability.ModuleNames
- Readability.ParenthesesInCondition
- Readability.PredicateFunctionNames
- Readability.TrailingBlankLine
- Readability.TrailingWhiteSpace
- Readability.VariableNames
- Refactor.ABCSize
- Refactor.CondStatements
- Refactor.CyclomaticComplexity
- Refactor.FunctionArity
- Refactor.MatchInCondition
- Refactor.NegatedConditionsInUnless
- Refactor.NegatedConditionsWithElse
- Refactor.Nesting
- Refactor.PipeChainStart
- Refactor.UnlessWithElse
- Warning.BoolOperationOnSameValues
- Warning.IExPry
- Warning.IoInspect
- Warning.NameRedeclarationByAssignment
- Warning.NameRedeclarationByCase
- Warning.NameRedeclarationByDef
- Warning.NameRedeclarationByFn
- Warning.OperationOnSameValues
- Warning.OperationWithConstantResult
- Warning.UnusedEnumOperation
- Warning.UnusedKeywordOperation
- Warning.UnusedListOperation
- Warning.UnusedStringOperation
- Warning.UnusedTupleOperation
- Exception names should have a common prefix or suffix, a common choice is have all of them end in
Errorread more
- Use line-endings consistently (Unix-style line endings are preferred) read more
- Use spaces around operators and after commas read more
- Don't use spaces after
(,[, and{or before},], and)read more
- 2 spaces soft-tabs are preferred read more
- Use
TODO:comments to plan changes to your code read more
- Use
FIXME:comments to plan changes to your code read more
- Function and macro names are always written in snake_case in Elixir read more
- Numbers can contain underscores for readability purposes read more
- Checks for the length of lines. (max 80) read more
- Module attribute names are always written in snake_case in Elixir read more
- Every module should contain comprehensive documentation read more
- Module names are always written in PascalCase in Elixir read more
- Because
ifandunlessare macros, the preferred style is to not use parentheses around conditions. read more
- Predicate functions/macros should return a boolean value, for functions, they should end in a question mark.
# preferred way
def valid?(username) do
# ...
end
# NOT okay
def is_valid?(username) do
# ...
end
- Files should end in a trailing blank line read more
- There should be no white-space (i.e. tabs, spaces) at the end of a line read more
- Variable names are always written in snake_case in Elixir read more
- The ABC size describes a metric based on assignments, branches and conditions.
- A high ABC size is a hint that a function might be doing "more" than it should. read more
- Each cond statement should have 3 or more statements including the "always true" statement. read more
- A function can take as many parameters as needed, but even in a functional language there can be too many parameters. read more
- Pattern matching should only ever be used for simple assignments inside
ifandunlessclauses. read more
- Pipes (
|>) can become more readable by starting with a "raw" value. read more
- Cyclomatic complexity is a software complexity metric closely correlated with coding errors
- If a function feels like it's gotten too complex, it more often than not also has a high CC value read more
- Unless blocks should not contain a negated condition read more
- An
ifblock with a negated condition should not contain an else block read more
- Code should not be nested more than once inside a function read more
- An
unlessblock should not contain an else block read more
- Most calls to the IExPry function are added during debugging sessions
- This check warns about those calls, because they might have been committed in error read more
- Most calls to the IoInspect function are added during debugging sessions
- This check warns about those calls, because they might have been committed in error read more
- The names of local variables should not be the same as names of functions or macros in the same module or in
Kernel. read more
- Names assigned to choices in a
casestatement should not be the same as names of functions in the same module or inKernel. read more
- Names assigned to parameters of a named function should not be the same as names of functions in the same module or in
Kernel. read more
- Names assigned to parameters of an anonymous function should not be the same as names of functions in the same module or in
Kernelread more
- Operations on the same values always yield the same result are likely the result of a debugging session or mistake. [read more](https://github.com/rrrene/credo/blob/master/lib/credo/check/warning/operation_on_same_values.ex
- Boolean operations with identical values on the left and right side are most probably a logical fallacy. read more
- With the exception of
Enum.each/2, the result of a call to the Enum module's functions has to be used. read more
- The result of a call to the Keyword module's functions has to be used. read more
- The result of a call to the List module's functions has to be used. read more
- The result of a call to the String module's functions has to be used. read more
- The result of a call to the Tuple module's functions has to be used. read more
- Operations on the same values always yield the same result and therefore make little sense in production code. read more