Skip to content

Conversation

@mohitsatr
Copy link
Member Author

Github, generate report

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

items:

@mohitsatr
Copy link
Member Author

Github, generate report

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

dissent !

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

from guideline:

for example transferMoney_deductsFromSource. There is no One Correct Way to name test methods.

in regression report we have https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/a4eaf13_2025072930/reports/diff/guava/index.html#A125
bunch of similar namings, that are still violation.

we need to have separate issue if we want to addreess them in separately.

Comment on lines 427 to 428
<property name="format" value="^[a-z][a-z0-9][a-zA-Z0-9]*$"/>
<property name="format" value="^[a-z](?:[a-z0-9][a-zA-Z0-9]*|[a-z0-9]*[0-9](?:_[0-9]+)*)$"/>
Copy link
Member

Choose a reason for hiding this comment

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

why MethodName and MemberName regex is different? Shouldn't it be same? @mohitsatr

Copy link
Member

@Zopsss Zopsss Sep 9, 2025

Choose a reason for hiding this comment

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

MethodName:
value="^[a-z](?:[a-z0-9][a-zA-Z0-9]*|[a-z0-9]*[0-9](?:_[0-9]+)*)$"

MemberName:
value="^(?![a-z]$)(?![a-z][A-Z])[a-z][a-z0-9]*(?:[A-Z][a-zA-Z0-9]*|[0-9](?:_[0-9]+)*)?$"

Copy link
Member Author

Choose a reason for hiding this comment

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

They are shortened and simplifed versions to save line length.

Copy link
Member

Choose a reason for hiding this comment

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

lets keep all regexp the same, it will clearly shows that rules of format is same.

@mohitsatr
Copy link
Member Author

@romani we cover these names. I tested them locally. I forgot to include the Suppression in the regression config.

@mohitsatr
Copy link
Member Author

Github, generate report

@romani
Copy link
Member

romani commented Sep 9, 2025

such methods does not have @Test so that is why it stays as violation https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/a4eaf13_2025122759/reports/diff/guava/index.html#A3

am I right?
strange that kind of same in our Inputs are ok.

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

items:

@Zopsss
Copy link
Member

Zopsss commented Sep 10, 2025

such methods does not have @test so that is why it stays as violation

Normal methods & Test methods, both follows lowerCamelCase so both of them follows same naming conventions.

https://google.github.io/styleguide/javaguide.html#s5.2.3-method-names


The current regex we're using doesn't allow for camel casing characters and digits together, for example testTest99_99, test_Test, testTest_Test, etc. Please adjust the regex according to this @mohitsatr

@mohitsatr
Copy link
Member Author

@Zopsss @romani

Underscores may appear in JUnit test method names to separate logical components of the name

Underscores are only allowed in test method. we can't put them in normal Method names. Normal methods & Test methods, both use same regex format. so we allow the following formats, we are also making underscores valid for normal functions.

testTest99_99
test_Test
testTest_Test

@Zopsss
Copy link
Member

Zopsss commented Sep 11, 2025

Underscores are only allowed in test method. we can't put them in normal Method names. Normal methods & Test methods, both use same regex format. so we allow the following formats, we are also making underscores valid for normal functions.

From style guide: https://google.github.io/styleguide/javaguide.html#s5.2.3-method-names

Method names are written in lowerCamelCase.
....
Underscores may appear in JUnit test method names to separate logical components of the name, with each component written in lowerCamelCase, for example transferMoney_deductsFromSource. There is no One Correct Way to name test methods.

from lowerCamelCase rule:

In very rare circumstances (for example, multipart version numbers), you may need to use underscores to separate adjacent numbers, since numbers do not have upper and lower case variants.

In the style guide it is mentioned that method names should be in lower camel case ( which allows for underscores ) and it is also separately mentioned that JUnit test methods can also use underscores.

So it is a bit confusing, if normal methods are allowed to have underscores or not. It is mentioned that Method names are written in lowerCamelCase which allows for underscores, so I think we should also allow for it? @romani @mohitsatr please share your opinion.

@mohitsatr
Copy link
Member Author

mohitsatr commented Sep 11, 2025

@Zopsss

In very rare circumstances (for example, multipart version numbers),

Let's not think of Multipart version number methods as normal methods. #17708 (comment)

@Zopsss
Copy link
Member

Zopsss commented Sep 11, 2025

Style guide has mentioned that normal methods can use lowerCamelCase, which means it can have underscores. @romani please correct me if I'm wrong.

@romani
Copy link
Member

romani commented Sep 12, 2025

Unfortunately Google style is not exact.
From one side they say that _ can be used in test methods to combine sentences. From another side in general camel case explanation, _ is allowed for numbers in all names(except package and generic names).

So if we can not write Regexp that decently covers allowance of _ before digits. We need to allow _ and update coverage table that false negatives to catch illegal underscore will be done when we finish new Check creation, might be not this year.

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

items:

@romani
Copy link
Member

romani commented Sep 12, 2025

For methods: allow underscore Only between sentences for tests and for all methods between digits.
Underscore is valid separator of digits in all names, even in class names

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

sounds like Regexp is not possible/reasonable to use in such complicated requirements, right ?
if you agree, lets write issue(s) on new Check(s) creation to cover requirements and finish with this PR. We did big effort, and we proved that regexp is not working any more.

items:

@mohitsatr mohitsatr force-pushed the membername_ branch 3 times, most recently from 8513ab3 to ed677a5 Compare September 25, 2025 11:56
Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

last:

@romani
Copy link
Member

romani commented Sep 25, 2025

Github, generate report

@romani
Copy link
Member

romani commented Sep 25, 2025

�[1;31mERROR�[m] COMPILATION ERROR : 
[�[1;34mINFO�[m] -------------------------------------------------------------
[�[1;31mERROR�[m] /home/circleci/project/src/it/resources/com/google/checkstyle/test/
chapter5naming/rule53camelcase/
InputUnderscoreUsedInNames.java:[8,24] 
variable guava33_4_6 not initialized in the default constructor

We need to restore default values.
Or better remove "final" from all of them

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

item:

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

item:

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

Last

void kotlinLang1_9_2() {} // violation, false-positive, 'must match pattern'

// violation below, '_' not allowed between lowercase character sequences
void convertToKotlinVersion1_9_24() {} // violation, false-positive, 'must match pattern'
Copy link
Member

Choose a reason for hiding this comment

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

Ok, we need some suppression to avoid false positives.
Suppression config and resulted false negatives should be marked until bsime ticket, please create it,
And we will merge.

Copy link
Member Author

Choose a reason for hiding this comment

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

false-positive for class names will be handled at #17835

@mohitsatr
Copy link
Member Author

Github, generate report

@romani romani force-pushed the membername_ branch 2 times, most recently from 52df831 to 264f9b7 Compare September 28, 2025 00:14
@romani
Copy link
Member

romani commented Sep 28, 2025

class CoverterToKotlinVersion1_9_24 {} // violation, false-positive, 'must match pattern'

was removed. as it was addressed in #17835

@romani romani merged commit 5d52248 into checkstyle:master Sep 28, 2025
119 of 120 checks passed
@romani
Copy link
Member

romani commented Sep 28, 2025

basic implementation is merged
all false negatves will be addressed in next issue

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