When looking for code examples that solve a given problem many of us might just seek out something that just works often on stack overflow, copy and past it in, and move on. Although there might be many great code examples for certain problems out in the open web that work fine, they might not always work great all the time, in every little way.
One solution is to start out with having a for loop that goes threw all values for i from 1 up to and including 100. the use conditional statements for Fizz, Buzz, FizzBuzz, and just logging out the value of i.
This solution works as expected, but all ready looks pretty sloppy. Also what about further expanding the code to included additional messages to print for certain multiples or collections of multiples. That would result in yet even loner expressions for each possibility. So then there should be a cleaner way of doing the same thing right? Well lets look at some more examples that do the same thing.
So another solution would involve using a variable that starts out as an empty string by default for each value of i in the loop. Then test if i is a multiple of 3 and if so add Fizz to the output string. Then if i is a multiple of 5 add Buzz to what will either be Fizz or an empty string. If after all this the value of the output variable is still an empty string set the value of output to the value of i.
For Cleaner sure, but we are still repeating code here, so maybe there is yet an even better way maybe?
So now there is the idea of making a helper method that accepts the current value of i, a multiple value such as 3, and then a message to return.
So now I have a little fizzer pure function of sorts that will always return the right string value for a set of given arguments. So now I am not reading code, but I have to add some code to not do so over and over again. For now it does not make a big difference, but if this project where to grow larger over time it might add up.
There is even more to writ about when it comes to all the little issues that will come up that result in technical problems, as well as readability concerns. There is always more than one solution to a problem, and some work may work out a little better than others. The situation might change and code might break, or it might end up eating up too much resources and needs to be scaled. The list of concerns goes on, and on, but it seems to me there are two general ways of thinking when it comes to working out any kind of solution for a problem. One way is to just quickly throw something together that works and moving on, and the other is trying to make a more solid software product that might take way longer to produce.