papermc/codebook

Library for handling jar remaping logic for PaperMC

codebook's Issues

Registry-related get methods

A lot of the methods on Registry, HolderGetter, HolderLookup, RegistryAccess take ResourceKey as the sole parameter returning something. A lot of the time, those ResourceKey arguments are obtained from static final fields somewhere which makes choosing the name for the local var very easy.

Something like

Holder<Structure> structure1 = registry.getHolder(BuiltinStructures.NETHER_FOSSIL);

can be changed to

Holder<Structure> netherForsilStructure = registry.getHolder(BuiltinStructures.NETHER_FOSSIL);

This is similar to #10 and how the various is and has methods are handled, by looking at the field used in the parameter.

A non-exhaustive list of methods that this could apply to are:

TagKey

• TagKey#create(ResourceKey, ResourceLocation)

ResourceKey

• ResourceKey#create(ResourceKey, ResourceLocation)

Registry

• Registry#get(ResourceKey)
• Registry#getHolder(ResourceKey)
• Registry#getOptional(ResourceKey)
• Registry#getOrThrow(ResourceKey)
• Registry#containsKey(ResourceKey)
• Registry#getHolder(ResourceKey)
• Registry#getTag(TagKey)
• Registry#getTagOrEmpty(TagKey)
• Registry#getOrCreateTag(TagKey)

RegistryAccess, RegistryAccess$Frozen, HolderLookup$Provider

• RegistryAccess#lookup(ResourceKey)
• RegistryAccess#lookupOrThrow(ResourceKey)
• RegistryAccess#registry(ResourceKey)
• RegistryAccess#registryOrThrow(ResourceKey)

HolderGetter, HolderLookup

• HolderGetter#get(ResourceKey)
• HolderGetter#getOrThrow(ResourceKey)
• HolderGetter#get(TagKey)
• HolderGetter#getOrThrow(TagKey)

BootstapContext

(yes there is a typo in Bootstap in the vanilla source)

• Bootstap#register(ResourceKey, Object, Lifecycle)
• Bootstap#register(ResourceKey, Object)
• Bootstap#lookup(ResourceKey)

Improve the "as" local name suggester

There are a lot of getAs methods, like on nbt, or gson-related things. These should be filtered out, and the remaining text should be checked against java keywords so we don't end up with _long and _int2 vars which currently exist.

Github Releases jars are broken

The codebook jars attached in the GitHub releases are missing their manifest's (they don't run). Cloning the project and using Intellij to build it works fine.

Output various reports

There are several useful reports that could be generated from a run of codebook.

Tasks

Beta Give feedback

1. Missing parameter mappings
2. All locals assigned from methods that don't have a suggester match
3. All locals assigned from fields that don't have a suggester match
4. Any mapped param that is renamed due to a conflict

ItemStack constructors

An ItemStack constructor that uses one of the static fields in Items.java should have its local var name be associated with that item name. So something like

ItemStack itemStack = new ItemStack(Items.ENCHANTED_BOOK);

should be

ItemStack enchantedBookStack = new ItemStack(Items.ENCHANTED_BOOK);

Inherit parameter names in lambda expressions from the interface

Currently, if the mappings are completed for an interface and that interface is used to create a lambda, the parameters of that lambda do not inherit the names from the interface.

Some examples in the source, in ExecuteCommand, the field CALLBACK_CHAINER's inner lambda does not have the correct parameter mappings which are set for ResultConsumer. Also in FillBiomeCommand#makeResolver, the returned lambda for BiomeResolver does not inherit parameter names from the interface.

Methods on collections that return booleans

Various collection types have methods that return booleans based on some condition, like if the element was successfully added or removed. The boolean local var names can be added or removed or something similar.

Enum ordinals

The integer returned by Enum#ordinal should not just use the i# format, but should be something associated with the type of the enum, like for Direction, it could be directionOrdinal.

All in the name of reducing the number of primitive local variables that have numbers after them.

nbt 'get' methods

Various methods on CompoundTag return a type based on a key input which is a string. Very commonly, that string is a constant which is easy to lookup when choosing a name for the local var. The local var should be named based on that string, completely ignoring the expected type.