[dart-misc] "Effective Dart" updated for Dart 2

['Bob Nystrom' via Dart Misc]

Greetings, Dartisans!

Over the past few weeks, I've put a lot of love into "Effective Dart
<https://www.dartlang.org/guides/language/effective-dart>" (AKA the "style
guide"). I rounded some of the sharp corners, clarified prose, and fixed
mistakes
<https://gist.github.com/munificent/748dbd5c4217c5d25f4a37c411965b42>. Most
importantly, I rewrote the guidelines around types
<https://www.dartlang.org/guides/language/effective-dart/design#types> from
the ground up to take into account Dart 2's new type system and inference.

Most of you are already writing code that fits within these new guidelines.
I codified the practices that people who treated Dart like an
inferred-statically-typed language previously followed. Now, Dart *is* that
kind of language, so the style guide can be clearer and more prescriptive.

This should help as all write code that is more consistent and takes
advantage of both explicit types and inference.

Let me know if you have comments/questions/etc.

Cheers!

– bob

[tatumizer-v0.2]

I think in this example, there's some confusion of colors (green one should
be red, and vice versa)

Here is *casting eagerly using List.from():*
int median(List<Object> objects) {
// We happen to know the list only contains ints.
var ints = objects.cast<int>();
ints.sort();
return ints[ints.length ~/ 2];}

['Bob Nystrom' via Dart Misc]

Oops, you're right. Thanks for spotting that!

I have a fix out: https://github.com/dart-lang/site-www/pull/897

– bob

Post by tatumizer-v0.2
I think in this example, there's some confusion of colors (green one
should be red, and vice versa)

Here is *casting eagerly using List.from():*
int median(List<Object> objects) {
// We happen to know the list only contains ints.
var ints = objects.cast<int>();
ints.sort();
return ints[ints.length ~/ 2];}
--

For more ways to connect visit https://www.dartlang.org/community
---
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
To view this discussion on the web visit https://groups.google.com/a/
dartlang.org/d/msgid/misc/b163bb15-8379-4af0-8de6-
8721a1aee950%40dartlang.org
<https://groups.google.com/a/dartlang.org/d/msgid/misc/b163bb15-8379-4af0-8de6-8721a1aee950%40dartlang.org?utm_medium=email&utm_source=footer>
.

['Bob Nystrom' via Dart Misc]

I understand the logic behind "DON’T explicitly initialize variables to
null", but I think there's a use case for the opposite.
Because null does not always mean "uninitialized". In java, I use
declarations like "String foo = null" as indicator that null is a *valid*
value for "foo". For example, it can mean "not applicable".

This is a reasonable convention, but it's not a *widely established* one.
Because of that, it's not a useful signal to readers of the code. If you
see:

String foo = null;


In some Dart code, you have no way of knowing which is the case:

- The author wants me to note that this string may deliberately be null
elsewhere in the program.
- The author doesn't realize variables are implicitly initialized to
null and thought they needed to write this.

Worse, if I see someone who writes:

String foo;


I don't know if they meant:

- This should never be null once it's initialized. (The inverse of your
rule.)
- It may or may not be null, but I didn't want to write the redundant
null initializer.

If there were a magic wand I could wave to get this convention loaded into
everyone's brain (and, alas, "Effective Dart" is not such a magic want in
general), I might be in favor of it. In the absence of that, I think it's
simpler to just tell people to not initialize things with null.

In practice, I don't think it's a super useful signal anyway. And the way I
would much rather convey it is by adding actual nullable and non-nullable
types to the language. (Which are still definitely a hoped-for feature, we
just have our hands full right now getting Dart 2 finished.)

Cheers!

– bob

[Warren]

Kudos Bob - this looks awesome! I like the summary page, and the layout
(green/red) is easy to follow.

Post by 'Bob Nystrom' via Dart Misc
Greetings, Dartisans!
Over the past few weeks, I've put a lot of love into "Effective Dart
<https://www.dartlang.org/guides/language/effective-dart>" (AKA the
"style guide"). I rounded some of the sharp corners, clarified prose, and
fixed mistakes
<https://gist.github.com/munificent/748dbd5c4217c5d25f4a37c411965b42>.
Most importantly, I rewrote the guidelines around types
<https://www.dartlang.org/guides/language/effective-dart/design#types> from
the ground up to take into account Dart 2's new type system and inference.
Most of you are already writing code that fits within these new
guidelines. I codified the practices that people who treated Dart like an
inferred-statically-typed language previously followed. Now, Dart *is* that
kind of language, so the style guide can be clearer and more prescriptive.
This should help as all write code that is more consistent and takes
advantage of both explicit types and inference.
Let me know if you have comments/questions/etc.
Cheers!
– bob

['Bob Nystrom' via Dart Misc]

Post by Warren
Kudos Bob - this looks awesome! I like the summary page, and the layout
(green/red) is easy to follow.

All credit to the design and layout goes to our awesome tech writer and dev
rel folks. I just did the content. :)

– bob

[tatumizer-v0.2]

Post by 'Bob Nystrom' via Dart Misc
In practice, I don't think it's a super useful signal anyway

It can make a more useful signal if dart starts flagging uninitialized
vars. Not nulls as such, but only nulls of "uninitialized" variety. No
changes in the language are necessary for this. If compiler cannot prove
that the variably was initialized - print warning, which could be
suppressed only by conditional (or special annotation?), or by explicit
initialization to null. This will help address a large percentage of NPEs
(don't know how large this percentage is, pretty sure it's greater than
50). I think the war against *all nulls* is a counterproductive
proposition (we already had some discussion about it) (Again, this is
based on the above assumption of "large percentage", otherwise it won't
make sense).

BTW, It's easy to prove that the fight against *all nulls* is a logical rat
hole - it will suffice to consider how the problem is handled in some
"popular" languages that claim to be null-safe, but in fact are anything
but (basically, they only ban the word 'null', by sweeping it under the
carpet). But it's beyond the scope right now :)

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2

Post by 'Bob Nystrom' via Dart Misc
In practice, I don't think it's a super useful signal anyway

It can make a more useful signal if dart starts flagging uninitialized
vars. Not nulls as such, but only nulls of "uninitialized" variety. No
changes in the language are necessary for this. If compiler cannot prove
that the variably was initialized - print warning, which could be
suppressed only by conditional (or special annotation?), or by explicit
initialization to null.

That might be nice, but it would have to do some kind of flow-sensitive
analysis. We're hoping to improve type promotion at some point, so that
might feed naturally into this.

Even then, it would only handle local variables. That doesn't cover the
very large number of fields and top-level variables that are not
initialized at their declaration but should get initialized before they are
read. I don't think there's a reasonable static analysis that covers those.

Cheers!

– bob