Errores ortográficos intencionales para evitar palabras reservadas

A menudo veo códigos que incluyen errores ortográficos intencionales de palabras comunes que, para bien o para mal, se han convertido en palabras reservadas:

• klasso clazzpara la clase :Class clazz = ThisClass.class
• kountpara contar en SQL:count(*) AS kount

Personalmente, encuentro que esto disminuye la legibilidad. En mi propia práctica, no he encontrado demasiados casos en los que no se podría haber usado un nombre mejor, itemClasso recordTotal.

Un ejemplo de JavaDocs para Class muestra esto en los parámetros:

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

¿Muestra esto un caso de uso razonable?

En mi humilde opinión, esta es una muy mala idea. Las palabras reservadas están reservadas por una razón, y hacer esto disminuye la legibilidad.

También estoy totalmente de acuerdo con tu segundo punto. Nombrar una variable class, incluso si pudieras hacerlo, sería tan malo como nombrarla tmpo a. Que clase de clase ¿Una clase de qué? Los nombres deben ser descriptivos.

La Guía de estilo de Python menciona este problema específicamente y sugiere:

Si el nombre de su atributo público choca con una palabra clave reservada, agregue un guión bajo al nombre de su atributo. Esto es preferible a una abreviatura o una ortografía corrupta.

Esto parece una regla general bastante buena, suponiendo que no entre en conflicto con la semántica de un idioma en particular.

Código de olor.

string stringVariable = "";

El código anterior no me dice nada sobre el uso previsto de las variables.

class Klass

El mismo problema

string UserNameString = "bmackey"

El código anterior no debe requerir una cadena de palabras clave agregada al nombre de la variable. Si necesita identificar tipos por nombre de variable, su código es demasiado largo. Condensador-refactor.

Personalmente, creo que es una opción perfectamente válida para su estilo de código.

Son palabras reservadas para que el compilador no tenga que decidir si se refería a la mecánica del lenguaje o su variable. Con eso en mente, implica que esperan que las personas necesiten una variable como una palabra reservada.

Al revisar la fuente incluida con JDK 1.6 R21, encuentro 917 ocurrencias de "clazz". Aparentemente, pensaron que era un estilo aceptable.

¿Cómo se siente tu equipo al respecto? Si crees que es malo, pero los otros 9 muchachos de tu equipo piensan que es bueno, entonces tienes que morder la bala y aceptarlo. Siempre y cuando haya comunicación sobre lo que está bien y lo que no, y está planteando problemas que ve como los ve, debería estar bien.

Lo que siente su equipo sobre el estilo de código es más importante que mi opinión, o la de cualquier otra persona en esta publicación . Eso vale para esta y cualquier otra decisión de estilo de código que pueda tener.

Los errores ortográficos intencionales para evitar palabras reservadas son una mala idea.

• Los errores ortográficos son difíciles de distinguir de la ortografía correcta, por lo tanto, hacen que el código sea más difícil de leer.

• Los errores ortográficos son difíciles de recordar, por lo que es probable que varios errores ortográficos inconsistentes compitan dentro del código, lo que hace que el código sea más difícil de escribir y de leer.

• Las palabras reservadas se refieren al lenguaje utilizado para resolver el problema, no al problema en sí. Un nombre de variable debe apuntar a un concepto relacionado con el problema.

Por lo tanto, es mejor elegir un nombre descriptivo alternativo o, si no existe una alternativa satisfactoria, calificar la palabra reservada como en:

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

Class clazzhuele a "No me molesté en tratar de encontrar un buen nombre". Una variable siempre representa algo, y un buen nombre lo describe. Me niego a imaginar que, clazzpor ejemplo, bajo ninguna circunstancia sea el mejor nombre posible. ¿Es una referencia a una clase?> Class_reference; es una copia de un objeto de clase?

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

Aquí clazz es la clase de destino en la que se realizará la verificación, por lo que

checkMemberAccess(Class<?> target, int which)

describiría mucho mejor para qué se usa el parámetro de lo que nunca lo hará clazz.

Si usan un nombre reservado para una variable, es una variable mal nombrada. Incluso si es un nombre legítimo, como Clase para software de aula.

Las variables mal nombradas son un signo de código mal pensado o casual; tenga cuidado con otras trampas en el Software que está manteniendo.

Creo que los errores ortográficos o abreviaturas intencionales son una buena idea si se usan con cuidado y de manera consistente .

Considere en 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

El lugar para usar errores ortográficos es donde la palabra reservada es claramente la mejor palabra para el trabajo. Hay dos lugares para no usar errores ortográficos en los que podría sentirse tentado.

1. No tienes ganas de pensar en un buen nombre
2. Solo desea una variable ficticia y no necesita un nombre descriptivo

En el primer caso, es bastante obvio que la pereza rara vez es una buena política para crear código de calidad. En el segundo caso, elija una variable realmente corta. Eso es lo que los matemáticos hacen todo el tiempo, y los programadores hacen para los índices. No hay razón para limitarse a hacer esto para los índices si realmente es solo una variable ficticia:

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 */ }

No pierde nada con nombres cortos de variables cuando el método o la estructura del código le dice qué debe estar allí.

He visto usos legítimos de Class klasscuando hago reflexiones donde realmente trabajas con una instancia de la Classclase.

A menudo veo códigos que incluyen errores ortográficos intencionales de palabras comunes que, para bien o para mal, se han convertido en palabras reservadas:

klass o clazz para clase: Class clazz = ThisClass.class

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

Personalmente, encuentro que esto disminuye la legibilidad. En mi propia práctica, no he encontrado muchos casos en los que no se podría haber usado un nombre mejor: itemClass o recordTotal.

Sin embargo, es tan común que no puedo evitar preguntarme si soy el único. ¿Alguien tiene algún consejo o incluso mejor, recomendaciones citadas de programadores respetados sobre esta práctica?

Para variables locales y argumentos formales, simplemente no importa.

Cualquier nombre está bien siempre que no sea intencionalmente engañoso o molesto. En tu ejemplo:

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

no importa si la variable local única es "clazz" o "klass" o "cls" o simplemente "c". Probablemente solo en línea la expresión:

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

La longitud del nombre de una variable debe estar relacionada con el alcance de la variable. Para las variables locales en métodos cortos (y todos deberían ser cortos), los nombres muy cortos están bien.

Creo que los errores ortográficos son siempre una mala idea. Simplemente no es agradable para tus lectores. Yo, por mi parte, me preguntaría si me perdí algo cuando veo la palabra klass. (¿Significaron classo significaron el pirata?) Al menos para mí, todos los errores ortográficos que reconozco son irritantes.

Para los muy pocos casos, donde la palabra reservada es realmente la única cosa significativa que se conoce sobre la variable, usaría las siguientes alternativas:

• Si es un argumento de función, use en aClasslugar de class.

• Si es una variable local o miembro, use en myClasslugar de class.

• Si es un descriptor de acceso, use en getClass()lugar de class().

Por supuesto, el prefijo agregado es bastante inútil y, en consecuencia, solo debe usarse como último recurso. Pero al menos no interfiere con el analizador mental de su lector, y es una forma segura de evitar palabras reservadas.

Un beneficio para la ortografía creativa es una mejor capacidad de búsqueda. Creo que es mucho más fácil hacer una búsqueda de código completo para cosas únicas, que para palabras comunes, donde con demasiada frecuencia encontrarás todas las cosas incorrectas, y 1000 de ellas. Como ejemplo, solía tener kzpg.com. Google eso ahora y verás solo unos pocos éxitos. Es único y, por lo tanto, muy fácil de encontrar.

Pero, en cierta medida, creo que esta pregunta es de opinión más que de sustancia. Personalmente, crecí en Forth, donde se trataba de palabras, y muchas de ellas. Uno aprendió a ser muy creativo para salvar los dedos. Al final tenía unos 640,000 caracteres, más o menos en mi base de origen. Por lo tanto, mantener las palabras cortas fue importante para hacer el trabajo.