decompiler: less concise, but also more useful, variable naming scheme

[slippycheeze]

Is your feature request related to a problem? Please describe.
Looking at this code, it is hard to tell what the actual types being addressed are:

ItemReplicaInfo* pIVar3, pIVar12;
Item** ppIVar6, ppIVar8, ppIVar13, ppIVar15;
Item*  pIVar4;
Object* pOVar10;

pIVar3 = pVVar1.head;
lVar7 = (longlong)(((longlong)pVVar1.tail - (longlong)pVVar1.head) / 0x140);
ppIVar6 = ppIVar13;
ppIVar8 = local_70.field2_0x8;
pOVar10 = local_70.field1_0x0;
pIVar12 = pVVar1.tail;
ppIVar15 = ppIVar13;
if (lVar7 != 0) {
    do {
        pIVar4 = GAME::Item::CreateItem(pIVar3 + (longlong)ppIVar6);

The current naming scheme is fairly concise, which is nice for small functions, but doesn't scale well to larger functions. Those 8 variable names are identical for 80+ percent of their content; very low information to character ratio, IMO.

This is amplified because humans tend to cluster type names, so Item, ItemReplica, and ItemReplicaInfo are routinely used together. Ditto "database table" type classes that use multiple vector<T> members as "columns" and index by integer ID to work with a single row of data: pVVar{N} has radically different types for every N, but the code doesn't distinguish them at all.

Describe the solution you'd like
I'd like to be able to have the decompiler use a "verbose" naming scheme that was less information-lossy, at least once the function exceeded a certain size limit. (Personally, I'd be fine with very verbose names all the time, but I know others prefer different, and I do as well, contextually.)

Every programmer, and their dog, has a naming scheme to suggest, but I have two concrete suggestions for how to handle this "placeholder" naming problem following; examples of the code from above

just say it all: the naming pattern is DataType.getName() unmodified; maximally verbose,
but also preserves 100 percent of information about the type of the variable. annotation for pointer variables and append a number as presently.

// JUST SAY IT ALL
ItemReplicaInfo* pItemReplacaInfo3, pItemReplacaInfo12;
Item** ppItem6, ppItem8, ppItem13, ppItem15;
Item*  pItem4;
Object* pObject10;

pItemReplacaInfo3 = pVVar1.head;
longlong7 = (longlong)(((longlong)pVVar1.tail - (longlong)pVVar1.head) / 0x140);
ppItem = ppItem13;
ppItem8 = local_70.field2_0x8;
pObject10 = local_70.field1_0x0;
pItemReplacaInfo12 = pVVar1.tail;
ppItem15 = ppItem13;
if (lVar7 != 0) {
  do {
    pItem4 = GAME::Item::CreateItem(pItemReplacaInfo3 + (longlong)ppItem6);

long abbreviation style: the naming pattern is "extract the first letter of every 'word' in the name", such that we get: Item⇒I, ItemReplicaInfo⇒IRI, etc. This preserves more information, but also demands more "smart" to avoid traps:

ItemReplicaInfo    IRI
itemReplicaInfo    IRI
item_replica_info  IRI or iri  // case folded or not, either way works; if lowercase use `p_` and `pp_`
URL                URL
item_ReplicaInfo   IRI, or ...

ItemReplicaInfo* pIRIVar3, pIRIVar12;
Item** ppIVar6, ppIVar8, ppIVar13, ppIVar15;
Item*  pIVar4;
Object* pOVar10;

pIRIVar3 = pVVarVar1.head;
longlongVar7 = (longlong)(((longlong)pVVarVar1.tail - (longlong)pVVarVar1.head) / 0x140);
ppI = ppIVar13;
ppIVar8 = local_70.field2_0x8;
pOVar10 = local_70.field1_0x0;
pIRIVar12 = pVVarVar1.tail;
ppIVar15 = ppIVar13;
if (lVarVar7 != 0) {
  do {
    pIVar4 = GAME::Item::CreateItem(pIRIVar3 + (longlong)ppIVar6);

Describe alternatives you've considered
I could keep manually renaming these things, but really... ouch.

[slippycheeze]

Considering this after posting, one additional thing that'd be really nice: the decompiler should "uniqueify" variable prefixes: keep a table that says IVar is assigned to Item, and then do something if a second type (eg: Items) wants to use IVar. and make it unique somehow, so that collisions are avoided.

Also, if the concept of "longer abbreviations from heuristics" is acceptable, but y'all don't want to schedule the task of implementing it, please say so? I'd have a shot at building the feature, or at least as much of it as I could, if it would be accepted upstream. (well, either concept, or even a description of what you /would/ accept instead, I guess.)

obviously, subject to the code being acceptable to y'all, that sort of thing; I'm looking for "you would be wasting time writing the code, because it would be rejected on design grounds no matter how goood it was" to save myself pain. ;)

[Wall-AF]

It may be worth considering adding a field to the composite editors etc. to allow the user to enter a base name for an instance of that object (and capitalise the first letter and prepend a p to generate the name for any pointers to one).

[LukeSerne]

I really like the idea of making the way the decompiler generates variable names configurable. I think I'd prefer the automatic naming to be as "dumb" as possible, and instead use short and unique names, something like v0, v1, v2 ... for local variables and a0, a1 ... for parameters. Especially when looking at smaller functions with few things going on, it's not that hard to keep track of the purpose and function of different variables, and a default name like local_10 or uVar8 doesn't give much useful information. Additionally, the shorter variable names generated by this naming scheme can make lines shorter, preventing lines from wrapping, which is also easier to understand.

While on the topic of automatic variable naming, it would be cool if the decompiler could detect iterator variables in loops, and name them i, j or k automatically.

[Wall-AF]

I like the idea for loop variables using i, j, k.

[cdohara]

While on the topic of automatic variable naming, it would be cool if the decompiler could detect iterator variables in loops, and name them i, j or k automatically.

This is mathematically unscalable due to finite alphabet. For example, what do we do if there is a loop that is O(n^4)? Perhaps better could be {i1, i2, i3, ...}, or some variation of this.

However, I also do very much like the idea of a more nuanced variable naming scheme for the decompiler.