New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Enforce consistent module attribute ordering #689
[WIP] Enforce consistent module attribute ordering #689
Conversation
…optional callback This function allows a check to massage the full frequences before determining the real highest match, for the current check this is nessary because not all modules contain necissarily all attributes.
The function merges similar frequencies which share attributes in the correct order but might include an attribute here or there.
…ases If the codebase contains insufficient examples of ordering to determine the preferred way to order two attributes the check falls back to the styleguide's way of ordering
@rrrene Please let's use this draft PR to have a discussion about the approach here. I'm not really happy with the whole merging implementation (especially with the usage of |
@sascha-wolf Thx for putting this together! 👍 I think it enables us to have a deeper discussion surrounding a check for module attribute/macro order. This PR raises the question if this can be molded into a sensible consistency check at all, since we can't know if this can be kept consistent across "real" codebases. I've module attributes that need to be set before a The problem is that we will only know once we have a working version of this 😄 As for the combinatorial problem you mentioned:
Basically This is why
is asking the wrong question. We are not looking for the "correct" order, we are looking for one valid order that all combinations can be mapped to:
Both
Hope this helps to clarify the point of consistency for this case. If you have any questions, feel free to ask 👍 P.S. As an aside:
This should not happen. Consistency checks by nature do not bother the user unless something inconsistent can be detected in the present code (and this exception would yell at the user about a style guide, which Credo does not aim to implement). |
This PR is a work-in-progress (it does not work yet) and an evolution of #588.
Instead of strictly enforcing the styleguide it instead captures the ordering of the module attributes in the whole project, and enforces consistency across the codebase.
Due to the nature of the check it does this a bit different than all other consistency checks. The other consistency checks act on a line-by-line basis but this check looks at the whole module.
It's also special in the way that not all modules necessarily use all module attributes but can still be considered valid. For example:
Has the module attribute order
[:moduledoc, :use, :alias, :require]
, while this module:Has the order
[:use, :import, :alias]
.These two orders do not contradict but rather compliment each other. The correct general order can be inferred:
[:moduledoc, :use, :import, :alias, :require]
As such the check introduces a new optional
transform_frequencies/1
callback forConsistency
checks. This callback is used in the check to merge orders as seen above, which is a surprisingly hard problem. All of this "merging" happens in theMerge
module which has been extracted to ease readability (although the code itself is not really readable.In some cases the check can not determine the preferred order, take the example from above but now imagine
Module2
to have a@type
at the end:In this case the two orders look like this:
As visible it's impossible to determine the correct order from just looking at these two modules. Instead this is handled by checking the order of attributes of all other modules in the order of frequency in the hope that one contains both attributes (
type
andrequire
) to determine the correct order.If this fails too the check falls back to the order listed in the community styleguide and prints a warning.