I’ve found defdelegate kind of annoying when using Visual Studio Code because it makes code navigation lot worse. At least when using Elixir-lsp extension.
wanton7
0
dogweather
I agree with everything you said about the Elixir culture. I guess I’ve got some baggage coming from the Ruby world: Never-ending DSLs and methods with open-ended options which aren’t well documented and not error-checked. In fact, even the rails command line app doesn’t check many of the options given and will silently fail in some cases.
0
dogweather
gregvaughn
I may be going off on a tangent here, but I find the best way to learn idioms of a language is to read code. Reading skills don’t seem to be taught much in colleges and bootcamps, but it is an extremely valuable skill. With so much open source out there, pick a project with experienced developers you respect, and read the way they wrote the code. You’ll learn so much more than any blog or video can teach. You’ll actually build up your own intuition for not only what the idioms are, but why they’re not something different. If you just pick this up from books/blogs/videos your answer to “why” questions is likely “because #{person} said so” instead of the core underlying reasoning they used.
4
dogweather
So actually, I’m not looking for resources for learning idioms. Rather, I’m looking for resources that are idiomatic. I.e., the code samples follow real-world practices. E.g., not skipping specs and @enforce_keys simply because it’s sample code.
Basically, I want to be coding using best practices all the time, and not needing to tack on that knowledge later on.
0
keathley
I can’t speak for most of the books out there. But I can tell you that Functional Web Development with Elixir, OTP, and Phoenix followed all of our “real-world practices”. We didn’t use the dialyzer and thus didn’t write specs. We didn’t use @enforce_keys because it creates brittle systems that are resistant to growth. I don’t believe you can definitively say that authors are leaving these things out for the sake of brevity. It might be that the authors don’t consider those to be “best practice” in the first place.
3
dogweather
Thanks. Yep, I’m interested to learn how these features are used.
Personally, I’m a believer in strong typing for domain modeling. I find it analogous to database constraints. I actually use Haskell for data import & JSON production so that I can lock down & guarantee my data and attributes. I haven’t had a problem with brittle code. During development when I’d find that I needed to change my model, I’d make the changes and then the compiler would guide me to the code that needed to adapt.
1
dimitarvp
What kind of growth are we talking about? If this is about rapid prototyping where you release 3 times a day then I’ll agree. But outside of that extreme case having stricter checks will definitely save you from mistakes made by tight schedules which will then tighten those schedules even further due to having to frantically fix bugs.
I don’t know the exact context and I might be way off but this is how it shook out for me, many times. Stricter checks intuitively feel annoying when you just want to build something quickly but they can also save a lot of time.
2
keathley
dimitarvp
This is definitely partially against my principles because I don’t believe in universal truths most of the time. But I’ve allowed myself to compile a list of those possible idiomatic good practices – which IMO go well beyond Elixir itself.
-
Use
@spec. However I’ll strongly recommend against that during rapid prototyping. It will just get in the way. The moment you find a module haven’t changed in 2 weeks however, go put specs on its functions and start chasing the green output ofdialyzer. -
Complement
@specwith your own guards. If you know a datatype you use is actually a list, DO NOT guard it withis_list(param). Define a guard and use that instead:
@spec orders :: [%Order{}]
defguard is_orders(x) when is_list(x)
def eligible_for_discount?(orders) when is_orders(orders) do
#...
end
-
Do not overdo docs. Many times they should even be superfluous. If your function is well-named and the parameter names hint at their purposes clearly enough you should be just fine by putting something like
Checks if this batch of orders is eligible for a corporate discountor even without docs at all. Module docs are mostly important for widely used libraries. For your own open-source pursuits and commercial projects they are mostly a distraction. Go for GitHub’s wiki articles, or Atlassian’s Confluence pages, etc. -
Don’t use
importif you can help it. Resist it with all your might. Only use it if you have no other choice and your code will not work otherwise. If you really must use it, use the:onlyoption. -
Don’t overdo
caseandcond. Use function heads with hardcoded parameter values, saydef length([]), do: 0for example. Readability often means less coding lines (though certainly not always; too much brevity can make your code very cryptic but that’s a bigger topic I won’t tackle here). -
Use macros and don’t be shy about it – but use them sparingly. For example when you want to transcode stuff and writing all functions manually would be tedious: that is a very valid usage. Macros should be used to make an otherwise annoying code generation easier and quicker. Some here in this forum get tempted to use them to introduce their own extra syntax in Elixir but I am very against this; these efforts usually attempt to emulate another language’s constructs and rarely seem aimed at actual productivity (at least not in the way I understand it; I realise this is a controversial opinion). They are usually used to rekindle nostalgia for paradigms the author fondly remembers from other languages. I am personally strongly opposed to these temptations; if using macros can both reduce the coding lines and improve readability then I’ll use them. But I am not a fan of the LISP approach where people make their own DSLs which are perfectly suited for the project… and nobody else except the author can maintain them or the project after they are introduced in it. We have to keep our work maintainable. That’s the professional courtesy I want to show to future maintainers of my code and thus I resist using macros in Elixir beyond simple readability improvement and reducing otherwise tedious coding work.
-
GenServer,Agentand many OTP primitives and derivatives should be used for (a) keeping state and (b) making your system resilient to partial failures. If you find yourself using them for other purposes then you are abusing them and should reconsider your approach. -
As noted above, I like
@enforce_keysfor structs, provided I am not in the rapid prototyping phase. I will prefer compile-time errors to runtime errors 99% of the time. -
Some extraneous code is acceptable if it makes using your modules more ergonomic and intuitive. For example I regularly make wrapper
Configmodules for my apps and libraries where I expose both genericput/getfunctions and specificput_*andget_*functions (say,put_timeoutorget_batch_maximum). I’ve had colleagues argue with me over this and I’ll concede this is a personal preference but to me the intuitive reading of my code almost as if it’s English should win over small extra amounts of code.
I am probably missing several others but hopefully this gives you an idea of what I find to be good practices. Apologies for this becoming rather huge.
13