Documentation for p_ variables ?

[Dylem]

Hello,

I was wondering if there was a documentation for all these p_(inert number here) variable ?

 

For example, a function from GenLayer :

    /**
     * returns the most frequently occurring number of the set, or a random number from those provided
     */
    protected int selectModeOrRandom(int p_151617_1_, int p_151617_2_, int p_151617_3_, int p_151617_4_)
    {
        if (p_151617_2_ == p_151617_3_ && p_151617_3_ == p_151617_4_)
        {
            return p_151617_2_;
        }
        else if (p_151617_1_ == p_151617_2_ && p_151617_1_ == p_151617_3_)
        {
            return p_151617_1_;
        }
        else if (p_151617_1_ == p_151617_2_ && p_151617_1_ == p_151617_4_)
        {
            return p_151617_1_;
        }
        else if (p_151617_1_ == p_151617_3_ && p_151617_1_ == p_151617_4_)
        {
            return p_151617_1_;
        }
        else if (p_151617_1_ == p_151617_2_ && p_151617_3_ != p_151617_4_)
        {
            return p_151617_1_;
        }
        else if (p_151617_1_ == p_151617_3_ && p_151617_2_ != p_151617_4_)
        {
            return p_151617_1_;
        }
        else if (p_151617_1_ == p_151617_4_ && p_151617_2_ != p_151617_3_)
        {
            return p_151617_1_;
        }
        else if (p_151617_2_ == p_151617_3_ && p_151617_1_ != p_151617_4_)
        {
            return p_151617_2_;
        }
        else if (p_151617_2_ == p_151617_4_ && p_151617_1_ != p_151617_3_)
        {
            return p_151617_2_;
        }
        else
        {
            return p_151617_3_ == p_151617_4_ && p_151617_1_ != p_151617_2_ ? p_151617_3_ : this.selectRandom(p_151617_1_, p_151617_2_, p_151617_3_, p_151617_4_);
        }
    }

 

This function is pretty easy to understand as it is commented, but some aren't and sometimes waste me a lot of time for nothing.

Is there really an interest in giving random-looking names to variables ? Is there a documentation about how they name their variables ?

 

[cad97]

ob·fus·ca·tion

ˌäbfəˈskāSH(ə)n/

noun

noun: obfuscation; plural noun: obfuscations

1. the action of making something obscure, unclear, or unintelligible.

   "when confronted with sharp questions they resort to obfuscation"

 

The Minecraft source is obfuscated. That's where the unreadable parameter names come from (effectively).

 

MCP is the community's mapping of these machine-generated names back into human-readable forms.

 

You can try updating your mappings, and if that doesn't give names to the code (potentially breaking references -- be careful), you could consider contributing mappings yourself.

 

But for the most part, trivial methods and newer methods have fewer/worse names because people haven't bothered to give them names again, because their effort was better spent on one of many other useful tasks.

Edited July 7, 2017 by cad97
possesive

[Dylem]

Thanks, I understand now.

[Draco18s]

Technically there are 4 different names:

 

The original source (only Mojang has this)

The obfuscated names, aka Notch names (these are generated by the compile process and look like aa.bbcfa, you would see these if you opened the vanilla jar in JD-GUI, these will be arbitrary as source code changes)

The SRG names (these are the ones you're seeing, generated by the decompile process with names like p_12345_c and func_765432_f and are generally stable as the source code changes and new versions are released)

The MCP names (these are community supplied via MCPbot, mapped to SRG names)