13

Typically, I see a few using statement at the top of class file. Example:

using System.Collections.Generic; using System.IO; using System.Xml.Linq;

But in a project I am working on, on several occasions I see 20 or more usings/imports in one class file. Is this bad design? It seems to be that classes designed to do one thing should only rely on a few components.

Improve this question
6
  • 1
    Visual Studio has an option to remove unused using statements. You might want to see how many of those 20 are in actual use. Commented Mar 23, 2016 at 17:54
  • @Dan -They are all in use as I have used ReSharper to weed out the unused ones. Commented Mar 23, 2016 at 18:11
  • Have you tried with adding an IoC, converting to constructor injection, and/or convert some integration points into inline lambdas to see if it will reduce the number of using statements without having to increase the number of classes? Keep in mind that increasing number of classes or source files will increase source code management overhead. Commented Mar 23, 2016 at 18:21
  • 2
    IoC just hides the problem. Commented Mar 23, 2016 at 19:03
  • 1
    Some of those things are almost just part of the language and the programming style it encourages, like Collections.Generic and LINQ, so I wouldn't necessarily worry about those. I'd probably focus my attention on the others. Most classes probably shouldn't need to do IO directly, so, perhaps if that's found everywhere there's some conflating of responsibilities or poor layering, but it does depend on the application. Commented Mar 23, 2016 at 19:10

2 Answers 2

Reset to default
21

It can indicate a bad design, yes. It might be that the class you're looking at is doing too many things, but it also might mean that the namespaces you're importing are really more coupled than the namespace separation implies. That may be because of over-engineer or over-abstraction, but it also might just be a design that doesn't align well with use.

That said, it's a smell - sometimes it leads you to something bad, and sometimes it's just a false alarm.

Improve this answer
3
  • I think the true "code smell" would be if the imported namespaces are all, or mostly, wildly different in purpose. To be honest, I've rarely had more than 6 to 8 using's in a single C# file. Commented Mar 23, 2016 at 20:56
  • 2
    I'd like to give you a second +1 if I could, just for using the term "code smell" correctly! Commented Mar 23, 2016 at 22:59
  • !@Greg - I agree, usually the "usings" are related. I think in this case it's a case over abstraction because about 15-20 of the "usings" come from application namespaces and the rest from .net framework. Commented Mar 24, 2016 at 14:47
2

A class should be no bigger and no smaller than what is needed to provide an intended function.

In one application, I have an encryption class that has one job: encrypt data. Between the core functionality, logging, and exception handling, the environment requires 11 distinct namespace imports to do this one job.

It's hard for me to tell myself 'minimize imports'. Or to judge my class' success solely by counting the number of imported namespaces. I can't justifiably use this, in isolation, as an indication of a class' success. To me, 'imports' are the means to the class' end. If the class' job is well-defined, everything else within the supporting system, including imports, will take care of itself.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.