[dart-misc] Style guide says nothing about part/ part of

[Kasper Peulen]

I was looking about best practices for using part, but the style guide
doesn't seem to say anything about it.

I would like this topic to be about what are best practices for using part.
Should it be avoided? Or is it a good way to organize your code? Or
something in between?

[Jan Mostert]

As far as I can see, part is best used to split enormous classes into
logical separate files - how you define enormous is probably up to
you. Gilad Bracha's book has a great example where he has an IDE class
split into parts - an IDE can have many parts, but is still all part of the
IDE class - eg scanner, parser, autocomplete, file-manager, windows,
debugger, etc
Then using the export operator, you can export certain operations to not
expose the full inner workings of your IDE class.

Does using parts have any benefits when compiling to JS other than just
structuring your code better?
When I started using Dart, I was under the impression that using parts was
necessary to build a single JS file, so I had one dart file which had a
gazillion part declarations and every dart file was part of that library;

Post by Kasper Peulen
I was looking about best practices for using part, but the style guide
doesn't seem to say anything about it.
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Günter Zöchbauer]

That's a good summary but I think you should replace a few "class" by
"library". In Dart a class can't be split into several files.

On Tuesday, December 22, 2015 at 5:13:14 PM UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
As far as I can see, part is best used to split enormous classes into
logical separate files - how you define enormous is probably up to
you. Gilad Bracha's book has a great example where he has an IDE class
split into parts - an IDE can have many parts, but is still all part of the
IDE class - eg scanner, parser, autocomplete, file-manager, windows,
debugger, etc
Then using the export operator, you can export certain operations to not
expose the full inner workings of your IDE class.
Does using parts have any benefits when compiling to JS other than just
structuring your code better?
When I started using Dart, I was under the impression that using parts was
necessary to build a single JS file, so I had one dart file which had a
gazillion part declarations and every dart file was part of that library;

Post by Kasper Peulen
I was looking about best practices for using part, but the style guide
doesn't seem to say anything about it.
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Jan Mostert]

There you go: https://dartpad.dartlang.org/15422fdb7479c0d5025c

Hehehe

Post by Günter Zöchbauer
That's a good summary but I think you should replace a few "class" by
"library". In Dart a class can't be split into several files.
On Tuesday, December 22, 2015 at 5:13:14 PM UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
As far as I can see, part is best used to split enormous classes into
logical separate files - how you define enormous is probably up to
you. Gilad Bracha's book has a great example where he has an IDE class
split into parts - an IDE can have many parts, but is still all part of the
IDE class - eg scanner, parser, autocomplete, file-manager, windows,
debugger, etc
Then using the export operator, you can export certain operations to not
expose the full inner workings of your IDE class.
Does using parts have any benefits when compiling to JS other than just
structuring your code better?
When I started using Dart, I was under the impression that using parts
was necessary to build a single JS file, so I had one dart file which had a
gazillion part declarations and every dart file was part of that library;

I was looking about best practices for using part, but the style guide

Post by Jan Mostert

Post by Kasper Peulen
doesn't seem to say anything about it.
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.

To unsubscribe from this group and stop receiving emails from it, send an
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Vittorio Ballestra]

Hi Vlad, what do you mean by "export operator" ?

Il giorno martedì 22 dicembre 2015 17:13:14 UTC+1, Jan Vladimir Mostert ha

Post by Jan Mostert
As far as I can see, part is best used to split enormous classes into
logical separate files - how you define enormous is probably up to
you. Gilad Bracha's book has a great example where he has an IDE class
split into parts - an IDE can have many parts, but is still all part of the
IDE class - eg scanner, parser, autocomplete, file-manager, windows,
debugger, etc
Then using the export operator, you can export certain operations to not
expose the full inner workings of your IDE class.
Does using parts have any benefits when compiling to JS other than just
structuring your code better?
When I started using Dart, I was under the impression that using parts was
necessary to build a single JS file, so I had one dart file which had a
gazillion part declarations and every dart file was part of that library;

Post by Kasper Peulen
I was looking about best practices for using part, but the style guide
doesn't seem to say anything about it.
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Günter Zöchbauer]

It's not an operator
https://www.dartlang.org/effective-dart/style/#do-specify-exports-in-a-separate-section-after-all-imports

Post by Vittorio Ballestra
Hi Vlad, what do you mean by "export operator" ?
Il giorno martedì 22 dicembre 2015 17:13:14 UTC+1, Jan Vladimir Mostert ha

Post by Jan Mostert
As far as I can see, part is best used to split enormous classes into
logical separate files - how you define enormous is probably up to
you. Gilad Bracha's book has a great example where he has an IDE class
split into parts - an IDE can have many parts, but is still all part of the
IDE class - eg scanner, parser, autocomplete, file-manager, windows,
debugger, etc
Then using the export operator, you can export certain operations to not
expose the full inner workings of your IDE class.
Does using parts have any benefits when compiling to JS other than just
structuring your code better?
When I started using Dart, I was under the impression that using parts
was necessary to build a single JS file, so I had one dart file which had a
gazillion part declarations and every dart file was part of that library;

Post by Kasper Peulen
I was looking about best practices for using part, but the style guide
doesn't seem to say anything about it.
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

[Jan Mostert]

I was getting class and library mixed up and not sure what to call export,
so called it an operator.

Was referring to this functionality:

export 'browsing.dart' show AbstractBrowser, LibraryBrowser, ClassBrowser;

Using export and show, you can expose certain classes in your library even
if that library had many parts. This allows you to hide certain parts of
your API.

Post by Günter Zöchbauer
It's not an operator
https://www.dartlang.org/effective-dart/style/#do-specify-exports-in-a-separate-section-after-all-imports

Post by Vittorio Ballestra
Hi Vlad, what do you mean by "export operator" ?
Il giorno martedì 22 dicembre 2015 17:13:14 UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
As far as I can see, part is best used to split enormous classes into
logical separate files - how you define enormous is probably up to
you. Gilad Bracha's book has a great example where he has an IDE class
split into parts - an IDE can have many parts, but is still all part of the
IDE class - eg scanner, parser, autocomplete, file-manager, windows,
debugger, etc
Then using the export operator, you can export certain operations to not
expose the full inner workings of your IDE class.
Does using parts have any benefits when compiling to JS other than just
structuring your code better?
When I started using Dart, I was under the impression that using parts
was necessary to build a single JS file, so I had one dart file which had a
gazillion part declarations and every dart file was part of that library;

Post by Kasper Peulen
I was looking about best practices for using part, but the style guide
doesn't seem to say anything about it.
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Post by Jan Mostert
I was getting class and library mixed up and not sure what to call export,
so called it an operator.

It's technically a "directive", like "import" and "part".

Post by Jan Mostert
export 'browsing.dart' show AbstractBrowser, LibraryBrowser, ClassBrowser;
Using export and show, you can expose certain classes in your library even
if that library had many parts. This allows you to hide certain parts of
your API.

You are still confused. :)

If you are using part, there is nothing to export. With parts, there is
only *one* library, and if you import it, you get everything from all of
the parts it's broken into, like it or not.

– bob

[Jan Mostert]

Did I misread this page?
From the way Gilad explains it, it sounds like he's building an API out of
library parts and only exposing certain parts via the API using export and
show. Chapter 3.5's headline is Breaking Libraries into Parts and 3.6
covers the export directive following on the same example he just broke up
into parts.

[image: Screenshot_2015-12-22-20-53-20.png]

Post by 'Bob Nystrom' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
It's technically a "directive", like "import" and "part".

Thanks for that! A bit rusty on the terminology :-)

Post by 'Bob Nystrom' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
I was getting class and library mixed up and not sure what to call
export, so called it an operator.

It's technically a "directive", like "import" and "part".

Post by 'Bob Nystrom' via Dart Misc
export 'browsing.dart' show AbstractBrowser, LibraryBrowser, ClassBrowser;
Using export and show, you can expose certain classes in your library
even if that library had many parts. This allows you to hide certain parts
of your API.

You are still confused. :)
If you are using part, there is nothing to export. With parts, there is
only *one* library, and if you import it, you get everything from all of
the parts it's broken into, like it or not.
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Jan Mostert]

Or is export an alternative way to expose other dart files in your library?
If that's the case, then part is just obsolete?

Post by Jan Mostert
Did I misread this page?
From the way Gilad explains it, it sounds like he's building an API out of
library parts and only exposing certain parts via the API using export and
show. Chapter 3.5's headline is Breaking Libraries into Parts and 3.6
covers the export directive following on the same example he just broke up
into parts.
[image: Screenshot_2015-12-22-20-53-20.png]

Post by 'Bob Nystrom' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
It's technically a "directive", like "import" and "part".

Thanks for that! A bit rusty on the terminology :-)
On Tue, 22 Dec 2015 at 20:42 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
I was getting class and library mixed up and not sure what to call
export, so called it an operator.

It's technically a "directive", like "import" and "part".

Post by 'Bob Nystrom' via Dart Misc
export 'browsing.dart' show AbstractBrowser, LibraryBrowser,
ClassBrowser;
Using export and show, you can expose certain classes in your library
even if that library had many parts. This allows you to hide certain parts
of your API.

You are still confused. :)
If you are using part, there is nothing to export. With parts, there is
only *one* library, and if you import it, you get everything from all of
the parts it's broken into, like it or not.
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Post by Jan Mostert
Or is export an alternative way to expose other dart files in your library?

Sort of. Export lets a declaration in one library appear to come from
another one. It's sort of like an alias. It lets you import a declaration
from one library (the one that exports it) even though it's really defined
elsewhere.

Post by Jan Mostert
If that's the case, then part is just obsolete?

Unlike export, parts give multiple files access to the same *private*
namespace, so part can express some things that export can't. Personally, I
very very rarely want to express that anyway. Even when I do, I think part
is too much of a blunt instrument to use for that. I'd rather something
like "friend libraries" or a more controlled way for one library to give
access to its private namespace to another.

– bob

[Jan Mostert]

Thanks Bob, now I get it!

Post by 'Bob Nystrom' via Dart Misc

Post by Jan Mostert
Or is export an alternative way to expose other dart files in your library?

Sort of. Export lets a declaration in one library appear to come from
another one. It's sort of like an alias. It lets you import a declaration
from one library (the one that exports it) even though it's really defined
elsewhere.

Post by Jan Mostert
If that's the case, then part is just obsolete?

Unlike export, parts give multiple files access to the same *private*
namespace, so part can express some things that export can't. Personally, I
very very rarely want to express that anyway. Even when I do, I think part
is too much of a blunt instrument to use for that. I'd rather something
like "friend libraries" or a more controlled way for one library to give
access to its private namespace to another.
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Don Olmstead]

Was there ever a bug on friend libraries? Guessing you'd want something
along the lines of assembly level access ala C#.

Post by Jan Mostert
Thanks Bob, now I get it!
On Tue, 22 Dec 2015 at 21:24 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Jan Mostert
Or is export an alternative way to expose other dart files in your library?

Sort of. Export lets a declaration in one library appear to come from
another one. It's sort of like an alias. It lets you import a declaration
from one library (the one that exports it) even though it's really defined
elsewhere.

Post by Jan Mostert
If that's the case, then part is just obsolete?

Unlike export, parts give multiple files access to the same *private*
namespace, so part can express some things that export can't. Personally, I
very very rarely want to express that anyway. Even when I do, I think part
is too much of a blunt instrument to use for that. I'd rather something
like "friend libraries" or a more controlled way for one library to give
access to its private namespace to another.
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Post by Don Olmstead
Was there ever a bug on friend libraries?

Nope. We've discussed it informally, but haven't worked up a full DEP or
anything. Right now, a good enough portion of the team is very busy hacking
on generic methods and hopefully soon non-nullable types that we're trying
to limit the number of other language changes in flight.

Cheers!

– bob

[Anders Holmgren]

Post by 'Bob Nystrom' via Dart Misc

Post by Don Olmstead
Was there ever a bug on friend libraries?

Nope. We've discussed it informally, but haven't worked up a full DEP or
anything. Right now, a good enough portion of the team is very busy hacking
on generic methods and hopefully soon non-nullable types that we're trying
to limit the number of other language changes in flight.

Ssshhh Don don't distract them. They are working on my fav features and
yours if I'm not mistaken.

Post by 'Bob Nystrom' via Dart Misc
Cheers!
– bob

[Vittorio Ballestra]

Flex (RIP) had a nice way of dealing with scope and visibility that
resembled the way XML uses namespace prefixes. You could declare a new
scope in a similar way and decide to which scope a declaration belong.

Post by 'Bob Nystrom' via Dart Misc

Post by Jan Mostert
Or is export an alternative way to expose other dart files in your library?

Sort of. Export lets a declaration in one library appear to come from
another one. It's sort of like an alias. It lets you import a declaration
from one library (the one that exports it) even though it's really defined
elsewhere.

Post by Jan Mostert
If that's the case, then part is just obsolete?

Unlike export, parts give multiple files access to the same *private*
namespace, so part can express some things that export can't. Personally, I
very very rarely want to express that anyway. Even when I do, I think part
is too much of a blunt instrument to use for that. I'd rather something
like "friend libraries" or a more controlled way for one library to give
access to its private namespace to another.
– bob

['Bob Nystrom' via Dart Misc]

Post by Jan Mostert
From the way Gilad explains it, it sounds like he's building an API out of
library parts and only exposing certain parts via the API using export and
show. Chapter 3.5's headline is Breaking Libraries into Parts and 3.6
covers the export directive following on the same example he just broke up
into parts.

In 3.5, he says, "due to the tight integration, we may want the IDE to
be a single
library with its private state shared across its subsystems." Then he uses
"part" to accomplish that.

In 3.6, he says, "It is possible that our project may grow beyond our
wildest expectations, and we really need to split it into multiple libraries."
Export is for composing libraries.

– bob

[Benjamin Strauß]

Hmm? Is his book finally out?

Post by Jan Mostert
Did I misread this page?
From the way Gilad explains it, it sounds like he's building an API out of
library parts and only exposing certain parts via the API using export and
show. Chapter 3.5's headline is Breaking Libraries into Parts and 3.6
covers the export directive following on the same example he just broke up
into parts.
[image: Screenshot_2015-12-22-20-53-20.png]

Post by 'Bob Nystrom' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
It's technically a "directive", like "import" and "part".

Thanks for that! A bit rusty on the terminology :-)
On Tue, 22 Dec 2015 at 20:42 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
I was getting class and library mixed up and not sure what to call
export, so called it an operator.

It's technically a "directive", like "import" and "part".

Post by 'Bob Nystrom' via Dart Misc
export 'browsing.dart' show AbstractBrowser, LibraryBrowser,
ClassBrowser;
Using export and show, you can expose certain classes in your library
even if that library had many parts. This allows you to hide certain parts
of your API.

You are still confused. :)
If you are using part, there is nothing to export. With parts, there is
only *one* library, and if you import it, you get everything from all of
the parts it's broken into, like it or not.
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Vittorio Ballestra]

Ok, tnx

Il giorno martedì 22 dicembre 2015 18:18:28 UTC+1, GÌnter Zöchbauer ha

Post by Günter Zöchbauer
It's not an operator
https://www.dartlang.org/effective-dart/style/#do-specify-exports-in-a-separate-section-after-all-imports

Post by Vittorio Ballestra
Hi Vlad, what do you mean by "export operator" ?
Il giorno martedì 22 dicembre 2015 17:13:14 UTC+1, Jan Vladimir Mostert

Post by Jan Mostert
As far as I can see, part is best used to split enormous classes into
logical separate files - how you define enormous is probably up to
you. Gilad Bracha's book has a great example where he has an IDE class
split into parts - an IDE can have many parts, but is still all part of the
IDE class - eg scanner, parser, autocomplete, file-manager, windows,
debugger, etc
Then using the export operator, you can export certain operations to not
expose the full inner workings of your IDE class.
Does using parts have any benefits when compiling to JS other than just
structuring your code better?
When I started using Dart, I was under the impression that using parts
was necessary to build a single JS file, so I had one dart file which had a
gazillion part declarations and every dart file was part of that library;

Post by Kasper Peulen
I was looking about best practices for using part, but the style guide
doesn't seem to say anything about it.
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

['Bob Nystrom' via Dart Misc]

Post by Kasper Peulen
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?

Personally, I believe the best practice for using "part" is: don't.

As far as I'm concerned, it has always been a misfeature of the language.
I've never liked it, and stopped using it the day export was added to the
language. Instead, I make each file its own library. If I want users to be
able to import one library and get stuff defined in multiple files, I make
a "parent" library that exports those sub-libraries.

– bob

['Paul Berry' via Dart Misc]

I second what Bob says.

Post by 'Bob Nystrom' via Dart Misc

Post by Kasper Peulen
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?

Personally, I believe the best practice for using "part" is: don't.
As far as I'm concerned, it has always been a misfeature of the language.
I've never liked it, and stopped using it the day export was added to the
language. Instead, I make each file its own library. If I want users to be
able to import one library and get stuff defined in multiple files, I make
a "parent" library that exports those sub-libraries.
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Alec Henninger]

For reference, I've found looking at reflectable and observe helpful to see
the "no parts" pattern in action.

https://github.com/dart-lang/reflectable/tree/master/reflectable/lib
https://github.com/dart-lang/observe/tree/master/lib

It seems convention for library names to [mostly] match their directory
structure. For instance, private libraries in "src" follow *package*.src.
*filename* for the most part (no pun intended).

Of course, the SDK uses parts all over the place.

Post by 'Bob Nystrom' via Dart Misc

Post by Kasper Peulen
I would like this topic to be about what are best practices for using
part. Should it be avoided? Or is it a good way to organize your code? Or
something in between?

Personally, I believe the best practice for using "part" is: don't.
As far as I'm concerned, it has always been a misfeature of the language.
I've never liked it, and stopped using it the day export was added to the
language. Instead, I make each file its own library. If I want users to be
able to import one library and get stuff defined in multiple files, I make
a "parent" library that exports those sub-libraries.
– bob

['Bob Nystrom' via Dart Misc]

Post by Alec Henninger
For reference, I've found looking at reflectable and observe helpful to
see the "no parts" pattern in action.
https://github.com/dart-lang/reflectable/tree/master/reflectable/lib
https://github.com/dart-lang/observe/tree/master/lib

Some more packages that don't use part:

https://github.com/dart-lang/dart_style
https://github.com/dart-lang/pub
https://github.com/dart-lang/http
https://github.com/dart-lang/path

Cheers!

– bob