Errores ortográficos intencionales para evitar palabras reservadas

En mi humilde opinión, esta es una muy mala idea. Las palabras reservadas se reservan por una razón, y al hacerlo disminuye la legibilidad.

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

  

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

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

Olor de código.

string stringVariable = "";

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

class Klass

Mismo problema

string UserNameString = "bmackey"

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

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

Son palabras reservadas para que el compilador no tenga que decidir si te refieres al lenguaje-mecánico o tu variable. Teniendo esto en cuenta, implica que esperan que las personas necesiten una variable como una palabra reservada.

Al revisar el código fuente incluido en JDK 1.6 R21, encuentro 917 apariciones de "clazz". Al parecer, pensaron que era un estilo aceptable.

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

La opinión de su equipo sobre el estilo del código es más importante que mi opinión, o de cualquier otra persona en esta publicación . Eso se aplica a esta y a cualquier otra decisión de estilo de código que pueda tener.

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

• Las faltas de ortografía 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.

• Las faltas de ortografía son difíciles de recordar, por lo que es probable que varias faltas de ortografía 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 que se usa 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 alternativo, descriptivo, o si no existe una alternativa satisfactoria, para calificar la palabra reservada como en:

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

Class clazz huele 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 clazz , por ejemplo, en cualquier circunstancia sea el mejor nombre posible. ¿Es una referencia a una clase - > class_reference, is es una copia de un objeto de clase - > copia_clase, etc. Posiblemente también elimine "clase" y solo use la palabra descriptiva, por ejemplo,

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

Aquí, la clave es la clase objetivo en la que se realizará la comprobación, por lo que

checkMemberAccess(Class<?> target, int which)

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

Si usan un nombre reservado para una variable, es una variable con un nombre incorrecto. 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 otros errores en la pieza de software que está manteniendo.

Creo que las faltas de ortografía o las abreviaciones intencionales son una buena idea si se usan con cuidado y consistencia .

Considera 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 no para 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ódigos de calidad. En el segundo caso, elige una variable realmente corta. Eso es lo que hacen los matemáticos todo el tiempo, y los programadores lo hacen para los índices. No hay razón para limitarte 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 pierdes nada con nombres de variables cortos cuando el método o la estructura del código te dice lo que debe estar allí.

He visto usos legítimos de Class klass al hacer una reflexión en la que realmente trabajas con una instancia de la clase Class .

  

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

     

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

     

kount para conteo 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 utilizado 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 mejor aún, cita recomendaciones de programadores respetados sobre esta práctica?

Para variables locales y argumentos formales, simplemente no importa.

Cualquier nombre está bien siempre y cuando 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 única variable local es "clazz" o "klass" o "cls" o simplemente "c". Probablemente solo pondría 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 deben ser cortos), los nombres muy cortos están bien.

Creo que las faltas de ortografía son siempre una mala idea. Simplemente no es agradable para tus lectores. Yo, por mi parte, me estaría preguntando si me perdí algo cuando veo la palabra klass . (¿Se referían a class , o se referían al pirata?) Al menos para mí, todas las faltas de ortografía que reconozco son irritantes.

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

• Si es un argumento de función, usa aClass en lugar de class .

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

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

Por supuesto, el prefijo agregado es bastante inútil y, por lo tanto, solo debe usarse como último recurso. Pero al menos no interfiere con el analizador mental de su lector, y es una manera segura de evitar las 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 en 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 ser dueño de kzpg.com. Google que ahora y verás sólo unos pocos hits. 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. Crecí personalmente en Forth, donde se trataba de palabras, y muchas de ellas. Uno aprendió a ser muy creativo para salvarse los dedos. Al final tuve unos 640,000 caracteres, más o menos en mi base de origen. Así que mantener las palabras cortas fue importante para hacer el trabajo.