RecordFlux icon indicating copy to clipboard operation
RecordFlux copied to clipboard

Deactivation of style checks

Open treiher opened this issue 2 years ago • 4 comments

Context and Problem Statement

In some cases, the style checks cannot be fulfilled or it is not intended to fulfill all style checks. In such cases, it should be possible to disable certain style checks.

Use Cases

UC1: Generated specifications

In particular, the line length checks cannot be guaranteed in all cases.

UC2: Protyping

During prototyping, the style checks could be annoying.

Considered Options

O1 Global deactivation of style checks (e.g., by CLI option)

No differentiation between different files possible (e.g., manually written specification vs. generated specification)

O2 Local deactivation using comments

Specific style checks can be disabled using comments on a file level, block level or line level similar to the messages control of pylint.

All checks can be disabled using style: disable = all.

Example
         Untagged_Value_data_trap_Value_specific_trap_Untagged_Length : Prelude::Asn_Length
            then Untagged_Value_data_trap_Value_specific_trap_Untagged_Value
               with Size => Untagged_Value_data_trap_Value_specific_trap_Untagged_Length * 8;
         -- style: disable = line-too-long
         Untagged_Value_data_get_next_request_Value_variable_bindings_Untagged_Value : RFC1157_SNMP::Asn_Raw_SEQUENCE_OF_VarBind
            then null;
         -- style: enable = line-too-long

+ Flexible

Decision Outcome

O2 (initially, only support style: tag at the beginning of the file)

treiher avatar Jun 20 '22 16:06 treiher

It seems to me that the CLI switch fits best for prototyping, and the comments are best for generated code. Ideally we would have both solutions then. A way to make the comments work for prototyping would be to have a single comment at the top of the file that disables all style checking.

kanigsson avatar Jun 20 '22 22:06 kanigsson

I have found the "pragma style" proposed in the snippet a bit misleading, since pylint also supports disabling all or some lints just for one line.

What about:

         Untagged_Value_data_trap_Value_specific_trap_Untagged_Length : Prelude::Asn_Length
            then Untagged_Value_data_trap_Value_specific_trap_Untagged_Value
               with Size => Untagged_Value_data_trap_Value_specific_trap_Untagged_Length * 8;
         -- style: disable-next = line-too-long
         Untagged_Value_data_get_next_request_Value_variable_bindings_Untagged_Value : RFC1157_SNMP::Asn_Raw_SEQUENCE_OF_VarBind
            then null;

See also: # noqa in flake8

rami3l avatar Jun 21 '22 08:06 rami3l

@rami3l The example just shows one example for disabling style checks on a block level. The description of O2 explicitly mentions that the checks could also be disabled for single lines or the whole file, similarly as it is done with pylint. The noqa of flake8 only allows to suppress checks on single lines and thus is much less powerful.

treiher avatar Jun 21 '22 09:06 treiher

@treiher Thanks for your clarification.

I had carefully read the description for O2 and the pylint link you posted before posting the comment, and I'm aware of the requirement of toggling checks on the block level.

I just wanted to point out that:

  • For the example you posted, the "pragma" style seems a bit too verbose;
  • From a codegen's point of view, adding something like # noqa at the end of each "long" line while printing the file seems like a good starting point.

rami3l avatar Jun 21 '22 09:06 rami3l