Repository: flutter
Issue: Update Flutter Style Guide for "Order other class members in a way that makes sense"
Labels: d: wiki,P3,team-framework,triaged-framework

Issue

The Flutter Style Guide provides valuable guidance for maintaining a consistent codebase. However, there's a specific guideline regarding the order of methods in Flutter widgets [https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#order-other-class-members-in-a-way-that-makes-sense](https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#order-other-class-members-in-a-way-that-makes-sense) that might benefit from some adjustments.

**Proposal**

The current style guide recommends ordering methods so that _"build" comes after other methods_, including overridable methods. This can be counterintuitive and less aligned with common best practices for structuring Flutter widget code.

In practice, and alignment with the "One Level of Abstraction per Function" principle, it is often more intuitive to order methods in the following way:

1. Overridden methods, except for "dispose," should be placed before the "build" method.
2. The "build" method for Widget and State classes.
3. dispose (if it is a `StatefulWidget`)
4. Private methods, such as utility functions, are placed after the `build` method.

This ordering is consistent with Flutter's implementation of certain widgets, such as `FutureBuilder`, and it can enhance code readability and maintainability.

**Suggested Revision**

I propose revising the Flutter Style Guide to recommend this adjusted method order explicitly. This change can help maintain code consistency across Flutter projects and better align with the practices that Flutter developers commonly follow. The revised section in the style guide could look like this:


> If no particular order is obvious, then the following order is suggested, with blank lines between each one:
> 
> 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. Members for mutable properties, without new lines separating the members of a property, each property in the order:
> 
> - getter
> - private field
> - setter
> 
> 8. Read-only properties (other than hashCode).
> 9. Operators (other than ==).
> 10. Overridden methods (except for dispose).
> 11. The build method, for Widget and State classes.
> 12. dispose (if it is a StatefulWidget)
> 13. Private methods.
> 14. operator ==, hashCode, toString, and diagnostics-related methods, in that order.


This update provides more flexibility and allows developers to create code that is easier to read, understand, and maintain. It also better aligns with the practices used in the Flutter framework itself.

Community Input

I'd like to hear from the Flutter community on this proposal. Please share your thoughts, feedback, and suggestions regarding this potential change to the Flutter Style Guide. If there is consensus, we can work towards updating the official style guide to reflect these improvements.