So, not only are the order of my conditions different from the lecture, some of my conditions themselves are different. This is because I have gotten in the habit of ordering my conditions by how likely they are to be true. If you put the most commonly true conditions first, you minimize the number of checks your code does. This is very much so an early micro-optimization that may not be necessary, so I do not expect it to be a common practice. At the same time, I have been conditioned to write as efficient code as possible except in cases where the code becomes a nightmare to understand. In this case, I think the code is still intuitive while also being efficient. Here are my checks:
- Is the guess wrong?
- Is the guess not an isogram?
- Is the guess the wrong length?
- The guess is valid but just not correct.
- The guess was right, so the player won.
While the game is played, the player’s guess being wrong can (and likely will) happen more often that the guess being right, so that is why I check for it being wrong first. If the guess is wrong, there are two specific cases we want to check and provide hints to the player, followed by a generic case to catch anything that is wrong but we do not want to hint as to why. In my case, I also chose to only dock a life in the generic case, so this structure works well.
Looking at the two specific reasons why the guess could be wrong, I chose to check for isograms first. This is because we tell the player the length of the word, so in practice the case where the lengths do not match should never happen barring player error. The player entering a word that is not an isogram is very much in the same boat, but that is only assuming the player knows what an isogram is (or looked it up prior to making a guess). Since we rely on the player to obtain this knowledge versus the length case where we directly tell them the information directly, it seems to me more likely the player would enter a guess that is not an isogram versus one that is of the wrong length. If we provided the definition of an isogram up front, I would consider these conditions interchangeable and put the length one first given it should be less computationally intensive than finding if a word is an isogram.
Finally, the case where the player wins happens exactly once per round given that is the whole point of the game. The only case where this would happen more often than the guessing the wrong word is if the player guessed the right word on the first try more often than not, which in practice should not be the case.
So, that is the logic I followed to get to the code I have now. I welcome any feedback and especially any challenges to my thought process. If I have made a logical mistake somewhere, I would much rather be told about it and fix it than to go on thinking my process is sound when there is in fact some error in it.
As an aside, I understand the point of this lesson was to remove the nesting of if statements by using early returns, but I opted to keep a level of nesting in favor of efficiency. One layer of nesting is not too bad to look at in my opinion. If my process would have led to two or more levels, I would have rethought my conditions to remove excess nesting and then ordered those new conditions by probability.