MetOffice / MetOffice/SimSys_Scripts

Lowercase and CamelCase checking of module imports in UMDP3 checker

Open
#220 0 comments 0 reactions 1 assignee View on GitHub

@Pierre-siddall is already working on this.

Since Apr 28, 2026.

bug
Dominant language
Python
Stars
9
Forks
19
Avg merge
5d 48m
Merged PRs (30d)
4

Description

During the runtime of `umdp3_conformance.py` it was noted that changing module imports to be uppercase did not result in a failure being registered in the output of the script as expected. `umdp3_conformance.py` calls the following code in `umdp3_checker_rules.py`

```python
def lowercase_variable_names(self, lines: List[str]) -> TestResult:
"""Check for lowercase or CamelCase variable names only"""
"""
TODO: This is a very simplistic check and will not detect many
cases which break UMDP3. I suspect the Perl Predecessor concatenated
continuation lines prior to 'cleaning' and checking. Having identified
a declaration, it also then scanned the rest of the file for that
variable name in any case."""
failures = 0
error_log = {}
count = -1
for count, line in enumerate(lines):
clean_line = self.remove_quoted(line)
clean_line = re.sub(r"!.*$", "", clean_line)

# Simple check for UPPERCASE variable declarations
if re.search(
r"^\s*(INTEGER|REAL|LOGICAL|CHARACTER|TYPE)\s*.*::\s*[A-Z_]+",
clean_line,
re.IGNORECASE,
):
clean_line = re.sub(
r"^\s*(INTEGER|REAL|LOGICAL|CHARACTER|TYPE)\s*.*::\s*",
"",
clean_line,
)
if match := re.search(r"([A-Z]{2,})", clean_line):
self.add_extra_error(f"UPPERCASE variable name : {match[1]}")
failures += 1
error_log = self.add_error_log(
error_log, f"UPPERCASE variable name {match[1]}", count +1
)

output = f"Checked {count + 1} lines, found {failures} failures."
return TestResult(
checker_name="Lowercase or CamelCase variable names only",
failure_count=failures,
passed=(failures == 0),
output=output,
errors=error_log,
)
```

addressing this issue will involve a refactor of this function to ensure module level imports are checked.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.