One Simple Trick to Instantly Improve Your Code - Finishing Tom Scott's FizzBuzz

In this video, we are taking a look at Tom Scott's solution to the FizzBuzz challenge, and see if we can improve his unfinished code.

[daemonsoadfan]

I personnally would have separated the limit variable than the rest of the ruleset. The reason is that, when manipulating the object rule set, with your solution you need to know in advance than the first element contains this type of object, but the next elements are different types of objects. So i would have preferred two variables with meaningful names, instead of only ruleset :)

[ratelslangen]

Major problem is your use of a heterogeneous list for the ruleset. Take the limit out, pass it in as a seperate parameter, makes the function itself much smaller.
Add a starting number parameter for bonus points. Return as a list of strings rather than logging it for purity, reusability and maintainability.
Personal gripe: two single letter variables that arent very clear, could easily be replaced with a full word or the loop over the ruleset can be replaced with a foreach.

[rubinelli]

The problem with abstraction is assuming you know where the code is most likely to change. Way too often, that added layer of abstraction adds work when a new, non-trivial requirement is added. For example, say we add the following rule: "When the number is divisible by 20 but not by 3, print Bingo instead." Now this is simple to add in a "dumb" if-else chain, but not as simple in the code that abstracts out the rules.

[JasonLatouche]

I think this solution is kinda nice for a more complex set of requirements... For example: the ruleset can be updated live from a database without the need to compile/deploy your code again...

[DNA]

I think there a two different ways you can reason when developing code to be future proof.
1. make the code very easy to understand and read so it becomes very easy for someone to understand it and change it later if necessary. (this is toms most compact solution)
2. break it out and abstract away the logic so you don't need to read it to use/change the behaviour. (this is what you did)
Both of these approaches are great. In the fizzbuzz problem, I would probably go with toms. But when problems and logic become more complicated. Like, making an algorithm to calculate prices of raw materials based on parameter a, b, c, d, e, f, g.... Then reading and refactoring becomes way to much work and your technical debt with go to the moon very fast, and this approach is better.

At my current job I'm working in a codebase that is 20 years old and with a technical debt half way to the moon. and this type of abstraction of logic is so valuable when complexity becomes higher then simple if statements.

[wlockuz]

This reminds me of my favorite programming principal.

YAGNI - "You Are Not Gonna Need It"

It basically means prematurely preparing your code for future extension is a bad idea.

[shadow_vertex]

I see you were inspired by FizzBuzz Enterprise Edition

[glitchinLife]

People that argue it's an overkill for such a small problem and the solution made the code "worse" in your opinion, you are right. Also, you completely missed the point. When you explain a complex idea to someone you try to come up with the simplest example to which you apply that idea, so people focus on the idea not the example, take the concept, and try to apply to more complex scenarios, and with practice the idea will become part of their knowledge. If we have to come up with a complex example to illustrate "fairly" every concept we try to teach it would take us more than the lifetime of everyone that watched this video to explain the simplest things. Not to mention how easily people get bored! Don't take my word on it, try it yourself, take the most elaborate example you can think of and try to explain even the simplest of ideas to someone and see how long it takes before they run away

[ifstatementifstatement]

The trick to improving your code is seeing examples of good code, understanding it and doing the same.

[ujjwallimbu]

Im just starting out as a web dev, this seems so brilliant. I literally have to pause and understand for every logic within the code. I hope i will get there someday.

[Cranked]

I would consider your "improved" code to be bad and even worse than Scotts. You made it more complex by adding unnecessary abstractions, made it harder to read and made it slower. You also have to lookup the ruleset array which is outside of the function that does the actual logic if you want to understand the function. Also your solution only works in languages like javascript because you used an array of objects and mixed different array values which is a big nono. Abstraction is not the answer to "better" or "cleaner" code. It is useful when needed but using it everywhere like in the smallest function possible leeds to bad code.

[bened]

You have succeeded in the practice all programmers sooner or later become masters in: Taking a simple solution everybody can understand and making an overly complex and mind-consuming mess out of it. I love it!

[harsha]

Fizzbuzz enterprise edition is what perfection looks like 😂

[MrBreakstuff]

The only issue i really have here is nested for loops paired with "computational thinking". This isn't computational thinking. You're deliberately avoiding thinking about what the computer is doing. This would be thinking in terms of abstraction, which usually goes in the opposite direction - optimising for ease of use to a developer rather than the CPU. Others have pointed out that this is probably only nanoseconds slower, and I suspect that might go away entirely after V8 has run it a few times. It's definitely a good approach, but I think we should be very careful about mistaking abstraction for computation.

[wardibald]

While this is indeed a better way of going about solving this problem with separation of concern, do realize that by decoupling the rules from the logic, you always have a bit of extra work that otherwise would not be necessary: validation of the rules.

The code might not behave as expected with, say, a zero or negative or null limit, no rules, repeating rules, null-string in some or all rules, and so on. This is no longer under your control if you decouple the rules and allow future users to access and modify them.

[Petticca]

This video was great!

I know pretty much absolutely nothing about coding. I can, however, follow concepts and learn, I think. Heh.

I watched the original and I appreciated that Tom started by breaking down that you're actually asking for different things to be done, and that you need to understand what and why. Which was really helpful for someone like me, a viewer who is pretty ignorant on the subject, it is filed under basics, after all. I think it was the perfect amount of information for the intended audience.

Watching this "follow up", was fantastic for explaining why you wouldn't actually code it that way if you were using it for anything more than an ad hoc demonstration that you understand _what_ you're being asked to create, and what separate concepts you need to understand are included.

I think if I followed you correctly (again, ignorant peon here) that primarily your changes place the information that's uniquely specific to the game in question, in a clear, easy to access and thus change, location.

And in doing so you streamlined the code?

Is this set up now actually performing/executing (sorry I don't know the correct terms) less commands, as it's using one and running through a checklist that includes 'instruction' there?

I guess I'm asking is are less "if" statements within the loop because they've been consolidated into the code at the top? If yes, is this more efficient and less resource intensive? And if that is the case, then presumably in more complex programming/coding there would potentially be times where the complexity, or specifics of what you're asking it to do, would be better kept as separated commands?

I hope someone with knowledge can understand what my ignorant ass is trying to get at and help out, it is would be appreciated!

[ThyTrueNightmare]

as you were showing tom's code, I figured out the solution myself. So I guess I am actually a decent programmer after all!

[beatboy]

I really, really hate this code. Whilst tom's code is not what I would do because as you said it does mix rules and logic, his code was substantially simpler. Lets take 1 example, rule 1 from your ruleset object. Instead of using a variable with a simple name like limit, defined within the function, you have used a very opaque ruleset[0], as a maintainer I have no idea what that is, which means I need to go to the definition, remember what ruleset[0] is, then play around with it in the context of the code to slot it in place of ruleset[0], which is the opposite of how abstraction should be. The point of abstraction is to not need to look at the code to understand how it works. In fact I just have a problem with using the object in this code at all. Here is how I would remake the code, instead of an object create a hashmap whose key is 3, 5... and the value is 'fizz', 'buzz' …. I personally would put it inside the function to prevent name pollution but it doesn't much matter. Then define my limit variable to be say 100, create my first loop and output variable as you have. Then instead of having to loop through all of of the things in the object you can use JavaScript's built in .forEach() function to check if I is divisible by a key, then add the value to the output variable if it is, whilst this essentially does the same thing its far more terse and easier to parse. Then check if the string is empty as you have. And finally console.log(output).

[lve]

I don't think an array should contain diffrent values

[aaronspeedy]

No disrespect to your content, but this seems like a way to instantly over complicate a lot of your code. When reading this code, you would have to jump to a new function to see how it worked, and in order to change the anything you would have to jump to the definition of the rulset and change it there. It's also pretty limiting in that you would have to change how the ruleset data is stored to change the logic. I think you have the right idea of storing the conditions in a data structure, but I think a much better approach would be to just store it in an array defined inside the function and only turn it into a general function if you need to do the same thing elsewhere in the code