Ok, BDD excitement aside, let me return to the original problem (which is that I spend a lot of time dealing with poorly written code by people on the team not implementing good coding practices). Assuming (for the moment) we cannot change the team sizes, is there any other advice? I know a lot has been given already (and I am truly, truly grateful)- but some of it is a bit over my pay grade.

The only thing I know we can do is that we absolutly can create a list of "Thou Shall" and "Thou Shall Not" coding rules. In fact, this is what my manager wants to do. IF we move foward with this, is there any advice on some good things to put on this list? My thinking thus far is

-Developers must write test for any piece of code that a) does not talk directly to external resources b) is in the view (xaml or code behind) c) is otherwise excused by a TA

-Developers will not check in code without corresponding unit tests unless excused by a TA

-Developers will not check in methods with more that 5 (totally pulling that number out of my nether region- is there a good number here?) control statements (If statements- loop statements, etc.) unless excused by a TA


That last one feels terrible, but how else can I quantify "Write modular code"? I actually don't mind long methods, as long as they don't have many control statements (that is, a 200 line method containing purely assignment statements doesn't bother me in the slightest).

Am I totally on the wrong track here? Is there another way to force developers who are writing difficult to maintian code into writing better code? Also, this doesn't really address the concept of complicated classes that are doing too much. I don't really have an answer for how to curb that, espcially since our ViewModel design is pretty messy, so implementations tend to be messy. Can't really fault people for that. Beyond that, we have some classes that contain tons of procedural code that have gotten pretty big, but I don't find them to be difficult to work in. If a class is just a container of procedural code, it's not that hard to figure out. It's when a class is actually an object with state that getting big makes it difficult to understand. So it's difficult to say "Classes must be less that xyz size". I suppose you could say "Classes that maintian state and are not ViewModels must be less than 300 lines of code" or something like that.

Finally, how do you enforce any of this? I doubt we can dock pay- but what if a developer continues to not write unit tests or big messy methods?