www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - import statement placement

reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
Are there any idiom rules as to where to put import statements in D?

In Python they can go anywhere but PEP-8 suggests they should all go at
the top of a file, just after the module documentation string.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 07 2017
next sibling parent Biotronic <simen.kjaras gmail.com> writes:
On Wednesday, 7 June 2017 at 12:39:07 UTC, Russel Winder wrote:

 Are there any idiom rules as to where to put import statements 
 in D?

 In Python they can go anywhere but PEP-8 suggests they should 
 all go at the top of a file, just after the module 
 documentation string.


I don't know if there is any official dogma on how to use 
imports, but given that local imports inside templates are only 
loaded if the template is instantiated, there are benefits to 
using local imports in those cases.

Another use for local imports is in unittests - any import that 
is only used in unittests may benefit from being moved from 
module scope to inside the unittests themselves, or for an import 
used by many tests, a version (unittest) block.

In my own code, I use very loose guidelines but prefer to put any 
imports that are used only in one or two functions, inside those 
functions. Imports that are used by multiple functions are placed 
at the top of the file, just below the module declaration (if 
any).

Similarly, I try to use selective imports when only a few symbols 
from a module are used in my module, but find that this becomes 
unwieldy past 3-5 symbols.

--
   Biotronic
Jun 07 2017
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 7 June 2017 at 12:39:07 UTC, Russel Winder wrote:

 Are there any idiom rules as to where to put import statements 
 in D?

 In Python they can go anywhere but PEP-8 suggests they should 
 all go at the top of a file, just after the module 
 documentation string.


Well for ones that aren't scoped (i.e. used pervasively 
throughout the module) I always put them after the module 
declaration (if not the file containing main) and doc comment.

For scoped imports they go either on the line after the opening 
brace of the enclosing scope, or the line before the 
(selectively) imported symbol is used (if there is a reasonable 
amount of code preceding the opening brace).

Perhaps the https://dlang.org/dstyle.html imports section should 
be expanded.
Jun 07 2017
next sibling parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Wed, Jun 07, 2017 at 01:17:39PM +0000, Nicholas Wilson via
Digitalmars-d-learn wrote:

 On Wednesday, 7 June 2017 at 12:39:07 UTC, Russel Winder wrote:

 Are there any idiom rules as to where to put import statements in D?
 
 In Python they can go anywhere but PEP-8 suggests they should all go
 at the top of a file, just after the module documentation string.


 
 Well for ones that aren't scoped (i.e. used pervasively throughout the
 module) I always put them after the module declaration (if not the
 file containing main) and doc comment.
 
 For scoped imports they go either on the line after the opening brace
 of the enclosing scope, or the line before the (selectively) imported
 symbol is used (if there is a reasonable amount of code preceding the
 opening brace).


[...]

I follow the same convention.

Though lately, I've been finding myself moving away more and more from
global imports, and moving imports into the scope in which they're
actually used.  While that sometimes necessitates more typing, I find
that it also improves code readability and movability: having scoped
imports in the block in which the symbol is used means reducing the
likelihood of overload conflicts with unfortunately-named symbols (there
are a few of these in Phobos). And I can easily move that code into a
different source file and have it Just Work, instead of having to
twiddle with the import statements at the top of the file (and
inadvertently leave useless imports in the original file where they are
no longer needed).

Nowadays I generally only use module-level import for things that are
truly used pervasively, like std.range.primitives, and std.stdio in the
module where main() is defined.  I try to avoid importing std.stdio
anywhere else, unless that module is directly concerned with I/O, and
force myself to structure the code such that such a dependency is not
needed in the first place -- e.g., write generic range-based algorithms
instead of code sprinkled with calls writeln.  I found that this has
helped improve my code quality significantly, and my code has become
much more reusable.


T

-- 
The best compiler is between your ears. -- Michael Abrash
Jun 07 2017
prev sibling parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 2017-06-07 at 10:08 -0700, H. S. Teoh via Digitalmars-d-learn
wrote:

 On Wed, Jun 07, 2017 at 01:17:39PM +0000, Nicholas Wilson via
 Digitalmars-d-learn wrote:

 On Wednesday, 7 June 2017 at 12:39:07 UTC, Russel Winder wrote:

 Are there any idiom rules as to where to put import statements in
 D?
=20
 In Python they can go anywhere but PEP-8 suggests they should all
 go
 at the top of a file, just after the module documentation string.


=20
 Well for ones that aren't scoped (i.e. used pervasively throughout
 the
 module) I always put them after the module declaration (if not the
 file containing main) and doc comment.




I am also tending to import individual symbols from modules rather than
whole modules. In Python this can sometime be the wrong thing to do,
but then the scope rules are different to D. The D import scope rules
seem to be equivalent to Python star imports, which is a nightmare.


 For scoped imports they go either on the line after the opening
 brace
 of the enclosing scope, or the line before the (selectively)
 imported
 symbol is used (if there is a reasonable amount of code preceding
 the
 opening brace).




I hadn't got into scoped imports. I suspect I am now going to become a
fan of them.


 I follow the same convention.
=20
 Though lately, I've been finding myself moving away more and more
 from
 global imports, and moving imports into the scope in which they're
 actually used.=C2=A0=C2=A0While that sometimes necessitates more typing, =


I find

 that it also improves code readability and movability: having scoped
 imports in the block in which the symbol is used means reducing the
 likelihood of overload conflicts with unfortunately-named symbols
 (there
 are a few of these in Phobos). And I can easily move that code into a
 different source file and have it Just Work, instead of having to
 twiddle with the import statements at the top of the file (and
 inadvertently leave useless imports in the original file where they
 are
 no longer needed).
=20
 Nowadays I generally only use module-level import for things that are
 truly used pervasively, like std.range.primitives, and std.stdio in
 the
 module where main() is defined.=C2=A0=C2=A0I try to avoid importing std.s=


tdio

 anywhere else, unless that module is directly concerned with I/O, and
 force myself to structure the code such that such a dependency is not
 needed in the first place -- e.g., write generic range-based
 algorithms
 instead of code sprinkled with calls writeln.=C2=A0=C2=A0I found that thi=


s has

 helped improve my code quality significantly, and my code has become
 much more reusable.
=20


OK, I am now convinced.

This still leaves the question of "whole module imports" vs "symbols
from modules". Because D imports are equivalent to Python or Java star
imports, which are anathema, I am thinking "symbols from modules"
remains the best strategy even with scoping.



 T
=20


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 08 2017