Development Techniques/Style/Etc

Dec 22, 2008 at 8:13 AM
I posted this:

To the other contributors:
I have been told by a guy that I work with that I should post a warning label on this project. He says that my habit of refactoring mercilessly could offend other developers in the wild who might think that I am disrespecting their code. I hadn't thought of that, but it is probably true. If you don't work in an agile shop that encourages refactoring and general code cleaning during every phase of development, you could be offended when I change the code you have submitted. I hope this doesn't bother anyone. I truely believe in the principle of shared code and that only together will we create the best software possible. I really am grateful for the contributions that each of you has made and I hope that you will continue to make more as the project progresses. I have already learned something from each of you and I hope that you are also learning from my style. Anyway, thanks again and please don't be
offended if I change a variable or class name here or there.

lachoneus8 responded with this:

Long live aggressive refactoring! My only concern is that for developers that can't maintain a regular pulse of the project, there may be a minor ramp up time each time the project sees major changes. The SVN comments seem pretty good though, so that will help. The only other thing is to maintain some code documentation, at least at the class level to aid people reading and understanding how the pieces fit together.

Personally, I'm always looking to learn from other developers' styles, especially on a project with such great utility and potential as this.
Dec 22, 2008 at 8:19 AM
Edited Dec 22, 2008 at 8:19 AM
I guess my first thought is "Comments are lies."  Which I think came out of the Pragmatic Programmer, but is could just be a random Bob Martin quote.  Anyway, my personal motto is "Comments are great because they help us identify the places where the developer was too lazy to do it right."  Which is another Uncle Bob quote.  I know this is a hotly contested point of view, but because I agree with it, you will hardly ever see my leave comments in my code, but you will often see method names that look like sentences describing what the method does.  I'm still reading and enjoying Clean Code though, so we will see what I think at the end of it.

If someone else leaves comments, I will probably leave them alone, unless I think the code is better served by integrating the comment into the names (variables, methods) around it. . .

Just my 2 cents.

Oh yeah, I hope that the classes, methods, properties, etc are clear enough that anyone with a working knowledge of the domain (D&D 4e) should be able to understand them without further instruction.  If that is not the case (and the MVP pattern/testing come to mind), perhaps we do need to put in some training/instructional links.

2 more cents.
Jan 9, 2009 at 1:03 PM
Perhaps its my lack of experience in the Extreme Programming world, but some of the interactions and terminology were confusing at first glance.  What is a presenter for example?  It seems to be somewhere between the controls and the data, but I'm not sure how that fits in.  What exactly constitutes a service?

I agree self-documenting code is a great thing, but when it takes a few years of experience in a high-paced software environment or the right degree to undestand it, how do you get versed into it?  Is there a specific book that is a prequisite before you can join in an open source product managed like that?

Don't want to come across as harsh, just playing devil's advocate.  I'm a converted C++ guy with a computer engineering degree so I don't have a lot of theory background, and most of what I've learned is self taught when I need to know (I haven't ever picked up a style book for the read, and haven't ever cracked a C#/Java book other than as a reference).  Perhaps its just me.  This said, I do like the organization of the project and would love to learn what makes a high-level software shop churn out great code so quick.
Jan 10, 2009 at 10:10 PM
Ah yeah, those are good questions.
First of all, here are some books that you will find helpful (I might say essential):
  • The Pragmatic Programmer - Pretty much essential for all serious developers, this book covers a lot of basic concepts that seem fairly obvious, but actually make you think.  The one drawback is that it is about 9 years old, so a few of the concepts that they talk about are a little deprecated.
  • Clean Code - This one is great.  Robert Martin doesn't pull any punches and he will help focus your development style and techniques to make your code clean and easy to read, which is the key to self documenting code.
These next 2 are all about domain driven design.  The Evans book is the original and the Nilsson book is updated for C# and covers some additional topics.  Either would be a good read:
You are probably familiar with design patterns as a C++ developer, so any book that you pick up on that would be good, or you can just go to the Martin Fowler's site to get details.  The presenter is part of the MPV pattern of Dependency Injection.  Basically, I am using the Passive View pattern in which the UI layer of the app (the View) has only trivial or extremely UI specific code.  When the View is instantiated, it is injected (through the constructor) into the Presenter, which is the brain of the presentation layer.  The Presenter handles all of the events from the View and all of the interactions between the UI and the Domain. Part of the reason for this is that using dependency injection allows us to more loosly couple the components and pass in mock objects for testing.  The Domain is seperated into 2 parts: the Entities, which are objects that are things (think nouns: PlayerCharacter, Weapon), and Services, which do things-usually to the Entities (think verbs: Import, Save, Load, Validate, Convert).  Basically, in order to preserve Orthogonality and observe the Single Responsibility Pricinple, an object that is a thing does not operate on things.  A Weapon doesn't have a Save() method; saving is deffered to the WeaponRepository which does nothing other than Save and Load Weapons.

I hope that makes some of the design decisions a little more clear.  If you have other questions, I would be happy to address them.  Of yeah, you might be able to find something of use on my blog as well: