.NET Brisbane, Australia

Tips on how to improve cohesion in a software design

For the novice in object-oriented programming one of the biggest challenges faced is the new mindset introduced by the OO concept: to be able to think and to model the world in a set of objects and its respective methods.

Every time I take part on a project where the people working are not used to this programming style (using the Microsoft Solution Framework of course) I notice that the main question marks are: what to aggregate? what to specialize? What to move to a super-class? what to leave as module specific operation?

Why do the people have this problem?

IMHO and as far as my experience tells me, I would say 80% of these issues are related to the fact that they are no longer be using the terrible global variables in their programming. and we know how hard is to let go this bad habit once you are used to it and specially if they are coming from a language where the untyped variables can be freely used, as in the classic Visual Basic.

And because those guys now are not using global variables anymore the first effect we notice in the development metric the low cohesion. The cohesion is what is going to bind in the relationship between object and its own operations, making it (the object) responsible for their actions and at the same time not having to worry about who is going to be calling them (the methods). A high cohesion is generally a very nice thing to have, because it introduces a resposability layer that only the methods will be aware of it. For instance: the process of getting a value (i.e.: an account balance) can introduce a change in other places (i.e.: some internal counter limiting the number of requests per minute) and the caller should not bear the responsability of this change.

For these people and these cases I usually show a little trick that now I share with you guys.

1st: Think of the data and its operations like eternal lovers. They are always together in the same domain, they always walk around as a pair no matter where they go. As an exercise take a moment and put everything you are about to develop under a helicopter view, try to draw a diagram grouping the objects and its methods like the one below:

 

2nd - if you are using too many nested 'if', you probably should be using 'cases/switches'. If you are using too many 'cases/switches' you probably should create an enumerator for those values. If a value needs to be accessed from somewhere outside the scope, create a method just to return this value. This technique outlined here in the 2nd rule is proven to be a great public variable killer, thus helping to enforce a good cohesion.

Now, let's go to the cohesion point. Enumerate the objects you are going to deal. Enumerate the methods you are going to call. Draw a matrix with them in a way that you can see who (object) is calling who (methods), like the one below:

 

Cool, hun? Now let's analize the data and for that you just have to remember your high school days: That's a popularity contest.

 

Pick the most popular methods. They will give you a good direction of the objects that are candidates for high cohesion, and even maybe to inherit from a future super-class opening a space for a better model abstraction.

 

 
I know this is not a 100% rule but everytime I do this exercise with my colleagues we always find the light at the end of the tunnel. If you have other suggestions or if you do this analisys in a different or not usual way, please share with us.

See you later.

SAFECode and Security Best Practices

MSDN and Version-Specific Content

Can anyone point to me which one is the correct procedure to create a custom exception class?

"Do not derive user-defined exceptions from the Exception base class. For most applications, derive custom exceptions from the ApplicationException class." - http://msdn2.microsoft.com/en-us/library/seyhszts(vs.71).aspx


"For most applications, derive custom exceptions from the Exception class. It was originally thought that custom exceptions should derive from the ApplicationException class; however in practice this has not been found to add significant value." -  http://msdn2.microsoft.com/en-us/library/seyhszts.aspx

If you look close enough you will notice the way the content page was built. One was done when the current version was .NET 1.1 and the other one when .NET 2.0 was out, which still applies to the .NET 3.5.

So, next time you come searching for content at MSDN, it is a good practice to see to what version it applyies.

.NET Framework Naming Conventions and Styles

 

 

The bosses are walking across the office as crazy, shouting, shaking papers, nervous...and they are everywhere. And they are asking for Tommy.

Tommy is The Developer, and he has seen this scene before. He knows that another application will be delivered by Friday, and it must be ready for the users on the same day. This is a high priority application.

He works long hours, drink lots of coffee, and fix and release the application as usual. Friday comes:

- Tommy is happy. He is not carrying anymore that heavy burden to deliver the product by Friday.

- The users...well, they are happy. They are just typists anyway, but they are happy.

- The Boss is happy. He finally can show his progress to his boss (yeah...everyone have a boss, even The Boss). 

Congratulations to everybody, nice party, Friday drinks. Tommy goes around like a happy-Larry.

Monday comes and Tommy has to move on. He's been doing this for too long and now he has way too many applications under his umbrella. The company hires a new developer to take care of Tommy's applications.

The next morning someone screams: That's the new hired guy. He almost had a heart attack just looking at Tommy's code...or should I say: His spaghetti.

I think you agree with me, this is not a very hard scenario to imagine, specially if you work in a market where the pressure is always on. I know many people who are great dealing with projects and deadlines, but unfortunately because of "external factors" they must produce something "for yesterday", otherwise the boss won't be happy. And the final result normally is a bunch of applications with almost nothing in common and lacking a very basic thing: Coding Standard.

Microsoft is great when it comes to provide the guidelines for coding practices and stardards (Microsoft Standards, in the case) and you can literally find hundreds of pages about this subject at MSDN.

You can there and read them all by yourself, it is really good reading I am sure of that, but if you are like our friend Tommy and has no time for reading I've gathered the main ones and collected them here for you to save yourself some time:
 

• Use Pascal casing for type and method names and constants

public class MyClass

{
   const int ConstantA= 100;
   public Mymethod( )   {}
}

• Use camel casing for local variable names and method arguments

int internalValue;
void MyMethod(int theParameter){ }

• Prefix interface names with I 

interface IMyInterface {..}

• Private member variables starts with m_ (as in http://msdn2.microsoft.com/en-us/library/aa479858.aspx but very debatable as someone commented)
  
• Custom attribute classes finished with Attribute
• Custom exceptions finishes with Exception
• Methods are named using verb and objects

protected void ShowForm( )

• Functions are named after the returning values description

GetAccountUserName( )

• Alway use clear and well described variable names
• Avoid variable names with just one letter, such as i or t. Call them index, counter or temp instead.
• Do not use Hungarian notation for public or protected members
• Do not abbreviate words
• Always use .NET predefined types, instead of the aliases in the System namespace.

use object instead of Object
use string instead of String

• For generics, capital letters for types. Reserve suffixing Type only when you are referring to the .NET Type 

//Correct:
public class LinkedBankAccountList<InternalKey,Data>{...}

//Wrong:
public class LinkedBankAccountList<KeyType,DataType>{...}

• Give the namespaces a good well-formed name, not some mnemonic
• Avoid fully qualified type names in the code. Use the using statement as much as possible.
• Avoid placing a using statement inside a namespace. (that's a very tricky one)
• Group all framework namespaces together and put custom or third-party namespaces underneath and at the end

using System;
using System.Data;
using MyCompanyDataAccess;
using ExternalCompanyLogicObjects;

• Use delegate inference declared instead of explicit delegate instantiation

delegate void DelegatePrincipal( );
public void MyMethod( ) {...}
DelegatePrincipal thisDelegate = MyMethod;

• Do not use tabs or nonstandard indentation, like one space keystroke. Microsoft recommends three or four spaces
• Comments must be indented at the same level of indentation as the code referred by the comment
• Member variables are declared at the top, with one line separating them from its properties or methods
• Declare a local variable as near as possible to its first use. Release the object, if needed, as soon as you can when its task is finished
• A filename should reflect the class
• When using partial classes, name each file after the logical part that class describes

//MyClass.cs
public partial class MyClass
{...}
//MyClass.DataAccess.cs
public partial class MyClass
{...}

• Place an open curly brace ({) in a new line. Avoid the butterfly indentation.

If you guys have any suggestion to the list or you do anything in a different style in your organisation, let us know in the comments, ok?

See you later.

How to Write a Safer and Better Code ?

 

TeamSystem and TFS add-on to Count Lines of Code and Predict Errors

 

Old Memories, Hard Disk

Do you remember those days ?

How To Make a Productive Project Meeting ?

• Every meeting MUST have 3 elements: purpose, agenda and maximum duration. If any of these items is missing, the meeting is meaningless and should not happen.
• Make sure you are able to define a purpose for the meeting in a maximum of 2 sentences, for instance:"This meeting is to plan the new developments for the project X". This way, everyone will know why they are there, what needs to be done and how to proceed in order to well-succeed.
• Define a clear agenda in advance. Make a list of all the items to be discussed, revised, analysed, displayed etc. When I conduct meetings, my personal strategy is to allocate a time limit for each item in the agenda and to assign the responsability to lead the discussion to someone in the group. Works as a charm.
• Define a duration for the meeting, how many minutes/hours it should last. From the start make crystal clear to everyone what time the meeting will start and, sometimes more importantly, when it will end. It is amazing the number of managers who have absolutely no control of their meetings and do not know how to enforce the finishing rule. If you think you have this habit...CHANGE THIS !!!
• Do not wait for the delayed people. Meetings must start on the agreeded time. Do not wait about late arrivals. Do not wait for those who need to be called for the meeting. You just make sure everyone gets notified, then when someone arrives after the meeting have started, DO NOT STOP TO REVIEW WHAT WAS SAID. Do this as a proof of respect to those who arrived on time.
• If the meeting's organizer is late, Consider the meeting cancelled, and get back to work. How long is considered late? Depends on the company, but I would not wait more than 5 minutes.
• Document your meeting. What I do is to put someone in charge of writing down the notes. What to put in the meeting notes? Basically the name of the attendants, the discussed subject, the agreed points, the next developments and/or actions with dates and their respective responsibles.
• When the meeting is over - do not wait more than 24 hours - the meeting notes must be sent to: All the participants, to those who could not make it to the meeting and to those who might be influenced by upcoming decisions.
• Keep the focus. Every meeting must have a regulator to notify the others when someone is discussing any subject outside the scope of the current topic. Ask one of the presents to volunteer for this task when the meeting is about to start. His/her task is to interrupt the meeting at any given time when the focus is lost and bring back the main subject. This new outside topic can maybe then be noted and even can be discussed in future meetings. In case of doubt regarding a specific topic being in or outside the scope, the meeting organizer has the final word.

I hope these notes can be of any help in your next meetings. If you have any comments or other meetings ideas, please feel free to leave them here and share as well.

See ya later.