camelCase identifier policy

[czaerlag]

As for now, TBeautifyCodeOptions.IdentifierPolicy is useless. No sane programmer would use anything but wpNone for identifiers, would he/she?
Well, I love Pascal, but I love camelCase as well, and I say it looks unexpectedly great for Pascal source code! So, I propose a change to components/codetools/sourcechanger.pas

Code: Pascal  [Select][+][-]

1. ...
2. type tWordPolicy = (wpNone, wpLowerCase, wpUpperCase, wpLowerCaseFirstLetterUp, wpCamelCase);
3. ...
4. function tBeautifyCodeOptions.beautifyWord(const aWord: string;
5.   wordPolicy: tWordPolicy): string;
6. ...
7. begin
8.   ...
9.   case wordPolicy of
10.   ...
11.     wpCamelCase: result:=lowerCase(copy(aWord,1,1))+copy(aWord,2,length(aWord)-1);
12.   ...
13. end;
14.  

Isn't it pretty?
It works well for me -- I've rebuilt the IDE. And I guess, it might become popular.

[Martin_fr]

I do consider myself sane, despite my constant exposure to lets call it "the fantastic world of ideas that this forum is".

All my class names start with an uppercase "T", e.g. "TFooBar".

The only first letter lowercase that I use is for enums (and then its usually 2 or 3 starting lowercase).

[Xenno]

As for now, TBeautifyCodeOptions.IdentifierPolicy is useless. No sane programmer would use anything but wpNone for identifiers, would he/she?

I am sane.
Using camelCase in Object Pascal goes completely against the language's established style guides and history. There’s a reason it's called PascalCase—do search.

Isn't it pretty?
It works well for me -- I've rebuilt the IDE. And I guess, it might become popular.

No.
Of course, you can ultimately apply or type any way you want since the language itself is case-insensitive but keep it for your own amusement. Sticking to native conventions keeps codebases clean and readable.

[czaerlag]

All my class names start with an uppercase "T", e.g. "TFooBar".

Yes, that means your WordPolicy is wpNone, as mentioned above.
What are the other options for? Would anyone force all identifiers to look like TFOOBAR, or tfoobar, or Tfoobar?
Maybe, the property should be just deleted, for it's completely useless?

[czaerlag]

Of course, you can ultimately apply or type any way you want since the language itself is case-insensitive but keep it for your own amusement. Sticking to native conventions keeps codebases clean and readable.

Of course, I will
Just tell me please, what is this groupbox (IDE Options/CodeTools/Words) all about? Looks like it has nothing to do with sticking to native conventions...

[Xenno]

Just tell me please, what is this groupbox (IDE Options/CodeTools/Words) all about? Looks like it has nothing to do with sticking to native conventions...

Please, look at that image. The group box titles: Indentifier policy
It will convert MyVar to: MyVar or myvar or MYVAR or Myvar.
Not tWordPolicy, tBeautifyCodeOptions.beautifyWord

[czaerlag]

It will convert MyVar to: MyVar or myvar or MYVAR or Myvar.
Not tWordPolicy, tBeautifyCodeOptions.beautifyWord

So, my question is: does a sane programmer want all his variable names to be converted this way?

By the way, class names, and type names, and routine names are identifiers as well. And, yes, it WILL convert ALL identifiers according to the policy selected.
You can try it yourself. Just select a policy and create a new form.

[Martin_fr]

All my class names start with an uppercase "T", e.g. "TFooBar".

Yes, that means your WordPolicy is wpNone, as mentioned above.
What are the other options for? Would anyone force all identifiers to look like TFOOBAR, or tfoobar, or Tfoobar?
Maybe, the property should be just deleted, for it's completely useless?

Ok, I shouldn't have just given the example of the type name only, because the single letter prefix makes it look different (though to me the "T" is just "one word of its own" and the its the same as any other)

But I also have vars and functions like

Code: Pascal  [Select][+][-]

1. procedure AppendText();
2. var MyText;
3. var Text; // even single word
4.  

Any identifier has each word (Including the first word) have its first letter uppercased.

To me keeping the first letter of the combined word in lowercase look really strange.

According to https://en.wikipedia.org/wiki/Camel_case both (yours and mine) are variants of CamelCase. Having the first letter of the first word uppercase is "UpperCamelCase" (aliased PascalCase) while yours is lowerCamelCase.

=> so in a Pascal environment, it is ok and even expected that wpCamelCase should resolve to the UpperCamelCase variant.

--------
That said, I don't mind if an extra variant is added. But by a new name, not replacing any existing.

[czaerlag]

both (yours and mine) are variants of CamelCase.

Great! But none of these variants is implemented as for now. Three completely usless options are implemented instead.
OK, let's have both.
1. Capitalize the first letter, and leave the rest of the word intact.
2. Lowercase the first letter, and leave the rest of the word intact.
That would at least make some sense.

[Martin_fr]

both (yours and mine) are variants of CamelCase.

Great! But none of these variants is implemented as for now. Three completely usless options are implemented instead.

Well, automatic CamelCase (if the origin wourd is in a different casing) would require the IDE to know the words from which an identifier is build. Including sometimes partial words CalcCnt, FindAbbrev. Even with a dictionary that would not always be possible, and otherwise could be a very expensive search.

OK, let's have both.
1. Capitalize the first letter, and leave the rest of the word intact.
2. Lowercase the first letter, and leave the rest of the word intact.
That would at least make some sense.

Probably, best to create an issue on the bug tracker.

Btw, did you see somewhere some doc which completions are (or should be) affected? I couldn't find that.

shift-ctrl-C => affected
Ctrl-Space => Does not seem to care anyway

[czaerlag]

Well, automatic CamelCase (if the origin wourd is in a different casing) would require the IDE to know the words from which an identifier is build.

Yes, this doesn't seem possible. The IDE cannot know what's on the programmer's mind. Maybe, an LLM of some sort could help, but I'd rather doubt it's worth of it
What is definitely easy -- just to take a word as it was initially spelled and only modify the first letter. This is sufficient for the vast majority of cases.

Btw, did you see somewhere some doc which completions are (or should be) affected? I couldn't find that.

Too bad, I also couldn't. The code is sparsely commented, so I had to use solely the RTFS and Try-And-Err methods.
As I can guess, the Beautifier is involved in code generation (when a unit is initially created, event handlers assigned, or Shift+Ctrl+C pressed), but Ctrl+Space is handled by SynEdit itself, so it does not work in this case.
Would be nice if Ctrl+Space worked as well. Would be even better, if there were a main menu action to apply the policies to existing code.

Probably, best to create an issue on the bug tracker.

Thank you. I'll do.

The question that remains unclear, in case of PascalCamelCase, is how to preserve lowercase enum name prefixes. It's gonna become actual if the Beautifier is involved in Ctrl+Space code completion.

[Martin_fr]

Would be even better, if there were a main menu action to apply the policies to existing code.

I don't use it myself, but isn't that what Jedi code formatter is about?

Not sure if it is pre-installed, but its afaik shipped with the installer.

And then yes, you have several sets of options for one and the same thing, unfortunately.

[Renat.Su]

I've been using camelCase for a long time for local variables, parameters, and class fields. I don't do that for types. I think it's too innovative)

Examples:

Code: Pascal  [Select][+][-]

1.   { TInvoiceItem }
2.   TInvoiceItem = class(TCollectionItem)
3.   private
4.     fName: string;
5.     fPrice: Currency;
6.     fQuantity: Double;
7.     fUnitName: string;
8.   public
9.     function Amount: Currency;
10.     property Name: string read fName write fName;
11.     property Quantity: Double read fQuantity write fQuantity;
12.     property UnitName: string read fUnitName write fUnitName;
13.     property Price: Currency read fPrice write fPrice;
14.   end;
15.  
16. ...
17.  
18.     procedure AddItem(const aName: string; aQuantity: Double;
19.                       const aUnitName: string; aPrice: Currency);    
20.  

[creaothceann]

I've always been using PascalCase. Recently even for types (instead of TPascalCase); makes sense especially for singletons (classes / advanced records that appear only once in the program and use static class variables and class subroutines).

_PascalCase for private fields; f or m prefixes would still make the fields appear regularly in the identifier completion box.

PascalCase_ for subroutine parameters that would otherwise hide class/record fields.

Lowercase for local single-character identifiers.

[Thaddy]

I believe it is not Pascal case, but "Borland case" and I actually love it, because it adds readability. But since a "few" years I just make sure most of my projects and units are saved in all lowercase. Then again, the compiler code uses a different convention which is actually equally readable. And I often sin against my own rules, the handicap of a compiler and language that is case agnostic. It is so bad that I always have to reset my mindset if I have been programming in C++ all night. (happens...) That even shows when people read my code...Code good, casing inconsistent...
But the imaginary Frank Borland did a good job introducing it.

https://www.trueagency.com/borland-frank-is-back  The nestors among us may like that link....

(Oh them days at 100 Borland Drive, the Borland campus)

Abbreviated by CoPilot, otherwise I would have posted too much text:

Short historical note: why camelCase has Borland roots
BorlandCase, as I would call it,  in Pascal didn’t originate in academia, well, it did, in a company that overflowed with academic talent but not in an academic sense:
BorlandCase in Pascal code didn’t appear out of nowhere. It traces back to Borland’s developer culture, especially during the Turbo Pascal and Delphi era. Borland wasn’t just a compiler company — it was a place filled with unusually talented engineers who shaped conventions that spread far beyond their own tools.

In the late Borland years, when the company struggled because of mismanagement and lack of focus on the development tools division, many employees even financed a management buyout - CodeGear - with their own savings to keep the developer tools alive. Some lost money doing so, but they did it because they believed in the work, the tools, and the community. That same culture — practical, developer‑first, and deeply personal — is where many of the naming and coding conventions we still use today were formed. Including TXxxx , and including C# convention.

So BorlandCase in Pascal isn’t arbitrary. It’s part of a lineage that started in a vibrant engineering environment where people cared enough about the craft to literally invest themselves in it.

I know, I was there for six weeks, just before Delphi was released. Some of those engineers are still good friends.

I hope you still notice the romantic note in the summary. That is really how I see it, but it is also fact.

It emerged organically inside the Delphi team, shaped by Anders, reinforced by Teixeira, Thorpe, Jazdzewski, Bauer, and the VCL culture. And they were relentless in maintaining it.