Prefixes vs suffixes in class naming

[asiekierka]

"BiomeDesert" vs "DesertBiome", etc. Or "ComponentTranslatable" vs "TranslatableComponent".

The former has advantages when sorting names in an editor and is my personal preference; the latter is more common in Java development and is preferred by most other people.

[kashike]

from private discussion with @asiekierka the other day:

22:34 <kasheek> I have a 'block' package with:
22:34 <kasheek> 'BedBlock'
22:34 <kasheek> 'CactusBlock'
22:34 <kasheek> 'MagmaBlock'
22:34 <kasheek> and I import them all into one of my classes. I can:
22:34 <kasheek> - look at the imports, in alphabetical order, without reading "Block" before each word
22:34 <kasheek> - search for ".BedBlock" and get results for BedBlock *and* BedBlockEntity *and* BedBlockEntityRenderer
22:34 <asie> that last one
22:34 <asie> that's a good argument

[maxpowa]

I would argue that search in most modern Java IDEs would be fuzzy enough that regardless of ordering of BlockBed/BedBlock the result would show.

[reoseah]

I think Mojang uses either suffixes (BedBlock) or just names (Bed).

[snip!]

Those classes are, probably, in same package and are named like:

ReedBlock
RenderType
RepeaterBlock
RotatedPillarBlock
Rotation
SandBlock

[reoseah]

Another example, which also shows Mojang names doesn't have I prefixes for interfaces:

[snip!]

[reoseah]

The former has advantages when sorting names in an editor

This is true if everything gets mapped into one large "sink" package (e.g. net.minecraft.src), but it is bad substitute for mapping packages correctly. And if classes are put in packages like blocks, items, entities, prefixes become redundant.

[asiekierka]

While your efforts are commendable, please do not post MCP content in here. Please use Enigma mappings or Tiny mappings from pomf to demonstrate your point next time, or hint at it without posting names directly.

The research is appreciated, however! We were already aware of Mojang not using I-prefixes thanks to Brigadier, but the other hint is pretty interesting. I was planning on looking at the alphabetical ordering myself at some point, however it also needs not be assumed that Minecraft's "internal names" are perfect or fitting for a more modded development environment.

[LemmaEOF]

I personally like having the prefixes, because that means all the items get grouped together, all the biomes get grouped together, etc. Of course, the counter-argument is that suffixes make everything that has something in common get grouped together, like IronIngot, IronSword, IronBlock, IronChestplate, etc.

[asiekierka]

@Boundarybreaker Actually, it's that they're in packages anyway. So, in .block, things are already grouped together. It doesn't matter if it's BlockBed and BlockChest or BedBlock and ChestBlock.

[LemmaEOF]

Ah, yeah. That is a good point. I was more thinking from mod-dev side. I'm fine with suffixes, then.

[darkevilmac]

Personally in all my code I use prefixes instead of suffixes on my class names. There's some exceptions to that rule for pretty much every situation that comes up I end up going for prefixes.

I find it works better when searching for a type of object in my IDE, and honestly just looks better to me.

A lot of this is opinion based and if you look at other mods source code on github it's pretty clear that most people are happy with class names using a prefix instead of a suffix.

[reoseah]

I think all mods use prefixing because they are using MCP names and MCP names mostly use prefixing because long time ago all minecraft was deobfuscated into single net.minecraft.src package. However, espacially in new code, features there's a lot of examples going with suffixes. E.g. ILightEngine, ChunkTask, SurfaceBuilder, IWorldCarver, IChunkGenSettings implementations, Config/Pieces/Structure classes for structures. Code for recipes and loot generations has many derived classes that don't include the name of the base class.

✓ CONSIDER ending the name of derived classes with the name of the base class.

This is very readable and explains the relationship clearly. Some examples of this in code are: ArgumentOutOfRangeException, which is a kind of Exception, and SerializableAttribute, which is a kind of Attribute. However, it is important to use reasonable judgment in applying this guideline; for example, the Button class is a kind of Control event, although Control doesn’t appear in its name.

From C# Design Guidelines

I think using prefixes kind-of locks you in that scheme and doesn't allow for any "judgment". But maybe it's not really needed for wide inheritance hierarchies, like that of Block or Item

[reoseah]

I've just thought, look at JEI implementations. There's no prefixing precedents in api and so all across the modding commmunity JEI-support classes are Machine+Category/Wrapper/etc.

[liach]

MCP did not have the suffix move because of large-scale dependencies from existing mods. This is not the case in fabric.

[asiekierka]

Yes. I'm already keen on doing it, it's just a decent amount of effort to sit down and do it.

[reoseah]

I've just thought: prefixes != backwards spelling, also they come in different flavors

Examples from MCP: [snip!]

I think you'll agree that inconsistency in naming is bad, names like [snip!] are terrible.

I'm probably too late with this...

[asiekierka]

Please stop posting MCP examples on pomf communication channels, or I will be forced to block you from the GitHub repository.

[asiekierka]

https://github.com/FabricMC/pomf/tree/18w47b