Timeline for RPSLS game revisited. Is my design better than previous attempts?
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:40 | history | edited | CommunityBot | replaced http://codereview.stackexchange.com/ with https://codereview.stackexchange.com/ | |
| Mar 20, 2014 at 14:55 | comment | added | Malachi | @BenVlodgi, I see your point. | |
| Mar 20, 2014 at 13:43 | comment | added | BenVlodgi | @Malachi its not that your strucutre is different than mine which is the problem. I think that you made design poor design choices. I happen to be pointing out what I believe the right choice to be, and that it is something that I have already implemented. Where proper use of a language is great when programming, but the design of your application is the most important part. If your programs structure is poorly designed it will become cumbersome, it will affect you at every stage of development, and be difficult to change once you decide to. | |
| Mar 20, 2014 at 13:22 | comment | added | Malachi | although you have really good information here, this is more about how my structure doesn't look like your structure, and not so much if my structure is good....I don't know if that makes complete sense, but I like @Mat'sMug Answer a little bit better for this question, I still value your answer though. I will be looking into Enums when I get back to this project. Thank you | |
| Mar 17, 2014 at 19:23 | comment | added | Malachi | I guess I don't fully understand Enums, maybe that should be my next study subject | |
| Mar 17, 2014 at 19:18 | comment | added | BenVlodgi | @Mat'sMug indeed.. I was just making a distinction between Malachi's Gesture class and my Gesture enum :) | |
| Mar 17, 2014 at 19:02 | comment | added | Mathieu Guindon | FWIW an enum is also an object :) | |
| Mar 17, 2014 at 19:02 | comment | added | ChrisW | @Malachi Gestures aren't necessarily a class (with associated behaviour). Instead they can be modelled as a mere value (i.e. as an enum), with "Rules" as a class (where 'rules' define the gesture-gesture interactions). | |
| Mar 17, 2014 at 18:56 | comment | added | BenVlodgi | @Malachi I'm not going against OOP principles by using an enum, even so, using OO is not a C# standard. It is a good practice. In your case, you're not even using OO properly, those objects are just encasing strings and maintaining a list of strings that they interact with. you shouldn't be using strings, you should be using enums... even if you were using Gesture objects, there should still be a gesture enums determining what kind of Gesture object that is. | |
| Mar 17, 2014 at 18:44 | comment | added | Malachi | @BenVlodgi, you speak of C# convention and then you go against OOP Principles because it is "clunky"? Gesture is a class. a Rock is an object. a lizard is an object. a pair of scissors is an object. these are objects and not variables you can create an enumeration of these objects I suppose, but they are still objects. | |
| Mar 17, 2014 at 18:31 | comment | added | BenVlodgi | @Malachi maintain a list of rules, it is sooo much simpler than making a gigantic clunky Gesture class. Then just use an extension method as I did above. | |
| Mar 17, 2014 at 18:28 | comment | added | Malachi | this "Gesture" kills this "Gesture" Vs. Rock smashes scissors "Gesture" Times | |
| Mar 17, 2014 at 18:26 | comment | added | Malachi | they have a property that says what Gestures they beat and what Gestures they lose to. they also have specific kill messages that are not shared. these things are properties specific to Gesture Objects | |
| Mar 17, 2014 at 18:24 | comment | added | BenVlodgi | @Malachi Also... Gestures don't have properties associated with them, which is the reason why an enum works | |
| Mar 17, 2014 at 18:14 | comment | added | BenVlodgi | @Malachi in a case statement you should use use the break keyword to end your code for that specific case. | |
| Mar 17, 2014 at 18:11 | comment | added | ChrisW | @Malachi "as far as stating it's C# convention, which convention are you referring to?" Visual studio IDE editor won't line your braces under the case: it will put the brace 4 spaces to the right of the case, and the code another 4 spaces to the right of that. | |
| Mar 17, 2014 at 17:44 | comment | added | Mathieu Guindon | @Malachi indeed, if (true) DoSomething(); is legal (same for a 1-liner loop), but for maintainability and readability purposes, it's recommended to always correctly scope these code blocks, i.e. use them curly braces and go if (true) { DoSomething(); }. | |
| Mar 17, 2014 at 17:41 | comment | added | Malachi | @Mat'sMug ok I understand that. but I still think that using the brackets on if statements and for loops is necessary, for loops for the reason you mention of scope, and if statements because it defines the ending of the code block, which also has scope, if you have more than one line isn't it mandatory to use brackets? | |
| Mar 17, 2014 at 17:37 | comment | added | Mathieu Guindon | @Malachi #4 is correct, you should use the curly braces to define a scope - the case blocks of a switch statement do not define a scope, by wrapping case blocks in curly braces you are introducing a scope there, which means each case can then define its own local variables, which smells. As for #5, it's also correct, you should spare "egyptian braces" for Java... but using them won't cause any harm (other than a future maintainer would probably CSharpify them - I know I would!) | |
| Mar 17, 2014 at 17:26 | comment | added | Malachi | encapsulation begs to differ with you on creating Gesture Objects rather than creating Gesture Variables. Gestures have Properties associated with them, they should be objects and not variables. | |
| Mar 17, 2014 at 17:25 | comment | added | Malachi | I completely disagree with #4 and #5. you should use brackets where you can. this keeps your code neat and tidy. as far as stating it's C# convention, which convention are you referring to? | |
| Mar 17, 2014 at 16:58 | history | answered | BenVlodgi | CC BY-SA 3.0 |