RFC: New convention proposal - class's attributes declaration grouping and ordering

[minhnimble]

Issue

When reviewing the latest changes to our Android template, it is realized that there is not a properly-defined convention anywhere for grouping and ordering the ViewModel's attributes declaration or even broader, class attributes. This lead to the fact that additional changes can happen from time to time, which is actually can be efficiently avoided. For example, here is an attributes order change after changing the attribute's access level due to no convention:

#441 (comment)

While this matter can sound trivial, the first clear benefit is that we can completely avoid random changes happening to the order of the attributes, thus allowing the PR to focus on really matter parts like logic, UI, etc. Additionally, having a clear convention from the beginning can help us efficiently manage, add, and update the attributes, especially when there is already a long list of attributes, thus gaining more efficiency in coding time. Lastly, defining the order with a predefined rule on the importance can help developers realize important attributes vs. non-important ones by looking at the ordering and grouping.

Solution

Thanks to @luongvo's suggestion idea, the solution won't be too complicated that we can easily follow:

• First, group the attributes into groups using the following two combinations listed with left-to-right ordering priority: first - access level (e.g., public >> internal >> private), and combine with - attribute type: (e.g., val >> var >> non-val >> non-var). Here is a quick example of 4 common options sorted using the above ordering convention:

  • public val attribute.
  • public non-val attribute.
  • private val attribute.
  • private non-val attribute.

• Then, among the above groups, keep must-have attributes (e.g., dispatcher) on top, then optional attributes (e.g., use cases).

• Lastly, when attributes have the same level of importance, sort them alphabetically.

Who Benefits?

Android folks

What's Next?

• Vote to go with the new convention proposal or not
• Add the convention to Compass if the majority vote for YES

[ryan-conway]

I'm not sure I understand the second line 👀

Then, among the above groups, keep must-have attributes (e.g., dispatcher) on top, then optional attributes (e.g., use cases).

Based on the first line, we will order the arguments like this:

class SomeClass(
    val height: Double,
    private val age: Int,
    private val context: Context,
    name: String,
)

But based on the second, I'm not entirely sure which order we should follow 🤔

// Required attributes at the top of each group
class SomeClass(
    val height: Double,
    private val context: Context,
    private val age: Int,
    name: String,
): AbstractClass(context, name)

// Required attributes at the top of the entire group
class SomeClass(
    private val context: Context,
    name: String,
    val height: Double,
    private val age: Int,
): AbstractClass(context, name)

[lydiasama]

Is it possible to combine this to this RFC? It would be great if we think about the default case too. @minhnimble