Issue #17841: Add GoogleMethodNameCheck to fix method name false nega…

[vivek-0509]

Issue: #17841

Description

Introduces a new GoogleMethodName check that properly validates method names according to the Google Java Style Guide, fixing false-negatives where underscores between letters and digits were not being flagged.

Problem

The previous MethodName check failed to detect invalid names like:

• gradle_9_5_1() - underscore between letter 'd' and digit '9'
• jdk_9_0_392() - underscore between letter 'k' and digit '9'

Solution

Created a dedicated GoogleMethodName check that:

• Has no configurable properties
• Uses multi-pattern validation instead of one complex regex
• Handles @Test methods separately (underscores allowed)
• Properly validates numbering suffixes (guava33_4_5 is valid)

Validation Rules

Regular Methods:

• Must be in lowerCamelCase
• Underscores only between adjacent digits (_4_5)
• Not between letter and digit (gradle_9 invalid)

Test Methods (@Test, @ParameterizedTest, @RepeatedTest):

• Underscores allowed to separate components
• Each segment must be lowerCamelCase
• Each segment must be at least 2 characters
• Segments cannot start with single lowercase followed by uppercase (e.g., fO)

Override Methods:

• Methods with @Override annotation are skipped (no validation)

Breaking Changes

None. This check is backward compatible with the previous MethodName regex behavior.

New module config: https://gist.githubusercontent.com/vivek-0509/6733c4a828cc940c59db1c7af371a806/raw/4758b044822977e75ba30138eefa3a9b3c2026f7/google-method-name.xml

Contirbution repo PR: checkstyle/contribution#1000

[vivek-0509]

The CI Failures are unrelated

[vivek-0509]

Github, generate report for GoogleMethodName/all-examples-in-one

[github-actions]

Failed to download or process the specified configuration(s).
Error details:

Please ensure you've used one of the following commands correctly:

• 'GitHub, generate report for <config_bundle_path>'
• 'GitHub, generate report by config from <file_path>'
• 'GitHub, generate report for configs in PR description'
  
  And check that all specified configs or files exist and are valid.
  
  Link: https://github.com/checkstyle/checkstyle/actions/runs/20267426773

[vivek-0509]

GitHub, generate report

[vivek-0509]

GitHub, generate report

[vivek-0509]

GitHub, generate report

[github-actions]

Report generation failed on phase "make_report",
step "Generate report".
Link: https://github.com/checkstyle/checkstyle/actions/runs/20292237473

[vivek-0509]

GitHub, generate report

[github-actions]

https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/2f3db4a_2025055802/reports/diff/index.html

[vivek-0509]

Hey @romani,
Here is the analysis of the report

Bug Found (Will Fix)

Issue: Test methods with numbering suffix like test3_1 are incorrectly rejected.

Cause: The implementation doesn't strip numbering suffix before validating test methods (unlike regular methods).

Examples:

• test3_1 → Rejected (Should be valid - 3_1 = adjacent numbers)
• testFoo_1_2 → Rejected (correctly invalid)

Fix: Will add numbering suffix stripping + INVALID_UNDERSCORE_PATTERN check for test methods.

---

Design Questions - Need Your Input

1. Single lowercase + Uppercase pattern (xAmbar, pLevel, eMeSinE)

Original MethodName regex has (?![a-z][A-Z]) which rejects names starting with single lowercase followed by uppercase , i kept the same behaviour for the new check, but google style guide does not mention anything regarding this according to the loweCamelCase rule it should be valid.

Examples:

• xAmbar → Rejected (arguably valid lowerCamelCase: x + Ambar)
• xPathRuleQueryNeedsInitialization → Rejected

Question: Keep for backward compatibility, or fix as bug?

2. Minimum 2-character segment requirement for test methods

Currently rejects single lowercase character segments:

Examples:

• t_name → Rejected (segment t = 1 char)
• test_a → Rejected (segment a = 1 char)
• test_foo → Valid (both segments ≥ 2 chars)

Real example:

@Test
void can_be_used_in_a_collector() {} //  Rejected (segment a fails)

Question: Keep 2-char minimum or allow single-char segments?

3. Test methods without @test annotation

Examples:

• void test_ctor_shouldThrow_whenPidIsMissing() → REJECTED (no annotation)
• @Test void test_ctor_shouldThrow_whenPidIsMissing() → VALID

Supported annotations: @Test, @ParameterizedTest, @RepeatedTest

Question: Should test-style method names without annotations be rejected, as Google Style only mentions JUnit tests?

[vivek-0509]

@romani ping

[romani]

@Zopsss , can you help me to review this PR?
while I am busy with general stream of PRs.

[vivek-0509]

Will fix the CI asap , failures caused due to recent pr merge method access level for getPackageLocation() changed to pubilc

[vivek-0509]

Hi @Zopsss ,

Before you review the code, I'd like to clarify my understanding of the expected rules for GoogleMethodNameCheck , as Google Style Guide is somewhat ambiguous in places.

For regular methods (without @Test), my implementation requires lowerCamelCase names where underscores are only allowed between adjacent numbers (like guava33_4_5). Names like gradle_9_5_1 with letter_digit underscores are flagged as invalid. Single letter names like f and patterns like fO are also rejected.

For test methods (with @Test, @ParameterizedTest, @RepeatedTest), underscores are allowed to separate logical components, with each component being lowerCamelCase. So transferMoney_deductsFromSource is valid, but test_1 is invalid because 1 is not lowerCamelCase and also it violates the no underscore between just number and digit. The numbering suffix rule also applies, so test3_1 is valid (adjacent numbers), but testFoo_1_2 is invalid (letter_digit pattern). For test methods like solve6x6_returnsTrue and solve6x6_noSolution_returnsFalse, my implementation treats them as valid since each component (solve6x6, returnsTrue, noSolution, returnsFalse) is lowerCamelCase and the underscore separates these components rather than being between a digit and letter within a component.

One thing I'm unclear about: Google Style says test components should be "lowerCamelCase". Strictly speaking, lowerCamelCase means multiple words joined with capitalization (like transferMoney). Should single-word components like test_foo be valid, or should we require multi-word lowerCamelCase like transferMoney_deductsFromSource?

If any of my expectations don't align with what's actually required, please let me know and I'll adjust my implementation before you do a full code review. This should save time .