-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Make doctests from code texts for case/2 #14423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
💚 💙 💜 💛 ❤️ |
case File.read(file) do | ||
{:ok, contents} when is_binary(contents) -> | ||
String.split(contents, "\n") | ||
|
||
{:error, _reason} -> | ||
Logger.warning "could not find #{file}, assuming empty..." | ||
[] | ||
end | ||
iex> file = "no_file.txt" | ||
iex> case File.read(file) do | ||
...> {:ok, contents} when is_binary(contents) -> | ||
...> String.split(contents, "\n") | ||
...> {:error, _reason} -> | ||
...> "Can't read the #{file} file" | ||
...> end | ||
"Can't read the no_file.txt file" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only concern here is that the previous version, although not a runnable doctest, felt like a more idiomatic example (log and fallback on a sensible default) vs returning a string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't it be rewritten into something like:
iex> require Logger
iex> file = "no_file.txt"
iex> case File.read(file) do
...> {:ok, contents} when is_binary(contents) ->
...> String.split(contents, "\n")
...> {:error, _reason} ->
...> Logger.warning "Can't read the #{file} file, assuming empty..."
...> []
...> end
[]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, but doctests instead of plain code texts provide assurance(for reader) of typos and other errors absence. Also doctests don't have implicit parts(as you mentioned: side effects, internal setup and other) and much more clear and easy to understand. In case when we can't avoid side effects(as in File) it's ok, but here, i'm sure, it's possible to find a good(ideomatic) pure functional example of usage, which can be doctested.
In other words, when I read a doctest i'm 100% sure it works, and that helps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the arguments in favor of doctests and I agree they are nice when possible for pure functions.
For conditionals like case
/if
/cond
..., hard-coding the condition to have a runnable doctest might also make the example less realistic and it only demonstrates one branch, but it seems we are not consistent across these.
i'm sure, it's possible to find a good(ideomatic) pure functional example of usage, which can be doctested.
Sounds good! How about some parsing like Date.from_iso8601/1
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, i'll do a pr
No description provided.