Question

How can I determine or tell if a set of classes are “spaghetti code”?

Should I look at my code as being spaghetti when I generate a Dependency Graph in Visual Studio under the Architecture menu, and see that there are a lot of curvy arrows pointing all over the place?

I always avoid the problem of spaghetti code by attempting to reduce the amount of dependencies between the classes. When doing so, yes, the Dependency Graph indeed becomes neater. And when I make changes to certain part, because the classes have little dependency between each other, I don’t have to worry about messing up the other classes.

But, by doing this method, sometimes, it appears that I have to repeat some code. For example, I could have the following object that’s stored in a list:

class DataBlock {
   public int id;
   public string name;
   public SomeObject dataObj;

   public Object[] Data1 { get { return dataObj.RetrieveInfo(); } }

   public Object[] Data2 { get { return dataObj.SomeProperty; } }

   public bool DoCompare(obj) { ... }
}

So, there is a list called DataList of the type List<DataBlock> consisting the above object.

And then now, suppose I am going to dispatch an event that will include some information from DataBlock. I could include this whole DataBlock object into the EventArgs. The handler function can then just do this:

void Handler(MyEventArgs evtArgs) {
   DataBlock data = evtArgs.Data;
   var firstData = data.Data1;
   data.Data2;
   firstData.DoCompare(data.Data2)
   data.name;  //etc, etc
}

This is convenient. But, this would also mean that the class that has this handler will then now have dependencies on the DataBlock object. So, one of my ways to get rid of this, is within my EventArgs, I repeat all those informations from DataBlock, like this:

class MyEventArgs : EventArgs {

   public MyEventArgs(id, name, data1, data2) {
      ID = id;
      Name = name;
      Data1 = data1;
      Data2 = data2;
   }
   public int ID { get; private set; }
   public string name { get; private set; }
   public Object[] Data1 { get; private set; }
   public Object[] Data2  { get; private set; }
}

By arranging my EventArgs this way, both my EventArgs and whichever class having the event Handler will not have dependency on the DataBlock. Only the firer of the event knows about the DataBlock and it rips off the data from DataBlock and put them into MyEventArgs via its constructor. However, now, the problem in this is, the MyEventArgs is repeating every getters/setters that is inside Datablock. And, I also lose access to all helper methods within DataBlock!

This is just a small example of a problem that I often face. There are more serious ones where I found myself repeating the getters/settings for a few classes, just because I want to reduce the dependency.

Other problems that I face that show up a lot of arrows on the Dependency Graph, is when, say, I have an interface called ISomeObject. Because the ISomeObject is a popular object within the classes, the interface is used by many other parts of the classes. In the end, there are tons of arrows pointing to the ISomeObject. Would this imply spaghetti code too?

It’s difficult for me to explain the problems I face when I want to keep my code organised. But I hope the examples above are enough to illustrate what I want to tell.

So, what are the best practices for a scenario like this? Should I determine that my code is spaghetti when the Dependency Graph in Visual Studio shows a lot of messy curvy arrows pointing all over the place?

Answer 1

I honestly believe that spaguetti code ins’t something tied to dependencies or such higher level things.

Spaguetti code is an anti-pattern that consists on creating a highly-coupled code with no order and completely irrational, meaning that author – programmer(s) – will hardly explain code flow for you.

One of most important symptoms of spaguetti code is that it’s unmaintainable: if you fix a bug, it creates one or more bugs. When you fix these bugs, you get more bugs. And finally code is fixed by hardcoding garbage everywhere.

Again, I doubt that a large object graph with a lot of dependencies would be “spaguetti code”.