The data presented here shows that tangled packages/classes are quite common. This suggests that the belief that tangling is a *negative* property, is in odds with reality (Of course, this is not a scientific study).
In the Mythbusting post I said that tangles of packages are benign. I based this claim on the fact that many successful libraries contain such tangles. In particular, I said that 20 out of 23 libraries that are bundled with the Spring framework, do contain tangles. Here are the actual graphs of five libraries/tools which you might be acquainted with.
These images were produced by Structure101.
Update 1: Added the preface (as per vinod's suggestion)
this shows nothing, apart from the fact that tangles occur quite often in code. if you bothered to look into some of these structures in more detail, you'd see that some of these cycles represent real issues and also prevent reuse. in the junit case the cycles prevent you from reusing the annotations without pulling the entire library along...
BTW - i've got absolutely no affiliation with structure101 or headway, but i'm annoyed. you are unfairly maligning a great tool that has come in very useful to myself and many others, using poor reasoning. If you want to know why your reasoning is bad, make sure you understand Bob Martin's work on dependencies: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
Anonymous
December 1, 2008 at 12:27 AMAndrew: "this shows nothing, apart from the fact that tangles occur quite often in code.".
If a certain property is common, in a statistically significant manner, in successful projects, then it is quite natural to assume that this property is a positive trait. However, the common belief is that tangles is a negative trait. The data given here suggests that this belief is in odds with reality (Of course, this is not a scientific study).
"in the junit case the cycles prevent you from reusing the annotations without pulling the entire library along..."
In order to satisfy the needs of every possible client one will have to decompose JUnit into an exponential number of sub-libraries, which is clearly not doable. It seems that a vast majority of library writers prefer to release tangled code rather than providing the ability to reuse each module independently. This is valid compromise and developers should be aware of that.
"you are unfairly maligning a great tool" - I am really sorry if this is the impression. My criticism is on the approach that depicts static cycles as evil. IIRC I didn't say anything bad about Structure101 itself (which seems to be very reliable and easy to use).
Unknown
December 1, 2008 at 1:55 AMItay,
It seems to me that if you'd put into your post what you've put in you comment above, your stand would be much more understandable.
it is true that a lot of code out there is tangled. but to say "tangled = good" as a result of that seems as religious and arbitrary as saying "untangled = good" (which i dont think is the thrust of static analysis - at least not in normal, non-academic use; its more like "suitably untangled=better manageable = good", imo)
Anonymous
December 1, 2008 at 2:10 AMVinod,
First, thanks for the tip.
Second, I tried to be as non-religious as I can (hence the understating tone to which you referred in another comment). People are so attracted to hard data, such as the one produced by static analyzers, that they don't reflect on questions such as: "what does the data mean?", "what's the correlation to desirable properties?". In a sense, this is my attempt to raise these questions.
Unknown
December 1, 2008 at 9:32 AMI use Structure 101 to remove cycles from JUnit code as often as possible. Often, I find that removing cycles improves other desirable design properties. There are some cycles that were introduced, especially early in the 4.x iteration, that I regret, because they've led to surprises down the road. However, a widely-used library doesn't get much freedom to deprecate names.
If you'd be interested in my transformed Structure 101 diagram, let me know.
David Saff
December 2, 2008 at 6:35 PMDavid,
I can certainly accept the fact the S101-like tools may provide useful information. I think that programs are inherently so complicated (I just wrote about it here) that in the vast majority of the cases the provided information is not more than a hint: you need additional reasoning to decide whether there's a real problem.
Too many times people tend to forget this point. They are drawn to decisive statements such as "tangles are evil!"
Anyway, I am interested in seeing your diagrams and hearing about the specific aspects of your code that S101 helped improving.
Unknown
December 3, 2008 at 12:42 PM