var-naming: improve underscore detection with _test package

[ccoVeille]

A package name like this one would be accepted by the code

• foo_bar_test

The current code is like this

// Package names need slightly different handling than other names.
	if strings.Contains(walker.fileAst.Name.Name, "_") && !strings.HasSuffix(walker.fileAst.Name.Name, "_test") {
		walker.onFailure(lint.Failure{
			Failure:    "don't use an underscore in package name",
			Confidence: 1,
			Node:       walker.fileAst.Name,
			Category:   lint.FailureCategoryNaming,
		})
	}

Source: https://github.com/mgechev/revive/blob/57ed899d0ce6ab78ad51cb83e67d2d9d32873eb2/rule/var_naming.go#L80-90

So anything that contains more than a _ and and with _test is accepted.

I think about using (pseudo-code)

• strings.CutSufix(packageName, "_test")
• then check if it was present
• then strings.Contains(packageNameWithoutTestSuffix, "_")

Originally posted by @ccoVeille in https://github.com/mgechev/revive/pull/1312#discussion_r2037874530

[ccoVeille]

This one will require the pending PR on var-naming is merged

• #1312

[buzzdan]

Ok this one looks very useful 😎

Will it help to enforce flatcase package name? (and flatcase_test)

Also, are we comparing the directory name to the package name to see its the same?

@ccoVeille and @alexandear thank you for all your hard work!

[ccoVeille]

I feel like you are importing the logic of ls-lint where you asked for flatcase to revive.

As I previously said to you, I think the things you need are already supported in revive with the following rules:

• filename_fornat
• exported

That's why I suggested you to use revive for your needs while you were trying to rely in ls-lint only, and I suggested you to use snake_case for directory containing Go files.

That said this issue is not exactly about what you reported in your comment here.

This issue is about fixing a hypothetical bug I identified with the current detection that you already exist.

So it would avoid a small edge case on something that currently works perfectly.

For anyone interested, I keep referring to a discussion that happened on ls-lint project

• https://github.com/loeffel-io/ls-lint/issues/284