[1.10.2] [SOLVED] "In" as a suffix in given parameters?

[Differentiation]

Hey,

So when I code I find that certain given parameters and method parameters have the suffix "In" at the end. For instance, "worldIn," "playerIn," "xIn," "yIn..."

This might be a silly question, but does anyone know why they have these "Ins" at the end? And why do some parameters have that while others do not?

Thanks!

Edited November 9, 2017 by Differentiation

[larsgerrits]

The parameters that have "In" at the end, have been named so by users who added them to the MCP mappings. It's just the code style they use. You can change them to anything you like if you want.

[Differentiation]

1 hour ago, larsgerrits said:

The parameters that have "In" at the end, have been named so by users who added them to the MCP mappings. It's just the code style they use. You can change them to anything you like if you want.

Ohhh

Thanks!

I adopted their style I guess, until today I asked myself: Why am I even writing that extra "In?"

[jabelar]

A parameter name is very limited in scope so doesn't matter too much as long as its meaning is understandable. Like if you're passing an integer that represents a color it is better to call that parameter an "int color" rather than "intIn".

 

Now an important thing is that in many situations, especially "setter" methods and constructors, the parameters are usually copied to fields that have similar meaning. So there are two coding styles for that. One is to name them the same but use the "this." reference to indicate the field. For example:

public void setColor(int color)
{
     this.color = color;
}

 

The other style is to always name the parameters something slightly different (but consistent) to identify it as the parameter. I personally tend to use a prefix "par" for parameters so I would have:

public void setColor(int parColor)
{
     color = parColor;
}

 

Many people who have contributed to MCP mappings and also to Forge like to do a similar thing but instead use a suffix "In" as you noticed. So it would be:

public void setColor(int colorIn)
{
     color = colorIn;
}

 

All three styles are fine, they are just a matter of personal preference. The main thing is that in each case they are readable, and they also prevent mistakes by making it harder to mix up the parameter with the class field.

Edited November 9, 2017 by jabelar

[Draco18s]

That only makes me think of How to Write Unmaintainable Code

Quote

Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table's primary key.

 

[LexManos]

Its decompiled code, seriously. Naming isn't perfect. However this is a community standard because of how the code is decompiled.

Local variables can get the name of classes. 'World world = null;' And ints can get i, j, k, etc.. See here for more information.

So to prevent parameters from colliding with Fernflower's local variable names people don't use class names directly.

[Differentiation]

6 hours ago, jabelar said:

A parameter name is very limited in scope so doesn't matter too much as long as its meaning is understandable. Like if you're passing an integer that represents a color it is better to call that parameter an "int color" rather than "intIn".

 

Now an important thing is that in many situations, especially "setter" methods and constructors, the parameters are usually copied to fields that have similar meaning. So there are two coding styles for that. One is to name them the same but use the "this." reference to indicate the field. For example:

public void setColor(int color)
{
     this.color = color;
}

 

The other style is to always name the parameters something slightly different (but consistent) to identify it as the parameter. I personally tend to use a prefix "par" for parameters so I would have:

public void setColor(int parColor)
{
     color = parColor;
}

 

Many people who have contributed to MCP mappings and also to Forge like to do a similar thing but instead use a suffix "In" as you noticed. So it would be:

public void setColor(int colorIn)
{
     color = colorIn;
}

 

All three styles are fine, they are just a matter of personal preference. The main thing is that in each case they are readable, and they also prevent mistakes by making it harder to mix up the parameter with the class field.

 

3 hours ago, LexManos said:

Its decompiled code, seriously. Naming isn't perfect. However this is a community standard because of how the code is decompiled.

Local variables can get the name of classes. 'World world = null;' And ints can get i, j, k, etc.. See here for more information.

So to prevent parameters from colliding with Fernflower's local variable names people don't use class names directly.

Ahh, I understand!

It's basically for no-confusion purposes.

Thanks guys!

[Draco18s]

6 hours ago, LexManos said:

Its decompiled code, seriously. Naming isn't perfect. However this is a community standard because of how the code is decompiled.

Local variables can get the name of classes. 'World world = null;' And ints can get i, j, k, etc.. See here for more information.

So to prevent parameters from colliding with Fernflower's local variable names people don't use class names directly.

Oh I get why it's done, Lex. Minecraft has its limitations because of the decompile and deobf process.

All I meant was that I, as a coder, wouldn't have chosen those names for my own functions.

[LexManos]

7 hours ago, Draco18s said:

Oh I get why it's done, Lex. Minecraft has its limitations because of the decompile and deobf process.

All I meant was that I, as a coder, wouldn't have chosen those names for my own functions.

Well you shouldn't. Anyone who takes code style from decompiled code is batshit insane... Write clean code. Decompiled code is NOT clean code.

[Draco18s]

40 minutes ago, LexManos said:

Well you shouldn't. Anyone who takes code style from decompiled code is batshit insane... Write clean code. Decompiled code is NOT clean code.

Well, obviously...