I’m trying to continue to wrap my brain around how I should be structuring things and I’m getting stuck on the Bob exercise of Exercism. Here is my code and right now, I’m just not understanding why my “Talking in capitals” test isn’t passing like I think it should:
defmodule Bob do
def hey(" "), do: "Fine. Be that way!"
def hey(""), do: "Fine. Be that way!"
def hey(message) do
cond do
shouting?(message) -> "Whoa, chill out!"
asking?(message) -> "Sure."
shout_numbers?(message) -> "Whoa, chill out!"
capitals_letters?(message) -> "Whatever"
# true -> "Whatever."
end
end
defp shouting?(message) do
message == String.upcase(message)
end
defp asking?(message) do
String.ends_with?(message, "?")
end
defp shout_numbers?(message) do
message
|> String.upcase()
String.ends_with?(message, "?")
end
defp capitals_letters?(message) do
message
|> String.split(" ")
|> String.capitalize
Enum.join(" ")
end
end
You shouldn’t have anything aside of the cond, as well as there shouldn’t be more than 4 clauses in it, Chill out, be that way, Sure, and Whatever.
There is no reason to have any of the strings to be returned at more than one place.
Also your current version of shouting does consider "1, 2, 3" shout…
The cases you need to recognize is if the input was shout (at least one alphabetic character and all alphabetics are in uppercase), if it was a question, if it was silence or if it was none of the former.
While this is still a work in progress, my goal was to get all of the tests to pass first, then refactor while learning more about how to better use Elixir. Thank you for the feedback.
So if I may ask, what exactly did you Google as your search? Did you know that you needed to search for the Unicode solution? Just trying to get a better feel for how one would go about how to figure out how to come to a solution. When I saw your solution, all the pieces made sense and I thought, "of course that makes sense how that was solved. " But it’s the how that conclusion was reached that truly interests me. What steps did you go through to get the results you were looking for.
That was working well, except it was leaving in $ and ^, so added those on top.
Then it was failing the last test with the diaeresis on the o (ö). It was stripping it off and turning it into a binary e.g. <<107>> or whatever. Then, after about an hour of trying stuff, I tried the option for unicode u at the end of the ~r/regex/u.
It is not just an elixir thing. When working with some construct like cond you should alsways have short and concise conditions, which are easy to read and tell you not only how data has to look like, but what it actually means.
When you want to know if some property p of data is either true or false you really should give that property a proper name and make it a function suffixed by a questionmark and use it. Just consider how much better ends_in_questionmark?(input) reads compared to input |> String.replace(~r/[\s]/, "") |> String.replace(~r/[\d]/, "") |> String.last == "?", just consider how much question?(input) does even better suites the context of the exercise!
Katrina Owen (creator of exercism) gave some nice talks about refactoring in ruby, one of these talks was even about our friend bob: Katrina Owen – Overkill; 2014. There is much stuff one can transfer to elixir. Propably not the stuff about extracting into various classes, but it would make sense to extract the predicates into separate modules. Haven’t done it so far in my own solutions though, since I’ve watched Katrinas talks just 14 days ago.
I believe that the top-level function (the cond) should be a restatement of the problem specification. It should be written using terms in the problem domain (teenagers) not the solution domain (whitespace, upper case, etc.). E.g.:
def hey(input) do
cond do
question?(input) -> "Sure."
yell?(input) -> "Whoa, chill out!"
nothing?(input) -> "Fine. Be that way!"
true -> "Whatever."
end
end
See how that code pretty much reads like the assignment for the problem. This is a big advantage of functional programming.
Hi @dogweather. I like your ‘hey’ function but have a few thoughts. Recently I’ve been coming round to the idea that, in general, fewer functions is better. Why? Because more functions = more surface area for your code which makes understanding/maintaining it more difficult. This view has been articulated (in some form) by Linus, Carmack, and Blow which lends it some credibility. That is not to say that monolithic, ginormous functions are good, but that perhaps programmers have been underestimating the costs of abstracting into multiple functions. Your solution has 7 functions. For contrast here’s my single-function solution:
defmodule Bob do
def hey(input) do
cond do
String.ends_with?(input, "?") -> "Sure."
String.upcase(input) == input and String.downcase(input) != input -> "Whoa, chill out!"
String.trim(input) == "" -> "Fine. Be that way!"
true -> "Whatever."
end
end
end