It depends how you manage scope. When there are thousands of global variables it will be impossible, but if the language (like Dlang) allows local scoping of im

It depends how you manage scope. When there are thousands of global variables it will be impossible, but if the language (like Dlang) allows local scoping of imports it's manageable... If you are very strict about what is an actual dependency or just a magic global. The rule is that if the import can be used in other programs/code-bases you can import it. But if it's just a way to get around using global variables you should rethink the architecture. ... Yes IDE's will find the definitions in your spaghetti code-base, but then they become part of a problem loop where the code-base would be unmanageable without the IDE. Namespaces are also a good solution to use instead of globals or magic globals. But it might become a category theory problem like where in the hierarchical structure you should put something. The best solution of course is to keep the code base small :)