Are there already opinions or standard approaches ...

# ktlint

[maxmello]

Are there already opinions or standard approaches for context parameter rules?
• Would we want to ensure a certain ordering of context parameters? Alphabetically? Named before underscore-parameters?
• Do we think there will be a “maximum number of context parameters” rule? Is there a point where it would be recommended to wrap context parameters into grouped objects if the number of parameters is too large? Or are large numbers of context parameters expected to be common, as higher level functions will always have to accommodate all parameters required by the nested functions?
• Would we enforce underscores as name for context parameters if the parameter is not directly used inside the function? What about open/abstract functions, would we always use underscore here, or keep the naming identical for the super function as well as all the implementations?

[Paul Dingemans]

You raise a number of good questions here. But I do think that some all of them are outside the scope of Ktlint, and would better fit in static code analyzers like Detekt, or Sonar.

• Would we want to ensure a certain ordering of context parameters? Alphabetically? Named before underscore-parameters?

We have no sorting rule for parameters in classes and functions in ktlint. Why would sorting the context parameter be handled differently? Enforcing that named context parameters go before anonymous parameters is definitely possible, but it comes with the same question what the benefit is.

• Do we think there will be a “maximum number of context parameters” rule? Is there a point where it would be recommended to wrap context parameters into grouped objects if the number of parameters is too large? Or are large numbers of context parameters expected to be common, as higher level functions will always have to accommodate all parameters required by the nested functions?

There is no rule for maximum number of parameter in classes and rules in ktlint. Why would we need such a rule?

• Would we enforce underscores as name for context parameters if the parameter is not directly used inside the function? What about open/abstract functions, would we always use underscore here, or keep the naming identical for the super function as well as all the implementations?

I am not sure whether ktlint could reliably detect that a context parameter is not used by name. Also here, it comes with the same question why we should do so for context parameters while we don't do this for classes and functions.

[maxmello]

You are correct, I guess these do fit more into detekt mostly. My original thought was only about the first bullet point and then I got carried away with additional ideas 😄 Thank you for your response though

[maxmello]

I was also originally looking for a channel to discuss code style and best practices more in general, but could not find one.

And w.r.t. the first point: As I am currently refactoring some code that does use a number of context parameters, also in polymorphic structures, I thought about how to do it the “best” or lets say in a consistent way. Since context parameters are not passed down into a function ordered, I guess there are more possibilities to just enforce some order rule that would help readability. But then, points two and three come more into play - should there even be that many context parameters on a function, or is that a code smell in and of itself.

[Paul Dingemans]

I guess we have to wait for a more broad adoption of context parameters. Once good practices have emerged, we can think about offering more support. Or you can write a custom ktlint rule that does the sorting for you 😉