Yarn: Helper vs Util vs Utils

Eu gosto mais do singular Util . 👍 para Util. 👎 para Ajudante, 😕 para Utilitários

tbh eu poderia ir de qualquer maneira, apenas vamos ser consistentes.

Além disso, se tivermos verbos, podemos usar -ing (gerúndio), por exemplo, Chatting NetworkThreading , ou substantivos no plural, por exemplo, Projectiles Screenshots over Helper Util etc.

Isso dificulta algumas coisas como MathHelper -> Maths ?? Ou Util -> s ??

Eu defendi Maths há muito tempo, já que é uma abreviação válida para Mathematics . https://github.com/FabricMC/yarn/issues/249#issuecomment -446102638

Yarn usa nomes em inglês americano, onde Maths não é uma abreviação válida para Mathematics .

Neste caso em que nem o gerúndio nem o plural se aplicam, sugiro voltar ao sufixo Helper . Caso contrário, prefira ing ou s , como Texts

Além disso DrawableHelper não é uma classe utilitária, mas uma interface funcional ou classe abstrata com muitos métodos de instância convenientes

Meu problema com a proposta do liach com -ing e -s é que torna muito difícil fazer algo consistente, derrotando completamente o propósito do problema. Você pode fazer com que as classes de utilidade de substantivos terminem em -s , mas então você terá exceções: Nbts , RailPlacements , Maps ? Seria impossível tornar consistente.

Devemos adotar um padrão e cumpri-lo. Olhando para a votação, deve ser Helper ou Util , mas não Utils .

Um argumento para Util sobre Helper é que a classe Util si não faz sentido ser chamada Helper . Acho que MathHelper ser chamado MathUtil não seria tão ruim, só que todo mundo já está acostumado a ser chamado MathHelper . Eu trabalhei em projetos onde a classe de utilidade matemática foi chamada MathUtil , e tem sido absolutamente boa, não faz diferença. O nome MathUtil nem foi discutido na questão de renomeação MathHelper .

Existem mais classes Util do que Helper atualmente, mas isso precisa ser ponderado pela frequência com que as classes são realmente usadas, então vou analisar isso agora e relatar os resultados .

Parece que a maioria das pessoas são para o sufixo Helper . Portanto, proponho renomear todas as classes atuais que terminam com Util ou Utils (exceto a classe Util ) para terminar com Helper . Renomeações de outras classes para terminar em Helper podem ser discutidas em edições separadas.

Parece que a maioria das pessoas são para o sufixo Helper .

Não?

Oh, opa, devo ser cego. Então proponho que renomeiemos todas as classes que terminam em Helper para terminarem com Util .

Proponho que os sufixos são obra do diabo e que renomeamos todas as classes que terminam em *elperer e *til para não ter esse sufixo.

MathHelper -> Maths .

PiglinHelper -> Piglins

Yarn usa nomes em inglês americano, onde Maths não é uma abreviação válida para Mathematics .

Eu pensei que Maths era um termo exclusivamente americano?

MathHelper -> Mathinator

Maps ? eu

Observe também que Guava (acho que era Guava?) usa o padrão plural: Maps , Sets , Collections , Streams .

Este foi o meu problema com o uso de plurais. Embora os nomes pareçam bonitos, há muitas exceções. Ou porque a palavra é um substantivo de massa (por exemplo, "matemática") e, portanto, não tem plural, ou porque o plural já é usado por outra biblioteca (por exemplo, "mapa"). Seria muito difícil permanecer consistente, derrotando o ponto de mudá-los em primeiro lugar.

Nomes que ficariam bem no plural:

• Tampões
• DataStreams
• Drawables
• DefaultSkins
• Mipmaps
• Nbts
• RailPlacements
• Gera
• Entradas
• Modelos
• Texturas
• Nomes de arquivo
• Projéteis
• LookTargets
• Testes de estrutura
• Testes
• Capturas de tela
• Alocações de Gl

Nomes que não estão bem porque são substantivos de massa ou não são substantivos:

• Jsons
• Matemáticas
• Als
• Glfws
• Suaviza
• Danos (o plural tem um significado diferente)
• Redes (há apenas uma rede aqui)
• NetworkThreads (há apenas um thread de rede)
• Criptografias de Rede

Nomes que não estão corretos porque já foram usados:

• Encantamentos
• Mapas
• Efeitos de status
• Poções

Nomes que não são aceitáveis ​​por diversos motivos:

• Rotation3s (este nome requer mais reflexão)
• Bate-papos (embora tecnicamente seja o plural de bate-papo, não se encaixa bem como uma classe de utilidade para "o bate-papo", assumindo que é para isso que serve. Se for para componentes de texto, "Textos" seria um bom nome)
• Utils (não podemos renomear isso para "s" lol, é melhor mantê-lo como "Util")

No total, 18/34 nomes ficariam bem no plural, o que significa que teríamos que encontrar nomes melhores para os outros 16. Tanto para consistência.

Eu ficaria bem em usar plurais onde faz sentido e voltar para um sufixo Util onde não faz sentido. Então, pelo menos, temos uma regra a seguir, em vez de escolher aleatoriamente entre "Helper" e "Util", que é o que fazemos atualmente.

O @Earthcomputer NetworkThreads funciona bem, no entanto. São utilitários para trabalhar com threads de rede. Não importa que haja apenas um deles.

Você pode discordar de mim em um ou dois desses pontos, mas esse não é o ponto, isso não muda muito a proporção geral de 18/34.

Eu argumentaria por Util ou Helper , removê-los inteiramente não faz muito sentido para mim.

A propósito, alguns não podem ser nomeados Util . Por exemplo, DataStreamHelper não é uma classe util, é um objeto que envolve um fluxo de dados.