D4no0
Credo rule to dissallow calls to specific functions
I have a project currently that I want to ban calls to some functions. Currently, all of those functions are either from a library or standard elixir library.
Since I have already a credo pipeline running, I was wondering if it would be possible to define a custom rule for this, or maybe there is already an existing rule for this (I could not find it).
Has anyone managed to do this successfully?
Marked As Solved
sodapopcan
I made one to ban assign/2. then is next ![]()
defmodule GelaSkins.Credo.NoCallsToAssign2 do
@moduledoc """
Checks that `Phoenix.LiveView.assign/2` can't be called.
"""
# you can configure the basics of your check via the `use Credo.Check` call
use Credo.Check,
base_priority: :high,
category: :custom,
exit_status: 0,
explanations: [
check: """
Always use `assign/3` in favour of `assign/2`.
This forces a pipeline when using multiple assigns. The advantage here is
that assigns may be added, removed, and re-ordered easily (no commas to deal
with) making diffs nicer. It also means you must explicitly name the
parameters accepted by LiveComponents. You cannot simply do
`assign(socket, assigns)`.
"""
]
@doc false
@impl true
def run(%SourceFile{} = source_file, params \\ []) do
# IssueMeta helps us pass down both the source_file and params of a check
# run to the lower levels where issues are created, formatted and returned
issue_meta = IssueMeta.for(source_file, params)
# Finally, we can run our custom made analysis.
# In this example, we look for lines in source code matching our regex:
Credo.Code.prewalk(source_file, &traverse(&1, &2, [], issue_meta))
end
defp traverse({:|>, _, [{:socket, _, _}, {:assign, meta, [_]}]} = ast, issues, [], issue_meta) do
{ast, issues ++ [issue_for(:assign, meta[:line], issue_meta)]}
end
defp traverse({:assign, meta, [{:socket, _, _}, [_]]} = ast, issues, [], issue_meta) do
{ast, issues ++ [issue_for(:assign, meta[:line], issue_meta)]}
end
defp traverse(ast, issues, _, _issue_meta) do
{ast, issues}
end
defp issue_for(trigger, line_no, issue_meta) do
format_issue(
issue_meta,
message: "Only use assign/3",
line_no: line_no,
trigger: trigger
)
end
end
It also checks for a single pipe into assign. I can’t remember why I did this instead of using the existing credo rule but I assume it’s because sometimes I’m ok with single pipes. This was a while ago.
Also Liked
sodapopcan
I’d say it’s definitely fine to do all of them in a single check. Certainly less code. I think the only advantage in using multiple checks is giving more details about why specific functions are banned per error as opposed to just a big “don’t a or b or c or d” but if you aren’t distributing it then one big one is fine.
Rereading this a perhaps slightly clearer way to write the check would be:
defp traverse({:assign, meta, [args, [_]]} = ast, issues, [], issue_meta)
when elem(args, 0) == :socket and len(args) == 3 do
{ast, issues ++ [issue_for(:assign, meta[:line], issue_meta)]}
end
EDIT: I royally hecked up my refactor there—it made no sense as I was using elem on a list and && in a guard
Fixed it, but now it’s only maybe marginally better.
EDIT 2: I should really stop answering questions first thing in the morning. I re-edited it, not that is really matters
I also realized the way I had it there it’s possible to get around the rule by not calling the socket variable socket, so perhaps you don’t even want to check for that. Ok, I’m really done now (probably, lol).
sodapopcan
krasenyp
I haven’t seen such rule and don’t know how to implement it but I’m curious about your use case as I too want to do something similar. In my case it’s related to capability-based development.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









