Why is a constructor defined before parameter declaration?

Question

In dart and flutter code, it is common use to declare a constructor BEFORE a classes' parameters/instance variables, e.g.:

class Example {
    // Constructor BEFORE parameters
    Examples(this.name, this.profession);

    final String name;
    final String profession;
}

Coming from php, I am used to a different ordering, which is: parameters first:

class Example {    
    final String name;
    final String profession;

    Examples(this.name, this.profession);
}

(To my knowledge this is how it's done in my other languages, too, like Java, Ruby, C#...)

In Dart's coding style guidelines at https://dart.dev/guides/language/effective-dart/style this "phenomenon" is not addressed and do far I didn't find any other source that talks about it.

Here is an example from a "Cloud Next '19" presentation, code presented by flutter core dev members: https://youtu.be/RpQLFAFqMlw?t=1070

And even the out-of-the-box counter app, that you get, when creating a new flutter project via flutter create, uses this ordering:

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  // This widget is the home page of your application. It is stateful, meaning
  // that it has a State object (defined below) that contains fields that affect
  // how it looks.

  // This class is the configuration for the state. It holds the values (in this
  // case the title) provided by the parent (in this case the App widget) and
  // used by the build method of the State. Fields in a Widget subclass are
  // always marked "final".

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

Does anybody know, why Dart chooses to do it differently?

Answer 1

This is just a style convention used by the flutter team and is documented in their style guide.

The main reason for this decision is:

This helps readers determine whether the class has a default implied constructor or not at a glance.

and further

If it was possible for a constructor to be anywhere in the class, then the reader would have to examine every line of the class to determine whether or not there was an implicit constructor or not.

For other elements, i.e. members, methods, static fields, etc. there is no clear ordering defined in the flutter style guide:

The methods, properties, and other members of a class should be in an order that will help readers understand how the class works.

But if there is no obvious order, the style guide suggests the following:

1. Constructors, with the default constructor first.

2. Constants of the same type as the class.

3. Static methods that return the same type as the class.

4. Final fields that are set from the constructor.

5. Other static methods.

6. Static properties and constants.

7. Mutable properties, each in the order getter, private field, setter, without newlines separating them.

8. Read-only properties (other than hashCode).

9. Operators (other than ==).

10. Methods (other than toString and build).

11. The build method, for Widget and State classes.

12. operator ==, hashCode, toString, and diagnostics-related methods, in that order.

All quotes taken directly from the style guide.