|
Steve French posted:it that doesn't have any dumb mistakes I beg to differ.
|
# ? Sep 20, 2014 12:27 |
|
|
# ? Jun 8, 2024 07:56 |
|
Steve French posted:
(I assume you intended the horror to be Ruby DSLs, but if you had something else in mind then do please feel free to point it out.)
|
# ? Sep 20, 2014 12:40 |
|
I used to get that kind of thing in Python because I had no idea what I was doing:Python code:
|
# ? Sep 20, 2014 13:39 |
|
necrotic posted:I beg to differ. Heh, I just meant it as a disclaimer for any additional mistakes made when creating this simplified example. Soricidus posted:
Nope. Not that I like them, just that that wasn't the point of this particular post. This guy gets it: qntm posted:I used to get that kind of thing in Python because I had no idea what I was doing: The last little bit should have been: Ruby code:
So this code is bad for not asserting on the specific type of error expected, but it is also odd that rspec happily catches its own test failure errors. They were smart enough to make the expectation error not subclass StandardError, so it's not caught by the catch-all rescue inside the implementation of operation, but they did not also make the raise_error expectation catch only StandardErrors. Also a lesser horror: weird mixed use of rspec should and expect syntax.
|
# ? Sep 20, 2014 17:19 |
|
I wonder what rspec does if the action under test raises, say, a SyntaxError? https://github.com/rspec/rspec-expectations/blob/master/lib/rspec/matchers/built_in/raise_error.rb#L42-L49 Ruby code:
Ruby code:
code:
|
# ? Sep 21, 2014 01:08 |
|
Deus Rex posted:I wonder what rspec does if the action under test raises, say, a SyntaxError? Yeah, not passing a specific exception to that expectation is really not a good idea. It's also pretty bad of rspec to let people do that by providing a default value; worse that the default value is Exception.
|
# ? Sep 21, 2014 04:32 |
|
eHow posted:Design a script to encrypt the credit card information. Using an encryption algorithm of your choice, create a routine that converts the information into encrypted data. Programming languages such as PHP have built in functions that can encrypt. An example is the base 64 encryption function that can be used by invoking the following code:
|
# ? Sep 21, 2014 22:02 |
|
You didn't really need anything past the "eHow".
|
# ? Sep 21, 2014 22:19 |
|
A few months back Obsidian Entertainment (a games company with a reputation for buggy games) released the beta for their next game. I decompiled it and discovered this monstrosity of a class: Calling an Obsidian programmer out on this over on another forum, I got quote:And? So, my question: is there any way to succinctly explain why this thing is a travesty? I tried writing something up but Christ if I've got to explain why single responsibility and encapsulation are good ideas, I'm not sure there's any hope. coffeetable fucked around with this message at 22:51 on Sep 21, 2014 |
# ? Sep 21, 2014 22:48 |
|
Not exactly sure why you felt the need to decompile a game and try to give a code review to a stranger but okay.
|
# ? Sep 21, 2014 22:53 |
|
That's more like a namespace than a class at that point.
|
# ? Sep 21, 2014 22:53 |
|
carry on then posted:Not exactly sure why you felt the need to decompile a game quote:and try to give a code review to a stranger
|
# ? Sep 21, 2014 22:58 |
|
carry on then posted:Not exactly sure why you felt the need to decompile a game and try to give a code review to a stranger but okay. Obsidian, specifically, is notorious for writing the best drat games ever, but usually ends up releasing pieces of poo poo that take a couple of releases to not crash / not leave the game in an irrecoverable state. For example, Obsidian had to disable Steam Cloud in New Vegas because it was killing game saves, and Obsidian couldn't figure out how to fix it. On the other hand, after some visual modding it was a blast to play and years after its release, a friend of mine was still finding new and interesting plot interactions in his playthroughs.
|
# ? Sep 21, 2014 23:06 |
|
coffeetable posted:My God—it's full of stars! It's an anti-pattern. This one: http://en.wikipedia.org/wiki/God_object
|
# ? Sep 21, 2014 23:06 |
|
Brain Candy posted:It's an anti-pattern. Except the large character class isn't a "God object" because it's not controlling the entire program's execution. It's just a store of a ton of information here and that's not too bad as things go.
|
# ? Sep 21, 2014 23:14 |
|
Somehow, after all that, I ended up finding this wonderful thing: https://web.archive.org/web/20060317085650/http://www.national.com/rap/files/datasheet.pdf
|
# ? Sep 21, 2014 23:28 |
|
The only reasonable way to critique a design is to provide an alternate design. For example, which things don't belong on a character? You could fold a bunch of the attribute-related ones to a fewer parameterized manipulators, but I'm not sure I'd actually prefer that design.
|
# ? Sep 21, 2014 23:30 |
|
hobbesmaster posted:Except the large character class isn't a "God object" because it's not controlling the entire program's execution. It's just a store of a ton of information here and that's not too bad as things go. That link I posted posted:god object is an object that knows too much or does too much. Note the "knows too much". If you can't replace an object with a different object you aren't doing OO. That isn't always bad, but megablobs are definitely a bad smell.
|
# ? Sep 22, 2014 00:20 |
|
Brain Candy posted:Note the "knows too much". There are likely to be many characters that are being tracked and they could easily subclass that for different types of characters (idk, say expansion character or GM or whatever). Do you think having long application, window or widget classes in a framework is bad too?
|
# ? Sep 22, 2014 00:31 |
|
coffeetable posted:A few months back Obsidian Entertainment (a games company with a reputation for buggy games) released the beta for their next game. I decompiled it and discovered this monstrosity of a class: Taken out of context, I feel it's unwieldy and has no clear class to it, instead it tries to cover every class of character within the game it seems. It sucks but I can understand the programmer defending it. However, in context, the class is deriving MonoBehaviour so I guess this is a Unity3D game? A manageable project should be following the entity-component pattern Unity is designed around and lays out for you to follow. It's not a good idea to work against it. For example, there is a CanCastSpells flag in that class, but the Unity way to do that would be a SpellCaster component which can be added and removed to change the entity's state. To see if the entity is in a spell casting state, the existence of the SpellCaster component is checked rather than doing it through a fixed member.
|
# ? Sep 22, 2014 00:53 |
Brain Candy posted:If you can't replace an object with a different object you aren't doing OO. If you exclusively program in OO you are a bad programmer.
|
|
# ? Sep 22, 2014 01:29 |
|
down with slavery posted:If you exclusively program in OO you are a bad programmer. More smalltalk discrimination.
|
# ? Sep 22, 2014 01:32 |
|
Yeah that's pretty typical for a game character class in any game let alone an RPG. You can bet each function in that class ended up reading from and writing to many aspects of the character, and that those rules were probably changing every day during the pre-production phase when they were experimenting with how the game would play. Sometimes you get a chance to go back and refactor out anything that can be, but that's rare when there are bugs that will actually impact consumers to fix.
|
# ? Sep 22, 2014 01:39 |
|
And if you really think you can do better... http://www.obsidian.net/jobs/open-positions/programming/447-engine-programmer
|
# ? Sep 22, 2014 01:48 |
|
The fact that there was any response from the developer other than "Please stop decompiling our game code. If you would like to file a specific bug report, please do so at <URL>" is the true horror. Bothering to engage with people giving unsolicited code reviews is just a giant can of worms, and doing so on a forum just leads to endless bikeshedding. As well, if this is a Unity game then nearly any horror a dev is going to construct in Unity is eclipsed by the horror that is Unity itself. ErIog fucked around with this message at 02:18 on Sep 22, 2014 |
# ? Sep 22, 2014 02:15 |
|
ErIog posted:As well, if this is a Unity game then nearly any horror a dev is going to construct in Unity is eclipsed by the horror that is Unity itself. I'm not doubting that Unity isn't garbage, but is there any articles or posts that goes in detail on why it's garbage? Also, while searching for any article like that, I found this: forum.unity3d.com/threads/programming-languages-considered-harmful.18009/
|
# ? Sep 22, 2014 03:05 |
|
HardDisk posted:I'm not doubting that Unity isn't garbage, but is there any articles or posts that goes in detail on why it's garbage? Come on, he created a computer game 15 years ago for a friend. That means that his opinion is insightful
|
# ? Sep 22, 2014 03:26 |
|
HardDisk posted:I'm not doubting that Unity isn't garbage, but is there any articles or posts that goes in detail on why it's garbage? You can read about all the problems with Unity here: http://forums.somethingawful.com/showthread.php?threadid=2692947 I think a lot of discussion of Unity problems started around page like 305 or something, and gets reignited whenever there's some new announcement about it. The main issues stem from them trying to solve every problem by throwing more programmers at it, and they chose to fork Mono instead of just licensing the existing version. This might have been fine if they had been diligent about updating it, but they haven't at all. So it lags behind a zillion years. They announced plans to try to fix these issues in May, but those plans, unsurprisingly, involve tasking more programmers with reinventing more wheels. Then you compare it to something like Unreal Engine, and you just start to wonder what they're thinking. Here's the blog post where they lay out their master plans for fixing the issues that stem from their tremendously out of date Mono fork: http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/ Most of the ire toward Unity in the game dev community is somewhat recent, though. So I wouldn't really blame anyone for having picked it for their project that's been in development for a long time. If a dude's got time to decompile and bitch about what he finds online then the Unity engine itself a much more target-rich environment for horrors. ErIog fucked around with this message at 04:10 on Sep 22, 2014 |
# ? Sep 22, 2014 04:01 |
|
coffeetable posted:A few months back Obsidian Entertainment (a games company with a reputation for buggy games) released the beta for their next game. I decompiled it and discovered this monstrosity of a class: Edit: If you want Unity horrors, there's plenty of operator overloading, hidden side-effects and many more abuses of the C# language (all running on a dated and customized Mono interpreter which is incompatible with most outside libs, naturally). SupSuper fucked around with this message at 04:12 on Sep 22, 2014 |
# ? Sep 22, 2014 04:07 |
|
SupSuper posted:It's a D&D CRPG. Every character is gonna have a massive character sheet tied to their backs (note that it's a class dedicated solely to CharacterStats, not even getting into the Character). While it's possible you could segregate stuff like bonuses and effects and such into subclasses, there's no guarantee the game rules won't need them all to do calculations anyways, making it a very inter-dependent component system. Hope you don't accidentally call TriggerWhenHit() instead of TriggerWhenHits() I guess that it's possible that the classes listed here aren't all-encompassing. It would be really swell to have classes for races like Orcs and Humans, and then classes for professions like Wizard and Barbarian, that all inherit from BaseStats. It's totally possible that that's actually what has been done, and we just haven't been shown those class definitions. We can hope QuarkJets fucked around with this message at 07:52 on Sep 22, 2014 |
# ? Sep 22, 2014 07:44 |
|
i can't put together a proper reply this morning because ive got work and thisSubjunctive posted:The only reasonable way to critique a design is to provide an alternate design. QuarkJets posted:It would be really swell to have classes for races like Orcs and Humans, and then classes for professions like Wizard and Barbarian, that all inherit from BaseStats. http://pastebin.com/PgtgPDPC
|
# ? Sep 22, 2014 08:15 |
|
hobbesmaster posted:Except the large character class isn't a "God object" because it's not controlling the entire program's execution. It's just a store of a ton of information here and that's not too bad as things go. Well, it does seem to contain a huge number of enums for things like (character) classes, races and cultures. Some of these should probably be proper independent classes, as this smacks of some ugly type-case/switch statement somewhere. Or best of all: move that stuff to data files loaded at runtime, rather than baking it statically into the code.
|
# ? Sep 22, 2014 08:16 |
|
coffeetable posted:i can't put together a proper reply this morning because ive got work and this Well then I retract my statement. An RPG game is probably the most obvious use case for class inheritance.
|
# ? Sep 22, 2014 08:22 |
|
coffeetable posted:A few months back Obsidian Entertainment (a games company with a reputation for buggy games) released the beta for their next game. I decompiled it and discovered this monstrosity of a class: The video http://vimeo.com/9270320 makes a lot of points and actually has researched them. One of the conclusions that lines of code is the best metric that actually works, the more you have, the more bugs you have, and humans can't really manage more than 200 lines of code at once. The fellow who wrote that class is the only person who can possibly understand it. There's also a less well researched article called Norris Numbers which is more about total lines of code, and how if you've got a big project, you really need good abstractions to be able to work with it as soon as it gets beyond 2000 lines of code.
|
# ? Sep 22, 2014 09:02 |
|
Honestly the big stack of fields and properties looks fine to me. Yeah, you could split it up into a bunch of highly-interconnected nested classes, but all that that would achieve is making it a bigger pain in the rear end to tweak things when the design changes. The bigger issue is all those methods - a lot of them would be better served in logically-separate utility classes (the level-up stuff, for example). If that's what the OP was talking about they should probably have just put in a screenshot of the methods instead of the whole thing, because the big stack of fields and properties looks a whole lot like necessary complexity, and leading with it makes it look as if you're saying "big = bad" and don't actually really know what you're talking about.
|
# ? Sep 22, 2014 09:46 |
|
QuarkJets posted:Well then I retract my statement. An RPG game is probably the most obvious use case for class inheritance. Composition is much more maintainable and having a standard class with all character attributes seems pretty logical to me in that context, even if you have a gazillion attributes.
|
# ? Sep 22, 2014 09:47 |
|
coffeetable posted:A few months back Obsidian Entertainment (a games company with a reputation for buggy games) released the beta for their next game. I decompiled it and discovered this monstrosity of a class: Throw them a link to Clean Code by Uncle Bob - that might be helpful, or why not a link to SOLID S ingle Responsibility Principle O pen Close Principle L iskov Substitution Principle I nterface Segregation Principle D ependency Injection
|
# ? Sep 22, 2014 10:19 |
|
M31 posted:It's seems like a good fit, but in the real world it doesn't work. You can make an Orc class, but then you get an PlayableOrc and a NonPlayableOrc, and the NonPlayableOrc has a friendly version and a non friendly version, etc.. And C# does not have multiple inheritance. I haven't devved a game, but it really looks like inheritance creates more problems than it solves, especially if your toolset only has single inheritance. If you must use classes you'd preferably have some sort of multiple inheritance system like mixins, Scala's traits, etc. Feels like the more coupling in your class structure, the more painful balancing may become once the game is of adequate complexity, let alone finding/fixing bugs. From the outside looking in it feels like Entity Component System are the best way to represent game worlds in a decoupled way, is that correct or are there better approaches?
|
# ? Sep 22, 2014 10:44 |
|
coffeetable posted:A few months back Obsidian Entertainment (a games company with a reputation for buggy games) released the beta for their next game. I decompiled it and discovered this monstrosity of a class: Yeah, I don't think you have much ground to stand on here. It does have single responsibility and encapsulation, there's just a lot of stuff there because it's an RPG game and characters in a RPG have a lot of stuff involving them. Sure you could hack it into smaller classes, but that wouldn't necessarily make it cleaner, easier, or more logical to use. There's just a lot fields, because there needs to be, and a lot of code involving these fields, because code dealing with these fields may best be associated with the object that has them.
|
# ? Sep 22, 2014 10:44 |
|
|
# ? Jun 8, 2024 07:56 |
|
M31 posted:Composition is much more maintainable and having a standard class with all character attributes seems pretty logical to me in that context, even if you have a gazillion attributes.
|
# ? Sep 22, 2014 10:48 |