Skip to content

Unifying the style checkers#196

Open
r-sharp wants to merge 12 commits intoMetOffice:mainfrom
r-sharp:unifying_the_style_checkers
Open

Unifying the style checkers#196
r-sharp wants to merge 12 commits intoMetOffice:mainfrom
r-sharp:unifying_the_style_checkers

Conversation

@r-sharp
Copy link
Contributor

@r-sharp r-sharp commented Feb 20, 2026

PR Summary

Sci/Tech Reviewer: @t00sa
Code Reviewer: @ericaneininger

The Abstract class and 2 real classes setup was a bit clunky.
I thought I could merge the two into one real class, but after trying that it transpires I needed a subclass to overwrite the behaviour of the check method for external runners.

Whilst I'm still struggling at times with the Linters VS Code deploys on the desktop, this change seems to have "re-discovered" a bunch of lines that are too long, in a file I'd not touched. There was a messed up "merge of main" which I presume caused this, but I'm just baffled.

Code Quality Checklist

  • I have performed a self-review of my own code
  • My code follows the project's style guidelines
  • Comments have been included that aid understanding and enhance the readability of the code
  • My changes generate no new warnings
  • All automated checks in the CI pipeline have completed successfully

Testing

  • This change has been tested appropriately (please describe)

It has been run on itself, in 'Python' mode, with no errors
In it's default 'Fortran' Mode :
It has been run on a 'um' branch with no failures.
It has been run on a um branch with VAF (Value Added Failures), where it identified the requisite failures.
It has been run on um/main , where it had a whale of a time identifying 874 files (out of 2406) with errors in them.

pytest has been run on the repository, no errors reported.

Security Considerations

  • I have reviewed my changes for potential security issues
  • Sensitive data is properly handled (if applicable)
  • Authentication and authorisation are properly implemented (if applicable)

AI Assistance and Attribution

  • Some of the content of this change has been produced with the assistance of Generative AI tool name (e.g., Met Office Github Copilot Enterprise, Github Copilot Personal, ChatGPT GPT-4, etc) and I have followed the Simulation Systems AI policy (including attribution labels)

Sci/Tech Review

  • I understand this area of code and the changes being added
  • The proposed changes correspond to the pull request description
  • Documentation is sufficient (do documentation papers need updating)
  • Sufficient testing has been completed

(Please alert the code reviewer via a tag when you have approved the SR)

Code Review

  • All dependencies have been resolved
  • Related Issues have been properly linked and addressed
  • Code quality standards have been met
  • Tests are adequate and have passed
  • Security considerations have been addressed
  • Performance impact is acceptable

@r-sharp r-sharp requested a review from t00sa February 20, 2026 19:32
@r-sharp r-sharp added this to the Spring 2026 milestone Feb 20, 2026
@jennyhickson jennyhickson modified the milestones: Spring 2026, Summer 2026 Feb 27, 2026
Copy link
Collaborator

@t00sa t00sa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable. I've made a few comments in-line.

Although this isn't in the scope of the present PR, have you considered moving the command line code, i.e. everything from L611 to the end of the file, out into a __main__.py file? This would allow you to do something like python -m script_umdp3_checker - assuming that the clone of SimSys_Scripts is in your python path - to run the checker as a command while still keeping it as a separate library.

Comment on lines +168 to +170
file_extensions: Set[str] = set(),
check_functions: Dict[str, Callable] = {},
changed_files: List[Path] = [],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initialising mutable types in function signatures is generally to be avoided because it results in the value being implicitly saved between calls. It is generally safer to set them to None and initialise them within the function, e.g.

def from_full_list(cls, name, file_extensions=None):
  file_extensions = file_extensions or set([])

The code seems to have used this method in places, so I'm not sure why it hasn't been used here

return self.name
@staticmethod
def filter_files(
files: List[Path], file_extensions: Set[str] = set()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Default mutable instance in a function signature?

name: str,
commands: List[List[str]],
all_files: List[Path],
file_extensions: Set[str] = set(),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Default mutable instance in a function signature?

r-sharp and others added 3 commits March 3, 2026 16:13
Co-authored-by: Sam Clarke-Green <74185251+t00sa@users.noreply.github.com>
Co-authored-by: Sam Clarke-Green <74185251+t00sa@users.noreply.github.com>
@r-sharp
Copy link
Contributor Author

r-sharp commented Mar 3, 2026

Having been forced to think about the intention on those function arguments (Default mutable instance in a function signature ?), I've made most of them required.
The one that remians options is now defaulted to None as the 'use' of the contents is protected with an "if variable:" switch.

@r-sharp r-sharp requested a review from t00sa March 3, 2026 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants