My point is that the actual code is more important than import statements. I often don't even need to change or see the import statements. Also, when I'm refactoring code, I usually finish changing the code first before fixing import statements.

I know modern compilers would be intelligent enough to pick up import statements anywhere in the source file. Why don't people put all the import statements at the bottom of the source code file? Is it because of historical reasons?

closed as primarily opinion-based by Greg Burghardt, amon, Jörg W Mittag, gnat, Laiv Apr 4 at 7:55

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Are you asking about a particular language? Because the answer is going to be language-dependent, often: “the language simply doesn't work that way” – amon Apr 3 at 21:58
  • @amon I'm not limiting my question to certain languages. Just want to see if someone were to design a new language, could it be more flexible like that. – WoLfPwNeR Apr 4 at 7:59

My point is that the actual code is more important than import statements.

I think you'll find that's a minority opinion! Import statements are code. Certainly one of the first things I want to know about any code is what the dependencies are, and what external data structures and classes it's going to be calling.

  • 3
    This is especially relevant in some languages, where dynamic imports are becoming a thing (dynamic import is I think a Stage 3 proposal for JavaScript), or any language which is completely interpreted (so dependencies must exist before they're called) – Delioth Apr 3 at 21:33

Yes, it is for historical reasons.

From a purely human standpoint, it makes more sense to put using, import, etc. at the top of the file, because it "sets the stage" for the code I'm about to see next. For example, if I see using System.Reflection at the top of the file, I'm pretty sure that I'm going to see reflection code in there somewhere.

  • I am sure you mean to give an example but many default added using namespaces and others during development are redundant. That's why IDE shows them as dim. So if I see using System.Reflection I can't be sure I am going to see any reflection code :) – Engineert Apr 3 at 21:46
  • 7
    @Engineert: A problem easily solved in Visual Studio by right-clicking and selecting "Sort and Remove Unused Usings." I never said I liked using statements that are not utilized in the code. – Robert Harvey Apr 3 at 21:47
  • 2
    It also makes sense in languages like C that were designed with a single-pass compiler in mind. – Blrfl Apr 4 at 2:27
  • @RobertHarvey of course it is and I am sure you are. My comment is just for a complaint about developers don't attention to remove unused using namespaces (I also know that no error occurs if not remove). Not offence :) Btw, I think the main reason that's why developers forget to remove is there is no easy way to remove from project or entire solution. It should be per file, right? – Engineert Apr 4 at 8:51

This entirely depends on the language's import semantic.

In many languages, import statements aren't declarative. The order and the location that the import statement is placed in matters to the interpretation and semantic of the imports.

For example, in C-derived languages, #include statement has the semantic of arbitrary textual inclusion. Python's import statement also acts like runtime executable statement for dynamic loading (i.e. like dlopen), not just parse-time/compile-time declaration.

Making an import statement an executable statement rather than just a compile time declaration has many benefits. For example, the code can dynamically self modify its module search path or conditionally imports different things based on runtime introspection, if import statement is purely declarative, you would have needed another special constructs to do those things. You'll find that languages that doesn't have runtime import semantic often have to resort to horrid hacks to implement things that are fairly easy otherwise.

It just happens that in many scenarios, putting most imports in the top, before any other code/declarations runs usually works well when you don't need to use/care about those dynamic import capabilities.


Why don't we put import statements at the bottom of source files

Because compilers generally don't cope well, if at all, with doing this.

By way of a related example, if we follow the principle of "write code primarily for other developers to read, not the compiler", then all the important things, like public methods, should be at the top of the file. And less important stuff should be near the bottom. To my mind, private fields in classes are one such less important thing. So I experimented with putting them at the end of the class with C#.

The result was a development nightmare. The moment I, for example, added an { to a method, the compiler couldn't then parse the fields. So the code would fill with errors and auto-completion wouldn't work. This made writing or editing the code really hard. It was a truly painful experience and I quickly abandoned it and moved those fields back to the top of the class.

So sometimes, we have to structure code for the benefit of the compiler, rather than for the reader. Import statements are one such example of this. So they go at the top of the file.

  • The experiences you had with the compiler/code highlighter/code completion led me to develop the habit of always typing {, [ and ( as balanced pairs and after that filling in what needs to go inside. Some IDE's can be configured to do that automatically. – Bart van Ingen Schenau Apr 4 at 10:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.