Static final fields should be renamed to CONSTANT_CASE

[tterrag1098]

This includes most registries, which are currently in camelCase, like Item.itemRegistry, Block.blockRegistry, etc. MCPBot requires a forced override to name fields like this, so why keep it around if it breaks the rules?

[Darkhax]

I agree, now is the perfect time to update these. We should compile a list of all registry fields so we can be sure not to miss anything.

[kashike]

I'm +1 for CONSTANT_CASE. The existing registries/etc are a mixture of snake_case, camelCase and CONSTANT_CASE - it would be nice to switch to CONSTANT_CASE for everything, especially since that's what MCPBot tells you to use.

[liach]

Only for primitives and Strings. Other types may be mutable.

[tterrag1098]

Nope http://docs.oracle.com/javase/specs/jls/se6/html/names.html#9367

[Darkhax]

Here is a list of the once I have found. This should be all of them, or at least the name spaced ones. Current clases are Block, PotionType, Potion, Enchantment, BiomeGenBase, SoundEvent and Item.

!sf field_149771_c BLOCK_REGISTRY
!sf field_185176_a POTION_TYPE_REGISTRY
!sf field_188414_b POTION_REGISTRY
!sf field_185264_b ENCHANTMENT_REGISTRY
!sf field_185377_q BIOME_REGISTRY
!sf field_187505_a SOUND_REGISTRY
!sf field_150901_e ITEM_REGISTRY

[LexManos]

What about the Init classes that hold the static things. In theory they should be CONSTANT_CASE no? Just somethign to think about.
We need to have someone go an name those correctly as those will be central to a lot of MC stuff and we dont want the community fighting over names.

[octylFractal]

If we want to use an established standard, Google suggests using ALL_CAPS only when the field is truly constant, not like the registries which may change over time. I would vote for ALL_CAPS or ALL_CAPS and camelCase, where applicable.

[matthewprenger]

All of the MC registries and their current mapped names:

net/minecraft/client/renderer/block/model/ModelBakery.field_177605_n => bakedRegistry
net/minecraft/client/resources/data/IMetadataSerializer.field_110508_a => metadataSectionSerializerRegistry
net/minecraft/item/Item.field_185051_m => properties
net/minecraft/client/audio/SoundHandler.field_147697_e => soundRegistry
net/minecraft/block/Block.field_149771_c => blockRegistry
net/minecraft/potion/PotionType.field_185176_a => potionTypeRegistry
net/minecraft/enchantment/Enchantment.field_185264_b => enchantmentRegistry
net/minecraft/item/Item.field_150901_e => itemRegistry
net/minecraft/potion/Potion.field_188414_b => potionRegistry
net/minecraft/util/SoundEvent.field_187505_a => soundEventRegistry
net/minecraft/world/biome/BiomeGenBase.field_185377_q => biomeRegistry
net/minecraft/block/BlockDispenser.field_149943_a => dispenseBehaviorRegistry

I definitely think we need to figure out a standard for all of these. I'm partial to REGISTRY myself.

[SoniEx2]

+1 for CONSTANT_CASE. Including for block/item fields, which should be their in-game names/IDs in uppercase.

[Darkhax]

To comment on some of the recent changes, I still feel that CONSTANT_CASE should be used for all of the registries, or at least the namespaced ones. As for Soni's comment, I agree that all item and block fields should be updated to resemble their name ID, however I am not sure if they should be camelCase or not. In that situation I would be okay either way.

[grondag]

Would like to see all final static fields in CONSTANT_CASE, including registries or other instances that may have mutable content. For me, it serves to remind that I am working with what is essentially a singleton instance, which in turn has other implications for state and concurrency.