Click here to Skip to main content
13,089,500 members (59,688 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


1 bookmarked
Posted 10 Apr 2014

Fizzy Bizzyness

, 10 Apr 2014
Rate this:
Please Sign up or sign in to vote.
Fizzy Bizzyness

FizzBuzz is an interview question which supposedly helps “filter out 99.5% of programming job candidates” who can’t program. I find this assertion very hard to believe, unless those tested are non-coding managers. But anyway, the problem statement is simple:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

A simple implementation in C# might look like this:

public void FizzBuzzSimple()
   string s;
   for (int i = 1; i < 101; i++)
      s = string.Empty;

      if (i % 3 == 0) s += "Fizz";
      if (i % 5 == 0) s += "Buzz";
      if (s.Length == 0) s = i.ToString();


Since the algorithm here truly is straightforward and simple, a more interesting exercise might be to consider the ways in which this code might change as the requirements change over time. Something like a kata. (For a fun “simple” problem description from a non-programmer’s point of view, this is hilarious, and all too true:

We’re all familiar with code where the conditional expressions have become both ugly and impenetrable. In fact, we’ve probably “contributed” to these codebases at some point too. Something that may have started with a relatively simple “if ((A and !B) or C)” grows over time to a rat’s nest of and’s, or’s, not’s, etc. So what might change here, and can we, or should we, try to “future proof” against it?

  • What if the range changes? Instead of 1 to 100, the user now wants 1 to 1000, or maybe 50 to 100. Maybe the range needs to be user configurable.
  • What if our output strings change? Instead of “Fizz” and “Buzz”, the user wants “Buzz” and “Feed”. Should we continue to hardcode magic strings? Maybe we want something entirely different than the “FizzBuzz” concatenation when a multiple of 15 is found. What if we need to localize the strings based on the user’s language?
  • What if the test conditions change, or new conditions are added? In practice, this is often the most likely change agent. What if more complex conditions are needed, such as special processing for multiples of 10? How can we make the code easy to read and maintain over time?
  • What if the test conditions, in the real world, are expensive in terms of performance? Instead of testing numbers, maybe we’re calling functions which make database or service calls. How do we make this performant?
  • What if our user no longer wants to “print” the output? Maybe the output will go to a diagnostics window, log, or screen. Could dependency injection help here?

There are probably myriad more possibilities, but I’m already feeling analysis paralysis.

Filed under: C#, my 2 cents


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

A Round Tuit
AKA Programmers
United States United States
I started my professional career as a mainframe Assembler programmer at a small insurance company. Since then I've developed dozens of enterprise and commercial solutions using a grab bag of technologies. I've been developing with .NET since 2003 and still love it.

You may also be interested in...

Comments and Discussions

GeneralMy vote of 2 Pin
sam.hill10-Apr-14 10:32
membersam.hill10-Apr-14 10:32 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.170813.1 | Last Updated 10 Apr 2014
Article Copyright 2014 by A Round Tuit
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid