Local variable name generation ideas

[natanfudge]

• [ ] Give types that implement Collection a plural name (In addition to arrays)
• [ ] Name boolean variables flag, flag2, etc instead of bl, I think that's more readable.
• [ ] For primitive arrays, use ints, and floats, instead of is and fs, etc

Feel free to add more or tick checkboxes.

[2xsaiko]

Map<K, V> → kToV / kToVMap

[Pyrofab]

Iterator → it maybe

[natanfudge]

Iterator → it maybe

That just seems less readable than iterator?

[2xsaiko]

I'd go for iter. Everyone seems to use that, and it's readable.

[Runemoro]

If a variable contains the result of a method named getXyz, it should be named xyz.

[2xsaiko]

ItemPlacementContext, ItemUsageContext, *Context → ctx BlockPos → pos BlockState → state PlayerEntity → player Direction → dir BlockView → view

[Pyrofab]

Building upon the PlayerEntity suggestion, (.*)Entity -> $1

[liach]

We should just allow the remapper to accept a local variable name suggestor

[natanfudge]

ItemPlacementContext, ItemUsageContext, *Context → ctx BlockPos → pos BlockState → state PlayerEntity → player Direction → dir BlockView → view

• I think context is fine
• yes
• yes
• no, dir is directory
• yes

[modmuss50]

I think expanding the auto name generator to include these in a yarn dist is the best way to go about this?

[natanfudge]

Gonna need lv remapping first

[modmuss50]

Ah yeah, didnt read the local bit. Could still do it for params possibly? might not be needed tho

[sfPlayer1]

Tiny remapper's name generation should remain independent of MC, so hardcoding rules for its typical classes is out - only important Java ones may receive some. The same applies to anything that can't be inferred without simple analysis, i.e. needing more than the descriptor+signature of the variable to be named.

You can still keep submitting ideas that are more extensive, we can implement more comprehensive schemes elsewhere in the tooling.

[2xsaiko]

* I think `context` is fine

I mean sure it's fine, but you want that name to not get in the way since most if not all of these are a container for other values whose names are the actually important part you want to look at when you're reading the code.

* no, `dir` is directory

Wouldn't be the first time an abbreviation could mean two different things based on context. And in most cases you're not going to be handling any directories in the same places as handling Directions so they won't conflict.

String → s (not sure if this already happens) StringBuilder → sb ? extends Exception → e

[Runemoro]

Tiny remapper's name generation should remain independent of MC, so hardcoding rules for its typical classes is out

Can't the tiny format be extended to include a "default variable name" property for class mappings?

[natanfudge]

Why is there a need for a default variable name? Whoever creates the mappings file can:

• Put the name if it was inputted by a human
• Otherwise, if this name is special (like *context), put the desired name (context in this case)
• Otherwise, leave empty and let tiny-remapper handle it.

[natanfudge]

String → s (not sure if this already happens) StringBuilder → sb ? extends Exception → e

I'm really against such short names in general...

[Runemoro]

@natanfudge I'm not sure what you're saying... therealfarfetchd suggested rules for automatically generating simpler names for certain classes, like BlockPos -> pos, and Player replied that they can't be hardcoded into tiny-remapper. I then suggested that they can be part of the mapping files.

[natanfudge]

I think what you suggested, is to extend the tiny format, with new syntax. I replied that what Player wants is achievable using the existing format.

[Runemoro]

is achievable using the existing format.

It isn't. With the existing format, we can only map things individually. Here we want a rule for all BlockPos variables to be named pos (plus a number when there's more than one).

Unless you're suggesting moving the name generation to when yarn is built, but in that case this issue should be for yarn, and the logic should be implemented in either stitch or Enigma.

[natanfudge]

Is weave still alive?

[Runemoro]

No, weave has been merged into Enigma and is no longer necessary.

[natanfudge]

The original idea of this issue was about generic things (See the opening comment), I agree that minecraft-specific stuff can be moved to yarn.

[Runemoro]

It doesn't make sense to have variable name generation both in yarn and tiny-remapper...

[natanfudge]

Well, variable name generation is already partially implemented in tiny-remapper.

[Runemoro]

And it can be kept there. But we'll need a way to provide the custom rules to tiny-remapper (for example, by specifying the rules in the tiny files).

[sfPlayer1]

I like the idea of adding the default variable name, not sure how it'd interact with enigma / manual mapping authoring though. Some external tool with the knowledge+analysis capabilities of e.g. matcher would still have to handle complex cases like inferring names from getter returns etc - that would apply to field names as well.

[RedstoneParadox]

Gonna plus one not renaming int arrays to is as that would surely cause issue in Kotlin where is is a keyword.

[natanfudge]

This is about parameters/variables, which you can't interact with from a Kotlin mod.

[Runemoro]

Suggestions for short names:

• String -> s
• Object -> o
• Character, char, result of String.codePointAt -> c
• Byte, byte -> b
• Integer, int, Short, short, Long, long -> i, j, k, n, m, ii, jj, ...
• Float, float, Double, double -> a, b, c