-
-
Notifications
You must be signed in to change notification settings - Fork 52
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
yampa
: Conformance with style guide
#266
Comments
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
The module declaration should explicitly list the definitions exported by the module.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
The module declaration should explicitly list the definitions exported by the module.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…). Refs #266. The module declaration should use haddock indicators to group the elements exported so as to facilitate navigating the documentation.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…). Refs #266. The module declaration should use haddock indicators to group the elements exported so as to facilitate navigating the documentation.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be grouped between external imports, external imports from the same project (but different libraries) and internal imports. When groups are used, comments must be used to indicate the nature of each group. If there are no distinct groups, they are considered to be all in the same group.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…Refs #266. Imports belonging to the same group should be listed in alphabetical order.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…Refs #266. Elements imported from a module should be listed in alphabetical order.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be explicit (aka. no wildcard imports).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be explicit (aka. no wildcard imports).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be explicit (aka. no wildcard imports).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be explicit (aka. no wildcard imports).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be explicit (aka. no wildcard imports).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Imports should be explicit (aka. no wildcard imports).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Do not wrap expressions in parenthesis unnecessarily.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…efs #266. Prefer where appearing alone on a single line, not at the end of a line or on the same line as the definition it introduces.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…efs #266. Prefer where appearing alone on a single line, not at the end of a line or on the same line as the definition it introduces.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…efs #266. Prefer where appearing alone on a single line, not at the end of a line or on the same line as the definition it introduces.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…efs #266. Prefer where appearing alone on a single line, not at the end of a line or on the same line as the definition it introduces.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
When allowed, prefer where to let clauses (except as needed in do blocks and arrow blocks).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
When allowed, prefer where to let clauses (except as needed in do blocks and arrow blocks).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
When allowed, prefer where to let clauses (except as needed in do blocks and arrow blocks).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
When allowed, prefer where to let clauses (except as needed in do blocks and arrow blocks).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
When allowed, prefer where to let clauses (except as needed in do blocks and arrow blocks).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
When allowed, prefer where to let clauses (except as needed in do blocks and arrow blocks).
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…kell 1.3.0 - 5.5). Refs #266. Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…kell 1.3.0 - 5.5). Refs #266. Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…kell 1.3.0 - 5.5). Refs #266. Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…kell 1.3.0 - 5.5). Refs #266. Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…kell 1.3.0 - 5.5). Refs #266. Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…kell 1.3.0 - 5.5). Refs #266. Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
…kell 1.3.0 - 5.5). Refs #266. Prefer consistent names, structure, and improvements over localized optimizations. For example, a module might define an API in a particular order, and a module with a similar but distinct API might list elements in a completely different order. Whenever possible, code should be consistent.
ivanperez-keera
added a commit
that referenced
this issue
Apr 29, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Several issues in the past have looked at conformance with the style guide, namely #255, #215, #214, #213, #212, #211, #207, #206, #205, #202, #200.
Although the current code is mostly conformant and fully conforms with the main rules and with any rules we can (currently) detect automatically, some suggestions that we really want implemented and some mandatory rules, are not being implemented. These include, for example, spaces after commas, where in a separate line, and explicit imports.
To finalize anything related to conformance with style guides in the Yampa library, we should do a final pass for style and make sure all code is conformant with the current recommendations.
The text was updated successfully, but these errors were encountered: