Packages
credo
1.7.14
1.7.19
1.7.18
1.7.17
1.7.16
1.7.15
1.7.14
1.7.13
1.7.12
1.7.11
1.7.10
1.7.9
1.7.8
1.7.7
1.7.7-rc.0
1.7.6
1.7.5
1.7.4
1.7.3
1.7.2
1.7.2-rc.4
1.7.2-rc.3
1.7.2-rc.2
1.7.2-rc.1
1.7.2-rc.0
1.7.1
1.7.0
1.7.0-rc.2
1.7.0-rc.1
1.6.7
1.6.6
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.6.0-rc.1
1.6.0-rc.0
1.5.6
1.5.5
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.5.0-rc.5
1.5.0-rc.4
1.5.0-rc.3
1.5.0-rc.2
1.5.0-rc.1
1.4.1
1.4.0
1.4.0-rc.2
1.4.0-rc.1
1.3.2
1.3.1
1.3.0
1.3.0-rc3
1.3.0-rc2
1.3.0-rc1
1.2.3
1.2.2
1.2.1
1.2.0
1.2.0-rc4
1.2.0-rc3
1.2.0-rc2
1.2.0-rc1
1.1.5
1.1.4
1.1.3
1.1.2
1.1.1
1.1.0
1.1.0-rc3
1.1.0-rc2
1.1.0-rc1
1.0.5
1.0.4
1.0.3
1.0.2
1.0.1
1.0.1-rc1
1.0.0
1.0.0-rc1
0.10.2
0.10.1
0.10.0
0.9.3
0.9.2
0.9.1
0.9.0
0.9.0-rc8
0.9.0-rc7
0.9.0-rc6
0.9.0-rc5
0.9.0-rc4
0.9.0-rc3
0.9.0-rc2
0.9.0-rc1
0.8.10
0.8.9
0.8.8
0.8.7
0.8.6
0.8.5
0.8.4
0.8.3
0.8.2
0.8.1
0.8.0
0.8.0-rc7
0.8.0-rc6
0.8.0-rc5
0.8.0-rc4
0.8.0-rc3
0.8.0-rc2
0.8.0-rc1
0.7.4
0.7.3
0.7.2
0.7.1
0.7.0
0.6.1
0.6.0
0.6.0-rc2
0.6.0-rc1
0.5.3
0.5.2
0.5.1
0.5.0
0.4.14
0.4.13
0.4.12
0.4.11
0.4.10
0.4.10-dev
0.4.9
0.4.8
0.4.7
0.4.6
0.4.5
0.4.4
0.4.3
0.4.2
0.4.1
0.4.0
0.4.0-beta5
0.4.0-beta4
0.4.0-beta3
0.4.0-beta2
0.4.0-beta1
0.3.13
0.3.12
0.3.11
0.3.10
0.3.9
0.3.8
0.3.7
0.3.6
0.3.5
0.3.4
0.3.3
0.3.2
0.3.1
0.3.0
0.3.0-dev2
0.3.0-dev
0.2.6
0.2.5
0.2.4
0.2.3
0.2.2
0.2.1
0.2.0
0.1.10
0.1.9
0.1.8
0.1.7
0.1.6
0.1.5
0.1.4
0.1.3
0.1.2
0.1.1
0.1.0
0.0.1-dev
A static code analysis tool with a focus on code consistency and teaching.
Current section
Files
Jump to
Current section
Files
lib/credo/check/refactor/double_boolean_negation.ex
defmodule Credo.Check.Refactor.DoubleBooleanNegation do
use Credo.Check,
id: "EX4007",
base_priority: :low,
tags: [:controversial],
explanations: [
check: """
Having double negations in your code can obscure the parameter's original value.
# NOT preferred
!!var
This will return `false` for `false` and `nil`, and `true` for anything else.
At first this seems like an extra clever shorthand to cast anything truthy to
`true` and anything non-truthy to `false`. But in most scenarios you want to
be explicit about your input parameters (because it is easier to reason about
edge-cases, code-paths and tests).
Also: `nil` and `false` do mean two different things.
A scenario where you want this kind of flexibility, however, is parsing
external data, e.g. a third party JSON-API where a value is sometimes `null`
and sometimes `false` and you want to normalize that before handing it down
in your program.
In these case, you would be better off making the cast explicit by introducing
a helper function:
# preferred
defp present?(nil), do: false
defp present?(false), do: false
defp present?(_), do: true
This makes your code more explicit than relying on the implications of `!!`.
"""
]
@negation_operators [:!, :not]
defguard is_doube_negation(a, b) when a in @negation_operators and b in @negation_operators
@doc false
@impl true
def run(%SourceFile{} = source_file, params) do
ctx = Context.build(source_file, params, __MODULE__)
result = Credo.Code.prewalk(source_file, &walk/2, ctx)
result.issues
end
defp walk({a, meta, [{b, _, ast}]}, ctx) when is_doube_negation(a, b) do
{ast, put_issue(ctx, issue_for(ctx, meta, format_trigger(a, b)))}
end
defp walk(ast, ctx) do
{ast, ctx}
end
defp format_trigger(:!, :!), do: "!!"
defp format_trigger(a, b), do: Enum.join([a, b], " ")
defp issue_for(ctx, meta, trigger) do
format_issue(
ctx,
message: "Double boolean negation found.",
trigger: trigger,
line_no: meta[:line]
)
end
end