Technorati Tags:
StandardsI think one of the best standards any team could have in their pocket is the Cyclomatic Complexity metric by Thomas McCabe. It sounds fancy but really it’s just a very good guideline that every developer on your team should use and think about when creating a method every time in code.
It’s simple, your methods get a risk rating based on the following forumual:number of decision points +1
a decision point is just a line in the method where you had to make a decision with code (see the example in Wikipedia).
And part of this metric says to try to have no more than 7 parameters in your methods. Sometimes you may go over but if you are finding that you have so many incoming parameters, you are most likely trying to do too much in that method OR you should have put a lot of those parameters into an object for example, or used an existing object that maybe you did not know exist. Maybe there is a pattern already setup in your code by other developers that you could use. Or there may be another bad design reason why you’re sending more than 7 parameters into your method. But definitely too many parameters is sloppy. There are better ways to do this, again such as sending in an object or whatever else the case may be that you can rid so many parameters.
Keep in mind Methods are meant to organize your code. They are meant to be a UNIT of work. Not an entire process! If you find your method getting beyond 50 lines it may be time to start moving a lot of that logic into reusable methods and calling those methods from your method that you just cleaned up. The whole point of code is not just encapsulation, inheritance, etc. but also that it’s readable for you and others. Who wants to read a 50+ line method every time and multiply that times several that you may have to debug. You are basically making the code as hard to debug as a damn stored procedure with 500 lines at that point.
Reflector has a plugin which will perform Cylcomatic Complexity analysis on your assembly also, so check that out.
Check out the full details about Cyclomatic Complexity. It’ a simple solid metric that you should never disregard and truly enforce on your team and yourself. This is a discipline that’s in the back of my mind every time I write a method because I think it’s a very solid practice.
Technorati Tags:
C#,
Standards,
RantsThere are two major annoyances when it comes to good code and readable code. Here are 2 things that really every team should ensure happens (at least in my opinion 
).
1) Any method should not be more than 50 lines but preferably < 25 if possible. I cannot stand huge methods. The point of OOP is to abstract logic out into manageable pieces. Methods are meant to mainly do one unit of work. Not 5 units to make up 1 unit. Put your logic in reusable methods so that they are not only reusable, but READABLE! I’d much rather see a bunch of case statements in a method but in between calls to other methods to make the entire thing readable.
2) Put the damn curly on the next line:
1: if(something){
2: //do something
3: }
that is the most irritating thing to read. Every time I see that curly on the right, it just irritates me and I move it back down for readability when I see this.
Why doesn’t the person just put it on the next line to make it much more readable:
1: if(something)
2: {
3: // do something
4: }
I mean are we that lazy? Do you REALLY think that the first one is actually more readable? If so I think you were born cross eyed and must see that way. You get an entire page of if statements throughout and nested, you start to see how that becomes very unreadable. If you are fine with it, more power to you but I think it looks like a pile.
I wish programmers would pay more attention to formatting, because it makes code so much more readable and saves so much time overall for anyone who has to read it.
I am kinda open ended on the one-statement after the if decision on whether to include a {}. You are not required in C# to include {} if there is only one statement after the next line in a single if statement without an else. If you are going to make the decision to include the {} then for readability, make sure the first is on a next line and keep it consistent like the last }.
Thank goodness I’m not coding in VB, I’d hang myself with the Subs, End Sub, and all the other extra verbose crap that I’d have to type.
This may seem like something not worth mentioning to some, but really, it makes a big difference and I just don’t get the lazy #2. You can’t debate #1 though and I wish though people would stop making 50+ line methods.
My rant for today.
