Yarn: 클래스 명명의 접두사 대 접미사

요 전에 @asiekierka 와의 비공개 토론에서:

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

나는 대부분의 최신 Java IDE에서 검색이 BlockBed/BedBlock의 순서에 관계없이 결과가 표시될 만큼 충분히 모호할 것이라고 주장합니다.

Mojang은 접미사(BedBlock) 또는 이름(Bed)만 사용한다고 생각합니다.

[한조각!]

이러한 클래스는 아마도 동일한 패키지에 있으며 이름은 다음과 같습니다.

RenderType
RepeaterBlock
RotatedPillarBlock
Rotation
SandBlock

Mojang 이름에 인터페이스에 대한 I 접두사가 없음을 보여주는 또 다른 예:

[한조각!]

전자는 편집기에서 이름을 정렬할 때 이점이 있습니다.

이것은 모든 것이 하나의 큰 "싱크" 패키지(예: net.minecraft.src )에 매핑되는 경우 사실이지만 패키지를 올바르게 매핑하는 데는 좋지 않습니다. 그리고 blocks , items , entities 와 같은 패키지에 클래스를 넣으면 접두사가 중복됩니다.

당신의 노력은 칭찬할 만하지만 여기에 MCP 콘텐츠를 게시하지 마십시오. pomf의 Enigma 매핑 또는 Tiny 매핑을 사용하여 다음 번에 요점을 시연하거나 이름을 직접 게시하지 않고 힌트를 주세요.

그러나 연구에 감사드립니다! 우리는 Brigadier 덕분에 Mojang이 I-접두사를 사용하지 않는다는 것을 이미 알고 있었지만 다른 힌트는 꽤 흥미롭습니다. 나는 어느 시점에서 스스로 알파벳 순서를 볼 계획이었지만, Minecraft의 "내부 이름"이 완벽하거나 보다 수정된 개발 환경에 적합하다고 가정할 필요도 없습니다.

저는 개인적으로 접두사를 사용하는 것을 좋아합니다. 왜냐하면 그것은 모든 항목이 함께 그룹화되고 모든 생물 군계가 함께 그룹화된다는 것을 의미하기 때문입니다. 물론 반대 주장은 접미사가 IronIngot, IronSword, IronBlock, IronChestplate 등

@Boundarybreaker 사실, 어쨌든 패키지에 있다는 것입니다. 따라서 .block에서는 이미 그룹화되어 있습니다. 그것이 BlockBed와 BlockChest인지 BedBlock과 ChestBlock인지는 중요하지 않습니다.

아, 그래. 좋은 지적입니다. 나는 mod-dev 측면에서 더 많이 생각했습니다. 접미사는 괜찮습니다.

개인적으로 모든 코드에서 클래스 이름에 접미사 대신 접두사를 사용합니다. 접두사를 사용하게 되는 거의 모든 상황에 대해 해당 규칙에 대한 몇 가지 예외가 있습니다.

내 IDE에서 개체 유형을 검색할 때 더 잘 작동하고 솔직히 더 좋아 보입니다.

이 중 많은 부분이 의견 기반이며 github의 다른 모드 소스 코드를 보면 대부분의 사람들이 접미사 대신 접두사를 사용하는 클래스 이름에 만족한다는 것이 분명합니다.

나는 모든 모드가 MCP 이름을 사용하기 때문에 접두사를 사용하고 MCP 이름은 대부분 접두사를 사용한다고 생각합니다. 왜냐하면 오래 전에 모든 마인크래프트가 단일 net.minecraft.src 패키지로 난독화되었기 때문입니다. 그러나 특히 새 코드에는 접미사를 사용하는 많은 예제가 있는 기능이 있습니다. 예: ILightEngine , ChunkTask , SurfaceBuilder , IWorldCarver , IChunkGenSettings 구현, 구조용 Config/Pieces/Structure 클래스. 레시피 및 전리품 생성용 코드에는 기본 클래스의 이름을 포함하지 않는 파생 클래스가 많이 있습니다.

✓ 파생 클래스의 이름을 기본 클래스의 이름으로 끝내는 것을 고려하십시오.

이것은 매우 읽기 쉽고 관계를 명확하게 설명합니다. 코드에서 이에 대한 몇 가지 예는 Exception의 일종인 ArgumentOutOfRangeException과 Attribute의 일종인 SerializableAttribute입니다. 그러나 이 지침을 적용할 때는 합리적인 판단을 하는 것이 중요합니다. 예를 들어 Button 클래스는 이름에 Control이 나타나지 않지만 일종의 Control 이벤트입니다.

C# 디자인 지침에서

접두사를 사용하면 해당 체계에 고정되고 "판단"이 허용되지 않는다고 생각합니다. 그러나 Block 또는 Item 와 같은 광범위한 상속 계층에는 실제로 필요하지 않을 수 있습니다.

방금 JEI 구현을 살펴보았습니다. api에는 접두사 선례가 없으므로 모든 모딩 커뮤니티 JEI 지원 클래스는 Machine+Category/Wrapper/etc입니다.

MCP에는 기존 모드의 대규모 종속성으로 인해 접미사 이동이 없었습니다. 이것은 패브릭의 경우가 아닙니다.

예. 나는 이미 그것을 하고 싶어하는데, 앉아서 하는 것만으로도 상당한 노력이 필요 합니다.

나는 방금 생각했습니다: 접두사 != 철자를 거꾸로 하고, 다른 맛도 냅니다.

MCP의 예: [잘라요!]

이름의 불일치가 나쁘고 [snip!] 같은 이름이 끔찍하다는 데 동의할 것입니다.

내가 이걸로 너무 늦었나봐...

pomf 통신 채널에 MCP 예제 게시를 중단하십시오. 그렇지 않으면 GitHub 저장소에서 강제로 차단하겠습니다.

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