Dependencies, and the danger of import *

[jducoeur]

Just a quick thought for the programming crowd. I've spent most of this week focused on refactoring Querki -- it's needed it for a while, and the growing need to write some proper test harness is the straw that's breaking the camel's back. (Unit testing is always a good check of your factoring: poorly-factored code is usually hard to test.)

Along the way, I'm trying to clean up my dependencies, and I'm starting to realize how dangerous mass imports can really be. I have lots of places where I had quickly typed

import models._

or something like that. (Underscore is Scala's wildcard operator, pretty consistently, so think of that as "import models.*".)

It isn't so much that this automatically makes your code bad. (Although I am beginning to suspect that it is slowing down my compiles, by muddying the dependency tree.) But it promotes lazy thinking: these sorts of mass imports make it simply too easy to use a whole lot of different classes and traits, without thinking about the factoring implications. The result is classes that are often less cohesive than they should be, in no small part because it was slightly too easy to be that way.

So I'm gradually moving towards a coding standard of being more explicit about imports in most cases. Some packages and objects are specifically intended for wildcard import, and that's okay, but I'm coming to the conclusion that the rule of thumb should be usually not doing so.

I'm curious: what are your habits? Do you prefer wildcard imports or explicit ones?

Comments

[kihou.livejournal.com]

I definitely find that wildcard imports in python make refactoring and such much harder and also make it hard to see where things are coming from, so I now always either import specific members or import the module and use the module namespace explicitly. (I guess the exception is modules that contain only a well-defined list of constants that are unlikely to dramatically change.)

[marphod.livejournal.com]

I generally come from the World Of C-Likes, so it has always been explicit ones for me.

When doing development, I write as if nothing were imported, and only import things as I find I need them. Periodically go through and trim out units I no longer need. I see no reason to change; while it might be a little faster coding by importing more and leaving in unnecessary ones, I find decreases the quality of my code. My currentway makes it easier for me to do loosely coupled interfaces, highly modular implementations, and makes me think about what I'm importing (well, including) and why.

[metageek.livejournal.com]

I don't use wildcard imports; I prefer to know what I'm bringing into my namespace.

[metahacker.livejournal.com]

In Java, my IDE brought things in for me, but Java has what I consider an unnecessary level of importing required--in my mind things like file access should be in the core.

It meant I never had to say "import java.net.*", however, because I could just name a class and IntelliJ would find it for me and ask to import it (or do that automatically).

In MATLAB there is a more serious implication in that some language features actually are separate products and must be bought separately. Knowing what you're using becomes crucial there, especially if you plan on sharing your code with others.

JS had no decent import mechanism, just including a whole file. Node.js and "require" start to change this and now I have I think about it again...and find myself going with "foo = require ('foo')", basically a wildcard...

[juan-gandhi.livejournal.com]

like instead of import scalaz; import scalaz._, you want us to list all the functions we want to import? Weird...

[crschmidt.livejournal.com]

I live by the Zen of Python, which includes:

"""
Explicit is better than implicit.
Namespaces are one honking great idea -- let's do more of those!
"""

(Though appropriately, it also includes "Although practicality beats purity.")

-- `python -mthis`