www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Import conventions

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
As an aid to maintainability, discoverability and possible automation, how would
people feel about a simple import ordering convention? Specifically:

- imports from std come first. Root-level comes first, followed by in
alphabetical order for sub-levels
- an empty line comes next
- imports from third-party come next. Root-level comes first, followed by in
alphabetical order for sub-levels
- an empty line comes next
- imports from other modules in "this" organisation/project/library come last.
Root-level comes first, followed by in alphabetical order for sub-levels

An example:

    private import std.loader;
    private import std.utf;
    private import std.c.windows.windows;

    private import mango.blah;
    private import mango.stuff;
    private import mango.abc.otherstuff;
    private import mango.things.nicethings;

    import mylib.stuff
    import mylib.badthings.hmm;
    import mylib.goodstuff.garbage;

Having been on the wrong side of maintaining hideously butchered Java import
lists in the past, I think this'd be a very useful convention to adhere to. It
can save a _lot_ of time scrabbling about in the semi-dark
Jun 14 2004
next sibling parent Chris Lawson <cl mangler.tinfoilhat.ca> writes:
We do this exact thing in our C# project.  It works well.

+1

Chris

Matthew wrote:
 As an aid to maintainability, discoverability and possible automation, how
would
 people feel about a simple import ordering convention? Specifically:
 
 - imports from std come first. Root-level comes first, followed by in
 alphabetical order for sub-levels
 - an empty line comes next
 - imports from third-party come next. Root-level comes first, followed by in
 alphabetical order for sub-levels
 - an empty line comes next
 - imports from other modules in "this" organisation/project/library come last.
 Root-level comes first, followed by in alphabetical order for sub-levels
 
 An example:
 
     private import std.loader;
     private import std.utf;
     private import std.c.windows.windows;
 
     private import mango.blah;
     private import mango.stuff;
     private import mango.abc.otherstuff;
     private import mango.things.nicethings;
 
     import mylib.stuff
     import mylib.badthings.hmm;
     import mylib.goodstuff.garbage;
 
 Having been on the wrong side of maintaining hideously butchered Java import
 lists in the past, I think this'd be a very useful convention to adhere to. It
 can save a _lot_ of time scrabbling about in the semi-dark
 
 
 

Jun 14 2004
prev sibling next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
+1 Sounds good. I'll have to brush up on my ABC's. An editor feature could 
possibly automate this for you. perhaps.

On Mon, 14 Jun 2004 17:43:23 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 As an aid to maintainability, discoverability and possible automation, 
 how would
 people feel about a simple import ordering convention? Specifically:

 - imports from std come first. Root-level comes first, followed by in
 alphabetical order for sub-levels
 - an empty line comes next
 - imports from third-party come next. Root-level comes first, followed 
 by in
 alphabetical order for sub-levels
 - an empty line comes next
 - imports from other modules in "this" organisation/project/library come 
 last.
 Root-level comes first, followed by in alphabetical order for sub-levels

 An example:

     private import std.loader;
     private import std.utf;
     private import std.c.windows.windows;

     private import mango.blah;
     private import mango.stuff;
     private import mango.abc.otherstuff;
     private import mango.things.nicethings;

     import mylib.stuff
     import mylib.badthings.hmm;
     import mylib.goodstuff.garbage;

 Having been on the wrong side of maintaining hideously butchered Java 
 import
 lists in the past, I think this'd be a very useful convention to adhere 
 to. It
 can save a _lot_ of time scrabbling about in the semi-dark

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 14 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9lvfxau5a2sq9 digitalmars.com...
 +1 Sounds good. I'll have to brush up on my ABC's. An editor feature could
 possibly automate this for you. perhaps.

Exactly the point. :). We can program our editors and code pretty-printers with the "D import convention", and all will be well with the world. ;)
 On Mon, 14 Jun 2004 17:43:23 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 As an aid to maintainability, discoverability and possible automation,
 how would
 people feel about a simple import ordering convention? Specifically:

 - imports from std come first. Root-level comes first, followed by in
 alphabetical order for sub-levels
 - an empty line comes next
 - imports from third-party come next. Root-level comes first, followed
 by in
 alphabetical order for sub-levels
 - an empty line comes next
 - imports from other modules in "this" organisation/project/library come
 last.
 Root-level comes first, followed by in alphabetical order for sub-levels

 An example:

     private import std.loader;
     private import std.utf;
     private import std.c.windows.windows;

     private import mango.blah;
     private import mango.stuff;
     private import mango.abc.otherstuff;
     private import mango.things.nicethings;

     import mylib.stuff
     import mylib.badthings.hmm;
     import mylib.goodstuff.garbage;

 Having been on the wrong side of maintaining hideously butchered Java
 import
 lists in the past, I think this'd be a very useful convention to adhere
 to. It
 can save a _lot_ of time scrabbling about in the semi-dark

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Jun 14 2004
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
Sounds good to me. I added it to the Best Practices wiki page: 
http://www.wikiservice.at/d/wiki.cgi?BestPractices.

Matthew wrote:
 As an aid to maintainability, discoverability and possible automation, how
would
 people feel about a simple import ordering convention? Specifically:
 
 - imports from std come first. Root-level comes first, followed by in
 alphabetical order for sub-levels
 - an empty line comes next
 - imports from third-party come next. Root-level comes first, followed by in
 alphabetical order for sub-levels
 - an empty line comes next
 - imports from other modules in "this" organisation/project/library come last.
 Root-level comes first, followed by in alphabetical order for sub-levels
 
 An example:
 
     private import std.loader;
     private import std.utf;
     private import std.c.windows.windows;
 
     private import mango.blah;
     private import mango.stuff;
     private import mango.abc.otherstuff;
     private import mango.things.nicethings;
 
     import mylib.stuff
     import mylib.badthings.hmm;
     import mylib.goodstuff.garbage;
 
 Having been on the wrong side of maintaining hideously butchered Java import
 lists in the past, I think this'd be a very useful convention to adhere to. It
 can save a _lot_ of time scrabbling about in the semi-dark

-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jun 14 2004
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
news:cajkv3$31c3$1 digitaldaemon.com
| As an aid to maintainability, discoverability and possible automation, how
would
| people feel about a simple import ordering convention? Specifically:
|
| - imports from std come first. Root-level comes first, followed by in
| alphabetical order for sub-levels
| - an empty line comes next
| - imports from third-party come next. Root-level comes first, followed by
in
| alphabetical order for sub-levels
| - an empty line comes next
| - imports from other modules in "this" organisation/project/library come
last.
| Root-level comes first, followed by in alphabetical order for sub-levels
|
| ...
|

So this would be considered bad: import std.file, std.socketstream,
std.stream; ? I like to do things like that, but if we all agree...
In general, I tend to agree, even if I don't like being that ordered, but I
could start sometime.

-----------------------
Carlos Santander Bernal
Jun 14 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:calhkg$2v9e$2 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
 news:cajkv3$31c3$1 digitaldaemon.com
 | As an aid to maintainability, discoverability and possible automation, how
 would
 | people feel about a simple import ordering convention? Specifically:
 |
 | - imports from std come first. Root-level comes first, followed by in
 | alphabetical order for sub-levels
 | - an empty line comes next
 | - imports from third-party come next. Root-level comes first, followed by
 in
 | alphabetical order for sub-levels
 | - an empty line comes next
 | - imports from other modules in "this" organisation/project/library come
 last.
 | Root-level comes first, followed by in alphabetical order for sub-levels
 |
 | ...
 |

 So this would be considered bad: import std.file, std.socketstream,
 std.stream; ? I like to do things like that, but if we all agree...

I'm only speaking from my own experience in rescuing a bad Java project, and having to write automated code modification programs that ran on 10s of millions of lines of (bad) code, but, yes, I think that's not so good. Putting things on their own lines really clear things up. You can even write driver programs to incrementally remove the imports and attempt compilations, and you get a report on which ones are redundant.
 In general, I tend to agree, even if I don't like being that ordered, but I
 could start sometime.

No one does. Like I say, this comes from my own experience of being on the other side of things, and that changed my perspective forever. (I also *never* do an import xyz.* in Java, but I'm not going to try and argue that in this forum <g>)
Jun 14 2004