Erros ortográficos intencionais para evitar palavras reservadas

Frequentemente, vejo códigos que incluem erros ortográficos intencionais de palavras comuns que, para o bem ou para o mal, se tornaram palavras reservadas:

• klassou clazzpara aula :Class clazz = ThisClass.class
• kountpara contagem no SQL:count(*) AS kount

Pessoalmente, acho que isso diminui a legibilidade. Na minha própria prática, não encontrei muitos casos em que um nome melhor não pudesse ser usado - itemClassou recordTotal.

Um exemplo do JavaDocs for Class mostra isso nos parâmetros:

 public <U> Class<? extends U> asSubclass(Class<U> clazz)

Isso mostra um caso de uso razoável?

IMHO, essa é uma péssima idéia. Palavras reservadas são reservadas por um motivo, e isso diminui a legibilidade.

Também concordo inteiramente com o seu segundo ponto. Nomear uma variável class, mesmo que você possa fazê-lo, seria tão ruim quanto nomear tmpou a. Que tipo de aula? Uma classe de quê? Os nomes devem ser descritivos.

O Guia de Estilo do Python chama esse problema especificamente e sugere:

Se o nome do seu atributo público colidir com uma palavra-chave reservada, anexe um único sublinhado à direita no nome do seu atributo. É preferível a uma abreviação ou ortografia corrompida.

Parece uma regra geral muito boa, supondo que não entre em conflito com a semântica de um idioma específico.

Cheiro de código.

string stringVariable = "";

O código acima não me diz nada sobre o uso pretendido das variáveis.

class Klass

Mesmo problema

string UserNameString = "bmackey"

O código acima não deve exigir a sequência de palavras-chave anexada ao nome da variável. Se você precisar identificar tipos pelo nome da variável, seu código será muito longo. Refatorar de condensação.

Pessoalmente, acho que é uma opção perfeitamente válida para o seu estilo de código.

São palavras reservadas para que o compilador não precise decidir se você quis dizer o mecânico da linguagem ou sua variável. Com isso em mente, isso implica que eles esperam que as pessoas precisem de uma variável como uma palavra reservada.

Percorrendo a fonte que acompanha o JDK 1.6 R21, encontro 917 ocorrências de "clazz". Aparentemente, eles pensaram que era um estilo aceitável.

Como sua equipe se sente sobre isso? Se você acha que é ruim, mas os outros nove caras da sua equipe acham que é bom, então você precisa morder a bala e aceitá-la. Contanto que haja comunicação sobre o que está bem e o que não está, e você está levantando problemas que vê como os vê, tudo ficará bem.

Como sua equipe se sente sobre o estilo do código é mais importante do que minha opinião, ou de qualquer outra pessoa neste post . Isso vale para essa e quaisquer outras decisões de estilo de código que você possa ter.

Erros ortográficos intencionais para evitar palavras reservadas são uma má idéia.

• Os erros de ortografia são difíceis de distinguir da ortografia correta, portanto, dificultam a leitura do código.

• Os erros de ortografia são difíceis de lembrar, de modo que vários erros de ortografia inconsistentes provavelmente competem no código, o que torna o código mais difícil de escrever e mais difícil de ler.

• Palavras reservadas referem-se ao idioma que está sendo usado para resolver o problema, não ao problema em si. Um nome de variável deve apontar para um conceito relacionado ao problema.

Portanto, é melhor escolher um nome descritivo alternativo ou, se não houver uma alternativa satisfatória, qualificar a palavra reservada como em:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> benchmarkedClass = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(benchmarkedClass, benchmark.generatedMethod());
}

Class clazzcheira como "eu não me incomodei em tentar criar um bom nome". Uma variável está sempre representando algo, e um bom nome descreve isso. Recuso-me a imaginar que, clazzpor exemplo, sob qualquer circunstância seja o melhor nome possível. É uma referência a uma classe -> class_reference, é uma cópia de um objeto de classe -> class_copy, etc. Também é possível soltar "class" e usar apenas a palavra descritiva, por exemplo

java.lang.SecurityManager.checkMemberAccess(Class<?> clazz, int which)
Parameters
    clazz -- the class that reflection is to be performed on.

Aqui clazz é a classe de destino na qual a verificação deve ser realizada, portanto

checkMemberAccess(Class<?> target, int which)

descreveria muito melhor para que o parâmetro é usado do que o clazz jamais fará.

Se eles usam um nome reservado para uma variável, é uma variável com nome inadequado. Mesmo que seja um nome legítimo, como Class para software de sala de aula.

Variáveis ​​mal nomeadas são um sinal de código mal pensado ou casual - cuidado com outras dicas do software que você está mantendo.

Acho que erros ortográficos ou abreviaturas intencionais são uma boa ideia se usados ​​com cuidado e consistência .

Considere em Java:

class X { public X() { } }
X x = new X();
x.getClass;  // Wha?  How does "get" help anything?
x.class;     // Best, but requires more lexer/parser work
x.klass;     // At least as good as getClass
x.clazz;     // Same

O lugar para usar erros ortográficos é onde a palavra reservada é claramente a melhor para o trabalho. Existem dois lugares para não usar erros de ortografia nos quais você pode ser tentado.

1. Você não sente vontade de pensar em um bom nome
2. Você só quer uma variável dummy e ela não precisa de um nome descritivo

No primeiro caso, é bastante óbvio que a preguiça raramente é uma boa política para criar código de qualidade. No segundo caso, escolha uma variável muito curta. É isso que os matemáticos fazem o tempo todo e os programadores fazem pelos índices. Não há razão para limitar-se a fazer isso por índices se realmente for apenas uma variável fictícia:

boolean isMyName(String testName) { return myName.equals(testName); }
boolean isMyName(String s) { return myName.equals(s); }

Date nextMeeting(Klass klass) { return /* something */ }
Date nextMeeting(Klass k) { return /* something */ }

Você não perde nada com nomes curtos de variáveis ​​quando o método ou a estrutura do código informa o que deve estar lá.

Eu já vi usos legítimos Class klassao refletir quando você realmente trabalha com uma instância da Classclasse.

Frequentemente, vejo códigos que incluem erros ortográficos intencionais de palavras comuns que, para o bem ou para o mal, se tornaram palavras reservadas:

klass ou clazz para a classe: Class clazz = ThisClass.class

kount para count no SQL: count (*) AS kount

Pessoalmente, acho que isso diminui a legibilidade. Na minha prática, não encontrei muitos casos em que um nome melhor não pudesse ser usado - itemClass ou recordTotal.

No entanto, é tão comum que não posso deixar de me perguntar se sou o único? Alguém tem algum conselho ou, melhor ainda, recomendações citadas por programadores respeitados sobre essa prática?

Para variáveis ​​locais e argumentos formais, isso simplesmente não importa.

Qualquer nome é bom, desde que não seja intencionalmente enganoso ou perturbador. No seu exemplo:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

não importa se a única variável local é "clazz" ou "klass" ou "cls" ou simplesmente "c". Eu provavelmente apenas incorporaria a expressão:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

O comprimento do nome de uma variável deve estar relacionado ao escopo da variável. Para variáveis ​​locais em métodos curtos (e todas devem ser curtas), nomes muito curtos são adequados.

Eu acho que erros de ortografia são sempre uma má idéia. Não é legal para seus leitores. Eu, por exemplo, estaria me perguntando se perdi alguma coisa quando vejo a palavra klass. (Eles queriam dizer classou o pirata?) Pelo menos para mim, todos os erros de ortografia que reconheço são irritantes.

Nos poucos casos em que a palavra reservada é realmente a única coisa significativa conhecida sobre a variável, eu usaria as seguintes alternativas:

• Se for um argumento de função, use em aClassvez de class.

• Se for uma variável local ou membro, use em myClassvez de class.

• Se for um acessador, use em getClass()vez de class().

Obviamente, o prefixo adicionado é inútil e, portanto, só deve ser usado como último recurso. Mas pelo menos isso não interfere no analisador mental do seu leitor e é uma maneira segura de evitar palavras reservadas.

Um benefício para a ortografia criativa é a melhor capacidade de pesquisa. Eu acho que é muito mais fácil fazer uma pesquisa completa de código por coisas únicas, do que por palavras comuns, onde muitas vezes você encontrará todas as coisas erradas, e 1000 delas. Como exemplo, eu costumava possuir o kzpg.com. Google que agora e você verá apenas alguns hits. É único e, portanto, muito localizável.

Mas, até certo ponto, acho que essa pergunta é mais uma opinião do que substância. Pessoalmente, eu cresci na Forth, onde se tratava de palavras e muitas delas. Aprendemos a ser muito criativos para economizar os dedos. No final, eu tinha cerca de 640.000 caracteres, mais ou menos na minha base de origem. Portanto, manter as palavras curtas era importante para realizar o trabalho.