Erros ortográficos intencionais para evitar palavras reservadas

44

Muitas vezes vejo códigos que incluem erros ortográficos intencionais de palavras comuns que, para melhor ou pior, 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 poderia ter sido usado - itemClass ou recordTotal .

Um exemplo dos JavaDocs para A classe mostra isso nos parâmetros:

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

Isso mostra um caso de uso razoável?

    
por Nicole 25.03.2011 / 20:46
fonte

12 respostas

63

IMHO, esta é uma péssima ideia. As palavras reservadas são reservadas por um motivo, e isso diminui a legibilidade.

Eu também concordo inteiramente com seu segundo ponto. Nomear uma variável class , mesmo que você pudesse, seria tão ruim quanto nomear tmp ou a . Que tipo de classe? Uma aula de quê? Os nomes devem ser descritivos.

    
por 25.03.2011 / 20:58
fonte
21

O Guia de estilo do Python aborda especificamente esse problema e sugere:

If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name. This is preferable to an abbreviation or corrupted spelling.

Esta parece ser uma boa regra geral, assumindo que não entra em conflito com a semântica de um idioma em particular.

    
por 25.03.2011 / 21:21
fonte
18

Cheiro de código.

string stringVariable = "";

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

class Klass

Mesmo problema

string UserNameString = "bmackey"

O código acima não deve exigir uma string de palavra-chave anexada ao nome da variável. Se você precisar identificar os tipos pelo nome da variável, seu código é muito longo. Condensador-refator.

    
por 25.03.2011 / 23:15
fonte
5

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 tenha que decidir se você quis dizer o idioma mecânico ou sua variável. Com isso em mente, isso implica que eles esperam que as pessoas tenham uma necessidade de uma variável como uma palavra reservada.

Examinando o código-fonte fornecido com o JDK 1.6 R21, encontro 917 ocorrências de "clazz". Aparentemente, eles achavam que era um estilo aceitável.

Como sua equipe se sente sobre isso? Se você acha que é ruim, mas os outros 9 caras do seu time acham que é bom, então você tem que morder a bala e aceitá-la. Desde que haja comunicação sobre o que está certo e o que não está, e você está trazendo os problemas que você vê, você deve estar bem.

A opinião da sua equipe sobre o estilo do código é mais importante do que a minha opinião ou qualquer outra pessoa neste post . Isso vale para isso e para qualquer outra decisão de estilo de código que você possa ter.

    
por 25.03.2011 / 23:49
fonte
3

Erros ortográficos intencionais para evitar palavras reservadas são uma má ideia.

  • Erros de ortografia são difíceis de distinguir da ortografia correta, portanto, tornam o código mais difícil de ler.

  • Erros de ortografia são difíceis de lembrar, de modo que vários erros ortográficos inconsistentes tendem a competir dentro do código, o que torna o código mais difícil de escrever e mais difícil de ler.

  • As palavras reservadas referem-se ao idioma usado para resolver o problema e 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 existir 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());
}
    
por 14.01.2014 / 15:22
fonte
2

Class clazz cheira a "Eu não me preocupei em tentar criar um bom nome". Uma variável está sempre representando algo e um bom nome descreve isso. Recuso-me a imaginar que clazz , por exemplo, sob qualquer circunstância, seja o melhor nome possível. É uma referência a uma classe - > class_reference, is é uma cópia de um objeto de classe - > class_copy, etc. Possivelmente também excluindo "class" e apenas use 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 alvo em que o cheque deve ser executado, então

checkMemberAccess(Class<?> target, int which)

descreveria melhor para que serve o parâmetro do que o clazz.

    
por 07.01.2013 / 12:42
fonte
1

Se eles usam um nome reservado para uma variável, ela é uma variável com nome incorreto. Mesmo que seja um nome legítimo, como Classe 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 Pedaço de Software que você está mantendo.

    
por 25.03.2011 / 23:14
fonte
0

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 palavra para o trabalho. Existem dois lugares não para usar erros ortográficos 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 fictícia e 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 realmente curta. Isso é o que os matemáticos fazem o tempo todo e os programadores fazem pelos índices. Não há razão para se limitar 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 de variáveis curtas quando o método ou a estrutura do código informa o que deve estar lá.

    
por 26.03.2011 / 14:11
fonte
0

Eu vi usos legítimos de Class klass ao fazer reflexões em que você trabalha com uma instância da classe Class .

    
por 30.06.2011 / 23:53
fonte
0

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

klass or clazz for class: Class clazz = ThisClass.class

kount for count in SQL: count(*) AS kount

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

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

Qualquer nome é bom, desde que não seja intencionalmente enganador 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 alinharia 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 todos devem ser curtos), os nomes muito curtos são bons.

    
por 14.01.2014 / 18:47
fonte
0

Acho que erros ortográficos são sempre uma má ideia. Não é legal com seus leitores. Eu, por exemplo, estaria imaginando se perdi alguma coisa quando vi a palavra klass . (Eles quiseram dizer class , ou significaram o pirata?) Pelo menos para mim, todos os erros de ortografia que eu reconheço são irritantes.

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

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

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

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

É claro que o prefixo adicionado é bastante inútil, e só deve ser usado como último recurso, consequentemente. Mas pelo menos não interfere com o analisador mental de seu leitor, e é uma maneira segura de evitar palavras reservadas.

    
por 29.11.2015 / 22:29
fonte
0

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

Mas, até certo ponto, acho que essa questão é mais de opinião do que de substância. Eu pessoalmente cresci em Forth, onde tudo era sobre palavras, e muitas delas. Aprendemos a ser muito criativos para salvar os dedos. No final, eu tinha cerca de 640.000 caracteres, mais ou menos na minha base de origem. Então, manter as palavras curtas era importante para que o trabalho fosse feito.

    
por 15.01.2014 / 13:40
fonte