var-naming: Unicode letter are not allowed

[ccoVeille]

While using English is common for coding, Go allows to use any Unicode letter, and not only the Latin letter from A to Z (no matter if they are lowercase or uppercase)

click to read the Go specification

 Identifiers name program entities such as variables and types. An identifier is a sequence of one or more letters and digits. The first character in an identifier must be a letter.

identifier = letter { letter | unicode_digit } .

a
_x9
ThisVariableIsExported
αβ

Source: https://go.dev/ref/spec#Identifiers

With letter being defined like this.

Letters and digits¶

The underscore character _ (U+005F) is considered a lowercase letter.

letter        = unicode_letter | "_" .
decimal_digit = "0" … "9" .
binary_digit  = "0" | "1" .
octal_digit   = "0" … "7" .
hex_digit     = "0" … "9" | "A" … "F" |

https://go.dev/ref/spec#Letters_and_digits

 The following terms are used to denote specific Unicode character categories:

newline        = /* the Unicode code point U+000A */ .
unicode_char   = /* an arbitrary Unicode code point except newline */ .
unicode_letter = /* a Unicode code point categorized as "Letter" */ .
unicode_digit  = /* a Unicode code point categorized as "Number, decimal digit" */ .

In The Unicode Standard 8.0, Section 4.5 "General Category" defines a set of character categories. Go treats all characters in any of the Letter categories Lu, Ll, Lt, Lm, or Lo as Unicode letters, and those in the Number category Nd as Unicode digits. 

https://go.dev/ref/spec#Characters

[ccoVeille]

I thought about it when seeing the restrictive regexp I found when reporting #1313

• Remove regex from code when possible #1313

While I checked recently the Go spec when checked things for ls-lint project

• support flatcasing for golang loeffel-io/ls-lint#284

And I found out package names (and so folder) could use

And what I found was about identifiers, and not only the package names

[alexandear]

While it's true that Go allows any Unicode letter for identifiers, using non-ASCII characters in variable names is generally not considered a best practice—especially in collaborative or open-source codebases. It can negatively impact readability, tooling support, and team collaboration across different locales.

revive is a linter, not a compiler, and as such, its purpose is to enforce code quality and maintainability through opinionated rules. Our choice to flag non-ASCII identifiers aligns with that goal, promoting consistency and accessibility in codebases.

We believe that enforcing ASCII-only variable names is a reasonable and practical constraint that benefits the broader developer community.

[ccoVeille]

I'm fine with this statement.

So it would be a matter of documentation then. We may report different error messages then.

But then, #1322 will have to be updated because it now uses unicode.IsUpper that will work for Greek, Cyrillic ... and even Latin language such as French.

• var-naming: remove regex from code #1322

[ccoVeille]

Now changes were rolled back in the other PR.

Let's go back to this issue.

What do you think about reporting variables, constants that contains "non ASCII Unicode letter"

[ccoVeille]

Also, we could consider the fact to allow non ASCII Unicode letters could be configured via a setting of var-naming rule.

cc @denisvmedia

[chavacava]

The rule banned-characters could be extended to check for non Latin characters in id's.

[ccoVeille]

The rule banned-characters could be extended to check for non Latin characters in id's.

I thought about it a few days ago.

Here is why I didn't talk about it.

Right now (even with #1322) :

• var-naming rule would report "non-ASCII Unicode letter and digit".
• banned-characters is not enabled by default
• banned-characters is indeed a better linter to report [^A-Za-z0-9_]+ character.
• banned-characters has currently a variable to provide the list of character to ban.

All these needs to be considered

[ccoVeille]

One way is to say:

• rewrite var-naming to accept Unicode letter and digit. (I'm not even sure there is a need to do it)
• rewrite banned-characters to report non - ASCII Unicode letter and digit
• enable banned-characters by default

But this could be considered as a breaking change.

[ccoVeille]

Another way is to do something like this:

• rewrite var-naming to accept Unicode letter and digit. (I'm not even sure there is a need to do it)
• add a new rule, enabled by default, to report report non - ASCII Unicode letter and digit

The new rule could be use-ascii-only or use-ascii

[ccoVeille]

I found back this linter

https://github.com/tdakkota/asciicheck

Then I thought about this issue.

I'm unsure how it could affect the discussion (almost monolog 😅) we had here, because I'm no longer sure about the conclusion I had with this topic.

I might have to read it again