OndrejValenta
What are your recommendations on method signatures and return values?
Based on our discussion here and to create some kind of guide for new players..
What are your guidelines and recommendations on method signatures and return values?
Since everyone can get creative in a dynamic language like Elixir you probably have some guidelines in your companies on how to define new methods and what should they return so you have easier code transfers from one programmer to another.
For example:
-
How many parameters is too much for a function? When do you rather create a structure to contain the incoming data?
-
Do you rather use single parameters or do you prefer receiving a map that you map and deconstruct?
-
What is your ordering of parameters? Do you put the most static parameters to front or back?
-
Do you override methods with specific mappings or rather have one method with a case inside?
-
What do you return from methods? Are there methods that are returning just plain values in your projects and when do you switch to {:ok, data…} tuples?
-
Do you return {:ok} or just plain :ok? For me {:ok} is more consistent with {:ok, data}, for others it’s not.
-
How many return values do you put in your return statements? Just one or two? For example, {:ok, data}, {:ok, data1, data2}
-
When do you create a return structure?
More questions will come from the discussion.
Most Liked
LostKobrakai
I really like the approach described in this, though I need to add that I never managed to work on a codebase, which consistantly did that. It’s for sure overhead, but on the other hand I really like the explicitness.
LostKobrakai
Oh god. I did just skim over the article and it mentioned the places I had read before. I’m mostly in favor of the {:error, exception} return value instead of {:error, something}. Exceptions have API to be turned into strings, they however can include structured data, which might be interesting if the caller wants to log the error. I don’t think the exact implementation shown makes too much sense.
kasvith
I also strongly believe the point @OndrejValenta raised.
Proper error handling in MVP to enterprise-level apps is very crucial. So an official guide about how to organize code around errors will be really valuable. At least mentioning some patterns in the guide would do the job.
As we saw there are a lot of third-party articles about it and some even can cause lot of trouble in the long run if you didn’t seriously take a look
Elixir has freedom, but too much freedom can shoot our own foot
so a good official guide about this would be super useful
Popular in Discussions
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








