CODEWITHSUNDEEP
flutterdart
Robert Wildling
Robert Wildling

Reputation: 1186

Why is a constructor defined before parameter declaration?

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?

Upvotes: 14

Views: 4405

Answers (3)

Azii jethwa
Azii jethwa

Reputation: 1

making a constructor in the class means that the class allows us to create different instances of our class, for example, if we have one car in class & by using a class of cars we make 100 cars.

Upvotes: -1

user1195608
user1195608

Reputation:

With respect to constructors, the Flutter style guide differs from the Dart style guide, two guides, which otherwise have a lot in common. So while the Dart's style guide does indeed not mention anything like "constructor first" nor do any code examples give the impression of such a recommendation, Flutter has come up with its own style guide, as mentioned and linked to before by DaGardner. The reason for that is that there are widgets with A HUGE AMOUNT OF parameters, which seems to be quite flutter specific.

Further discussion can be found at: https://github.com/flutter/flutter/issues/1220 https://github.com/dart-lang/linter/issues/186

Upvotes: 7

DAG
DAG

Reputation: 6994

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.

Upvotes: 17

Related Questions