A Rose is a Rose

Let me think out loud here a little and get some opinions. On what? On how far to go when naming things in programs. let me start at the beginning. The other day I decided to code up a game of “Rock Paper Scissors.” Perhaps latter to develop into the more geeky “Rock Paper Scissors Lizard Spock.” I’m doing this as a demo of the Select/Case structure in Visual Basic and the switch/case structure in C# along with a little compound if/then/else stuff. It’s a common enough project and simple enough that when I started I let the default object names stand.

I mean after all how hard is it to remember that RadioButton1 is the option for Rock, RadioButton2 is the option for Paper, and RadioButton3 is the option for Scissors? Actually not to bad. But what number value stands for the computer picking each of those options? And I wanted to select a number to represent the outcome of the comparison to make displaying the result. OK so if RadioButton1 is the player picking Rock then 1 is the computer picking 1. Right? Ah, but then I have to set the minimum as well as maximum because otherwise I have to remember to subtract 1 so that radioButon1 and 0 sort of go together. Ah, forget about it I don’t want to think that hard – rename the silly radio buttons. So now they are rRock, rPaper and rScissors. This gives me something simple that looks like (in part):

Select Case computerChoice
    Case 0          '   Rock
        If rPaper.Checked Then
            Stat = 2    '   Lose
        ElseIf rSissors.Checked Then
            Stat = 1    '   Win
            Stat = 0    '   Tie
        End If


That’s the VB code of course. But then I thought, I can use enums in C# and maybe that would be easier. So I created enums for both the computer pick and the result.

enum whoWins { iTie, iWin, iLose };
enum iPic {Rock, PaperS, Scissors};


The code (in C#) now looks something like:

switch (computerSelects)
    case (int)iPic.Rock:                    //   Rock
        if (rPaper.Checked)
            Stat = (int)whoWins.iLose;      //   Lose
        else if (rScissors.Checked)
            Stat = (int)whoWins.iWin;       //   Win
            Stat = (int)whoWins.iTie;       //   Tie


It’s all very well self documented and it’s pretty clear what is going on but it feels ugly to me. It’s the conversion/casting that bugs me the most as that just feels wrong to me. How about using integer constants? It’s a little more setup (in VB)

Dim iWin As Integer = 1
Dim iLose As Integer = 2
Dim iTie As Integer = 0
Dim pickRock As Integer = 0
Dim pickPaper As Integer = 1
Dim pickScissors As Integer = 2

But the resulting code feels cleaner  to me.

Case pickRock          '   Rock
    If rPaper.Checked Then
        Stat = iLose    '   Lose
    ElseIf rSissors.Checked Then
        Stat = iWin    '   Win
        Stat = iTie    '   Tie
    End If


For this type of project I think I get all the benefits I want from named objects (in this case integers) in terms of the code being self-documented and requiring less actual thought on things that I really shouldn’t be wasting brain cells thinking about but without the complexity of having to fully specify and cast the enums into integers. Is it still overkill? I could see some people saying so but for me there is enough added value to make it worthwhile. Clearly the computer and the compilers really don’t care. Names are just identification and in many cases they will replace variable references with loading constants into registers to speed. We really don’t need to worry too much about that.

What do you think? Hopefully I didn’t lose anyone switching between C# and VB but honestly that’s the way my crazy mind works. how would you handle this sort of thing? Is it a worthwhile conversation to have with beginners? Obviously I think so but am I wasting time?

Comments (6)

  1. ajuc says:

    I would just create 2 dimensional array indexed by playersPick and computersPick containing results. Then the code will reduce to

    result = lookUp[(int)computerPick][(int)playerPick];

    Or whatewer the syntax for c# is.

  2. ajuc says:

    If c# has HashMap type you can also omit casting to int by using

    Hashmap<Pair<enumPick, enumPick>, enumResult> lookup;

    type names probably are different in c#, but you get the idea 🙂

  3. Anon says:

    "Let me think out loud _hear_ a little"

    hear: to perceive sound

    here: to occur at this point in time/space

  4. Bryan says:

    Ummm.. Ajuc what if you/your students do not have arrays yet???

  5. ajuc says:

    Also - to really do things right we shouldn't need to cast anything.

    So there could be 2 functions nextComputerPick(..) and nextPlayersPick(...) that returns enums iPick (no need to cast to int, and we are sure that only valid values are possible).

    By doing cast to int we lose information that this variable can only have three values - in this case id won't matter - we use the value right after casting, but in some other we could pass it around, and at some point don't remember where this value came from, and is it guaranted to be valid.

    At first I didn't realized this blog is about teaching programming, if students don't know arays, of course if/case is perfectly good.

  6. Garth says:

    Being a high school programming teacher and not a programmer means I tend to look at things like this in a very simple way.  I tell the kids to look at your naming and comments as though you were going to put this project on the shelf for 3 months half way through it, then try to pick up where you left off.  If you can picture yourself saying “What the heck was I trying to do here?” then the names and comments need a little work.  The other programming teacher in my school is not big on forcing the kids to use good naming conventions or comments in their programs.  Every now and then I will wander into his classroom during programming and some kid will ask me for help.  If I see variables like i1 or a RadioButton1 I simply tell them “Kid, you are on your own until you go through and make sense of all this gibberish.”  I think a good program written by a beginner should be almost readable by a non-programmer.  The comments and variable names should provide the non-programmer a general idea as to what is going on.  Does changing i1 to picFootball require more typing?  For sure.  Does it make it a heck of a lot more readable?  For sure.  Does it improve my attitude and reduce the gray hair collection on my head when I have to help some kid do some trouble shooting?  Oh, yes.

Skip to main content