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

[juan-gandhi.livejournal.com]

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

[jducoeur]

Fair point, and it's looking like I'm going to wind up in a somewhat nuanced position. There are a fair number of libraries where wildcard import is appropriate, but for querki-internal code I'm leaning against it in most cases.

And there are many libraries where it clearly wants to be forbidden -- for example, while mutable data structures occasionally have their uses, I would never, ever want to find "import scala.collections.mutable._" anywhere in the code.

Truth is, I don't know scalaz at all well, and am not using it inside Querki yet. It's on my to-do list, but has been hampered by how few decent introductions I've found for it, and *man* it is hard to get started on, especially if you don't have a strong category-theory background to begin with: they toss around an enormous amount of jargon much too casually. So far, other things have been higher priority for my self-education (eg, getting deeper in Akka). Scalaz is approaching the top of my list, although I will admit that I've been putting it off in hopes that they would finish the frikking Functional Programming in Scala book first, but I suspect I'm going to have to start elsewhere...

[juan-gandhi.livejournal.com]

So, we probably can come to a compromise:
- import libraries they way they are recommended to be imported;
- import other people's code the way you think is better;
- import your own components individually by name.

(If so, that's what I actually practice, to my amazement.)