Make cabal files conform to style guide #271

ivanperez-keera · 2022-03-16T11:52:53Z

Having a style guide for projects helps maintain and read code. This lowers the maintenance cost and makes it easier to introduce, evaluate, and approve changes.

I recently introduced a style guide for cabal files in Yampa. I would like to do the same here. Using the same guide for both projects will make things simpler for me, since I maintain both.

The goal of this task is to apply the rules of this Cabal style guide to all cabal files in this project.

To implement this issue, I would like to ask that:

The rules in the guide are applied IN ORDER, one per commit. For example, the same commit should NOT apply both line wrapping rules (80-character column limit) and element re-ordering rules.
The summary of each commit should point to the rule being applied in the format described in that issue (see ivanperez-keera/Yampa@1e3655b, for an example; notice that there is no line wrapping in the headline, it is an artifact of github).
The body of the commit could include a description of the rule. When the rule is too long, it can contain a summary or only those specific aspects that are relevant for the portion of the code being adjusted.

Please see issue ivanperez-keera/Yampa#196, and the commits associated to that issue, for details.

The text was updated successfully, but these errors were encountered:

ivanperez-keera · 2022-03-16T11:53:55Z

It would be fine to apply this to dunai and bearriver only, for now, and later adjust also the examples in a separate issue.

All Cabal files must include a copyright notice in a comment at the top of the file. The copyright notice must have the format: -- Copyright (c) YEAR - HOLDER - RIGHTS RESERVED

…. Refs #271. The Cabal file must include a cabal-version declaration in the first line after the copyright notice. The build type declaration may affect the interpretation or effect of some fields, and must follow the Cabal version declaration.

…271. Package metadata should be in the following order: - name - version - author - maintainer - homepage - license - license-file - copyright - category - synopsis - description - data-files, if applicable

… Refs #271. A Cabal file consists of, in order: 1. License or copyright information 2. Cabal version declaration and build type declaration 3. Package metadata 4. Source repository declarations, if present 5. Flag declarations, if present 6. Libraries, if present 7. Executables, if present 8. Tests, if present 9. Benchmarks, if present

Fields within library, executable, test suites and benchmarks are listed in the following order: - type, if applicable - main-is, if applicable - exposed-modules, if applicable - other-modules, if applicable - build-depends - default-language - hs-source-dirs - compiler options - flag-dependent configuration

Modules listed in fields such as exposed-modules and other-modules should always be listed in alphabetical order, one module per line.

….3). Refs #271. Packages listed in fields such as build-depends should always be listed one package per line, with the comma that separates items being the first character in the line.

We set the code limit for Cabal files at 80 characters.

For all settings in libraries, executables, tests and benchmarks, their values should be set in a new line. The new line starts an indented block. This applies irrespectively of whether the value could fit within the same line as the keyword that introduces it.

A single blank line always appears: 1. Between consecutive sections. 2. Between consecutive entries of a section. - Exception: A blank line between two consecutive fields guarded by the same flag condition is optional. Such blank lines are used as needed to create logical groupings of fields.

…). Refs #271. 4.6.4 Horizontal whitespace: always required Beyond where required by the language or other style rules, and apart from literals and com- ments, a single ASCII space also appears in the following places. [...] 2. On both sides of any binary or ternary operator.

Horizontal alignment is required in the following: - for the values of the fields denoting the Cabal version, the build type, and other package metadata, except when the values of those fields are given in a separate line. It is also added for field fields in flags.

All Cabal files must include a copyright notice in a comment at the top of the file. The copyright notice must have the format: -- Copyright (c) YEAR - HOLDER - RIGHTS RESERVED

…. Refs #271. The Cabal file must include a cabal-version declaration in the first line after the copyright notice. The build type declaration may affect the interpretation or effect of some fields, and must follow the Cabal version declaration.

…271. Package metadata should be in the following order: - name - version - author - maintainer - homepage - license - license-file - copyright - category - synopsis - description - data-files, if applicable

… Refs #271. A Cabal file consists of, in order: 1. License or copyright information 2. Cabal version declaration and build type declaration 3. Package metadata 4. Source repository declarations, if present 5. Flag declarations, if present 6. Libraries, if present 7. Executables, if present 8. Tests, if present 9. Benchmarks, if present

Fields within library, executable, test suites and benchmarks are listed in the following order: - type, if applicable - main-is, if applicable - exposed-modules, if applicable - other-modules, if applicable - build-depends - default-language - hs-source-dirs - compiler options - flag-dependent configuration

Modules listed in fields such as exposed-modules and other-modules should always be listed in alphabetical order, one module per line.

….3). Refs #271. Packages listed in fields such as build-depends should always be listed one package per line, with the comma that separates items being the first character in the line.

We set the code limit for Cabal files at 80 characters.

For all settings in libraries, executables, tests and benchmarks, their values should be set in a new line. The new line starts an indented block. This applies irrespectively of whether the value could fit within the same line as the keyword that introduces it.

A single blank line always appears: 1. Between consecutive sections. 2. Between consecutive entries of a section. - Exception: A blank line between two consecutive fields guarded by the same flag condition is optional. Such blank lines are used as needed to create logical groupings of fields.

…). Refs #271. 4.6.4 Horizontal whitespace: always required Beyond where required by the language or other style rules, and apart from literals and com- ments, a single ASCII space also appears in the following places. [...] 2. On both sides of any binary or ternary operator.

Horizontal alignment is required in the following: - for the values of the fields denoting the Cabal version, the build type, and other package metadata, except when the values of those fields are given in a separate line. It is also added for field fields in flags.

All Cabal files must include a copyright notice in a comment at the top of the file. The copyright notice must have the format: -- Copyright (c) YEAR - HOLDER - RIGHTS RESERVED

…). Refs #271. 4.6.4 Horizontal whitespace: always required Beyond where required by the language or other style rules, and apart from literals and comments, a single ASCII space also appears in the following places. [...] 2. On both sides of any binary or ternary operator.