NameCaseConvention.LOWER_CAMEL should handle mixed case more properly

[koppor]

Actual:

-      PdfDocumentViewModel PDFviewModel = new PdfDocumentViewModel(mockPDF);
+      PdfDocumentViewModel pDFviewModel = new PdfDocumentViewModel(mockPDF);

Expected

-      PdfDocumentViewModel PDFviewModel = new PdfDocumentViewModel(mockPDF);
+      PdfDocumentViewModel pdfViewModel = new PdfDocumentViewModel(mockPdf);

Update mockPdf instead of mockPDF.

(This was originally reported at https://github.com/openrewrite/rewrite-static-analysis/issues/12#issuecomment-1588208014)

[seonWKim]

What would you expect if the variable name was PDFViewModel? (v to uppercase V). Will the result of the variable name changed into pdfvIewModel?

-      PdfDocumentViewModel PDFViewModel = new PdfDocumentViewModel(mockPDF);
+      PdfDocumentViewModel pdfvIewModel = new PdfDocumentViewModel(mockPDF);

[koppor]

I expect PdfViewModel. The assumption is that the programmers uppercase the abbreviations and then continue with an upper case letter for the next word. E.g., XMLParser -> XmlParser, ISOStandard -> IsoStandard, TOSCAAnalyzer -> ToscaAnalyzer.

Maybe, you can configure the behavior? I there could also be code which reads ISOstandard, TOSCAanalyzer, ..

[koppor]

Update I see that my assumption writing the comment. OMG. Maybe, the recipe should have some build-in abbrevations (PDF, ISO, XML, JSON) and offer a configuration of the known abbrevations?

[seonWKim]

@koppor, wouldn't checking for built-in abbreviations be expensive? rewrite would have to check all variables to see if they contain any built-in abbreviations.

What are your thoughts on allowing users to define their own built-in abbreviations? This approach offers the following advantages:

• We don't need to specify abbreviations in the code and can track users' preferences.
• If there are no abbreviations to check, there won't be any additional cost.

[koppor]

While I don't think, it's a performance issue (*), I agree that the list of terms is opinionated. Better nothing than something. (Even if I like knob-less software, which just works -- convention over configuration).

(*) First, the rule needs to be activated by three consecutive capital letters. Then, the variable name needs to be split to groups of capital letters belonging together (because these need to be changed). NOW, the lookup is done. If nothing found, the "normal" rewrite is done. IMHO a lookup of a String in a HashSet of 5 Strings is very fast.

Side note: There is the cost of checking the existence of user-provided terms (mappings?)

[seonWKim]

Side note: There is the cost of checking the existence of user-provided terms (mappings?)

The cost that I've mentioned earlier was for example, if rewrite have built in abbreviations such as PDF, ISO, XML, JSON, there will be additional cost of checking every variable names whether they include those built in abbreviations. But I think, we can minimize this cost by adding the rule(First, the rule needs to be activated by three consecutive capital letters) you provided.

First, the rule needs to be activated by three consecutive capital letters

So in order for the rule to be activated, at least 3 consecutive letters has to be capital letters?

• PDF, ISO, XML, JSON -> activated
• 2 letters(capitalized) -> not actiaved

[koppor]

Yeah, my gut feeling says so. Looking forward!