digitalmars.D - Import conventions
- Matthew (24/24) Jun 14 2004 As an aid to maintainability, discoverability and possible automation, h...
- Chris Lawson (4/37) Jun 14 2004 We do this exact thing in our C# project. It works well.
- Regan Heath (6/35) Jun 14 2004 +1 Sounds good. I'll have to brush up on my ABC's. An editor feature cou...
- Matthew (4/48) Jun 14 2004 Exactly the point. :). We can program our editors and code pretty-printe...
- J C Calvarese (6/36) Jun 14 2004 Sounds good to me. I added it to the Best Practices wiki page:
-
Carlos Santander B.
(25/25)
Jun 14 2004
"Matthew"
- Matthew (11/34) Jun 14 2004 I'm only speaking from my own experience in rescuing a bad Java project,...
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
Chris Lawson <cl mangler.tinfoilhat.ca>
+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
+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
"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
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
"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
"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