At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.
Variable names in most languages, Python included, can be about 32 characters in length. They can be a LOT more descriptive than say "a". This helps document what the code is doing. More comments would be a good habit to get into. Especially if you want mixed case strings as input, I would put the selections in the prompt: b = raw_input("Player 2, Rock, Paper or Scissors?") If you want something to play with, your truth table could be translated into a dictionary of dictionaries that have the result as the value. That may be a bit too much. The two input stanzas could be made into a function that returns the validated input. The prompt could be passed in. Again, this may be too much.
Thanks! Great suggestions. Just covering functions now, so can see how the input could be validated that way. Haven't gotten to dictionaries yet.
Here's my code for this one: http://pastebin.com/D7nxa3f0 See if you can understand why I've done things the way I've done them. Think about how could you make it scale to having more options (e.g. Lizard/Spock).
bdean20: Cool. You are using some stuff I haven't gotten to yet, but I can follow what you've done. I can see how you've used the function to accommodate different numbers of players. I also missed an opportunity to save code by checking if the two players' choices we generically equivalent. Pastebin is cool too! Thanks so much!
I like the structure of this version much more. You're on your way. result = (RockPaperScissors(playerChoices[player1], playerChoices[player2])) A couple of things about this line, first one pair of parentheses aren't needed: result = RockPaperScissors(playerChoices[player1], playerChoices[player2]) Many (most?) people (myself included) by convention only capitalize the names of classes (you'll get to them), functions should start with a lowercase letter: rockPaperScissors() You need WAY more commenting. I have code from years ago, still in production, that I hate to maintain because I didn't comment it. A line or two of description about what each function does, expects for inputs, what it returns (including data type [ string, int, float ] is a WONDERFUL thing. In one of the OCW courses that I've done, it was recommended that blocks (sections) of code be less than 15 lines long. As I do it, I like it! One of Python's idioms, which caters to C style programming is writing all your functions and then starting execution: def func1(): def func2(): def func3(): if( __name__ == "__main__" ): func1() if( func3() ): func2() func4() print( "Done" ) This structure helps on larger programs. Combined with keeping blocks of code small, it makes for good code to debug and maintain. Lately I've been framing out programs by writing my function headers and comments and then coming back and filling them in with code later.
@rsmith6559 Thanks for your input. 1. I completely overlooked the brackets bit, but it's no big deal. Extra brackets never hurt. 2. The capitals issue isn't a big deal in standalone files with 0 classes. My excuse is that I used copy/paste for the words from within the strings and never got around to fixing it. 3. The entire point of meaningful variable names is that you don't need extra comments that do absolutely nothing for you. In a relatively simple program, you don't need all that many comments. Often in the type of programming I do, there isn't much time to be all that pedantic about coding style. Generally, the moment it compiles and passes all of the tests, I'm done with it and never look at it again. Finally, I do not intend to ever develop anything large with python. As much as I love the language, it's more of a problem-solving utility for me.
Bear in mind, the only thing that I know about @scarson is that they're taking an intro course. My assumption is that this is the time that they're developing habits, both good and bad, hence being pedantic about details that aren't all that important for short, throwaway programs but will save a lot of unneeded effort as the projects get larger and more complicated.
I totally appreciate the feedback, @rsmith6559. You are exactly right, I knew I had a s
You are exactly right on, @rsmirh6559. I knew I had code that worked, but other than that had no idea whether it was well written or not. Yours is exactly the feedback I was looking for. Thanks.