I am familiar with the term "highly coupled" but am curious if there are signs (code smells) that can indicate that code is highly coupled. I'm currently working with Java EE but this can apply to any language.
Edit:
In case anyone's interested, this article sounds helpful: In pursuit of code quality: Beware the tight couple! (IBM)
The number one indicator of badly coupled modules in my opinion is bilateral dependencies. For example, Module1 one calls some function in Module2 and Module2 calls some function in Module1.
Most interfaces should be unidirectional. If the module that was called needs to pass some information to the calling module that is not returned as part of the call then it should use some sort of message passing or event triggering mechanism such as a message queue. Ideally, the handle to message passing interface should be passed in during some initialization or registration process. This completely abstracts the interface in such a way that the module does not actually care who the event is for...hence it is decoupled.
Another indication is when one module is constantly calling some other module for some specific data set. This should make you question who should actually own the data set. Why is it that this module in question always needs to see data that belongs to some other module?
A third tool so to speak is to ask yourself, "Can I pull this module out and replace it without requiring changes to other modules.
This is by no means a exhaustive list, but they are the top three things I ask myself when designing software.
The old design saying is, "You can touch your friends, and you can touch your privates. But you can't touch your friends privates." That's coupling in a nutshell.
Signs of highly coupled code include very large interfaces that let people know about private details of the implementation, and objects that seem to "know a lot about each other". There are tools for automatic analysis that will flag code that looks tightly coupled for you. See http://www.scitools.com/features/metricsintro.php for a random one. (I have no idea how well it works. It just turned up fairly high in a Google search.)
Try writing some unit tests for classes. If you can't easily test classes without the need to create/mock loads of support classes or a db/ui whatever then it's a sure sign of bad coupling/dependencies.
It's also one of the best cures, but you have to do it during the coding (like TDD) to keep you honest.
The obvious sign to me is that everything is public.
The other sign is Law of Demeter violations -- excessive this.SomeObj.SomeProp.SomeProp references on non-fluent interfaces.
I once saw what I've since dubbed a "puppetmaster class" that built a data entry form on-the-fly. It had several other software design violations so excessive coupling was the least of its concerns.
When it retrieving data from the controls it created, it did so like this:
var control = activeDataEntryControl as CustomTextBox;
if (control != null)
result = control.NestedTextBox.Text;
/* several other controls */
The Ripple Effect.
Every change has a ripple effect through all the tightly-coupled modules.
The "Open-Closed" principle has been violated in that it's not properly closed and change leaks out.
Check the number of #include/imports etc between classes/packages/dlls/jars/whatnots. Try to draw a graph of this, mentally, manually or using some kind of tool.
If you find it impossible to implement a feature because you have no idea where a specific responsibility goes, then your system is too tightly coupled.
For very basic signs you may consider looking the number of interfaces and their usage between classes of different packages(usually loosely-coupled code contains interfaces and there are limited direct interaction between the individual classes in different packages), number of class names that can be used to group other classes (in loosely-coupled code actual interaction between classes that have different jobs are done by interface functions or by functions of more common/grouping classes) or number public variables inside classes(more loosely much lesser/ even none public variables).
Pretty much all the code smells indicate superfluous coupling in some manner. I suppose the smell that would most indicate coupling though might be "Inappropriate Intimacy" (my favorite smell).
I suppose another reasonable method to measure would be to count the lines in your UML diagram. If you have N objects, and N^N (or more) lines between them, then your code is pretty much maximally coupled. N lines would probably be about as minimal as you could get.
