¿Cuándo es demasiado largo el nombre de un método Java? [cerrado]

En las últimas semanas he visto a algunos tipos que usan nombres realmente largos para un Método o Clase (50 caracteres), esto generalmente se basa en la premisa de que mejora la legibilidad, mi opinión es que un nombre largo como este es un indicador de que estamos tratando de hacer mucho o demasiado en una clase de método si necesitamos un nombre tan largo, sin embargo, quería saber qué piensan ustedes al respecto.

Un ejemplo es:

getNumberOfSkinCareEligibleItemsWithinTransaction

Un nombre en Java, o en cualquier otro lenguaje, es demasiado largo cuando existe un nombre más corto que transmite igualmente el comportamiento del método.

Algunas técnicas para reducir la longitud de los nombres de métodos:

1. Si todo su programa, clase o módulo trata sobre 'artículos para el cuidado de la piel', puede dejar el cuidado de la piel. Por ejemplo, si se llama a su clase SkinCareUtils, eso lo lleva agetNumberOfEligibleItemsWithinTransaction

2. Puedes cambiar de adentro a adentro ,getNumberOfEligibleItemsInTransaction

3. Puede cambiar Transacción a Tx, lo que lo lleva a hacerlo getNumberOfEligibleItemsInTx.

4. O si el método acepta un parámetro de tipo Transaction, puede soltar el InTx por completo:getNumberOfEligibleItems

5. Cambia numberOf por cuenta: getEligibleItemsCount

Ahora eso es muy razonable. Y es un 60% más corto.

Solo por un cambio, una respuesta no subjetiva: 65536 caracteres.

A.java:1: la representación UTF8 para la cadena "xxxxxxxxxxxxxxxxxxxx ..." es demasiado larga para el grupo constante

;-)

Estoy de acuerdo con todos: los nombres de los métodos no deberían ser demasiado largos. Sin embargo, quiero agregar una excepción:

Sin embargo, los nombres de los métodos de prueba JUnit pueden ser largos y deben parecerse a oraciones.

¿Por qué?

• Porque no se llaman en otro código.
• Porque se usan como nombres de prueba.
• Porque luego se pueden escribir como oraciones que describen los requisitos. (Por ejemplo, usando AgileDox )

Ejemplo:

    @Test
    public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
        ...
    }

Consulte " Diseño impulsado por el comportamiento " para obtener más información sobre esta idea.

El contexto "... dentro de la transacción" debería ser obvio. De eso se trata la orientación a objetos.

El método es parte de una clase. Si la clase no significa "Transacción", y si no le evita tener que decir "WithinTransaction" todo el tiempo, entonces tiene problemas.

Tiendo a usar la regla de haiku para los nombres:

 Seven syllable class names 
 five for variables
 seven for method and other names

Estas son reglas generales para los nombres máximos. Violo esto solo cuando mejora la legibilidad. Algo como recalculateMortgageInterest (currentRate, quoteSet ...) es mejor que recalculateMortgageInterestRate o recalculateMortgageInterestRateFromSet ya que el hecho de que involucra tasas y un conjunto de cotizaciones debe quedar bastante claro en los documentos integrados como javadoc o el equivalente .NET.

NOTA: No es un haiku real, ya que es 7-5-7 en lugar de 5-7-5. Pero todavía prefiero llamarlo haiku.

Java tiene una cultura de alentar nombres largos, tal vez porque los IDE vienen con un buen autocompletado.

Este sitio dice que el nombre de clase más largo en el JRE es el InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedStateque tiene 92 caracteres de largo.

En cuanto al nombre del método más largo, he encontrado este supportsDataDefinitionAndDataManipulationTransactions, que tiene 52 caracteres.

Nunca use una palabra larga cuando una diminuta servirá.

No creo que su tesis de "la longitud del nombre del método es proporcional a la longitud del método" realmente aguanta.

Tome el ejemplo que da: "getNumberOfSkinCareEligibleItemsWithinTransaction". Eso me parece que solo hace una cosa: cuenta el número de artículos en una transacción que caen en una determinada categoría. Por supuesto, no puedo juzgar sin ver el código real del método, pero eso me parece un buen método.

Por otro lado, he visto muchos métodos con nombres muy cortos y concisos que hacen mucho trabajo, como "processSale" o el siempre popular "doStuff".

Creo que sería difícil dar una regla estricta sobre la longitud del nombre del método, pero el objetivo debería ser: lo suficientemente largo como para transmitir lo que hace la función, lo suficientemente corto como para ser legible. En este ejemplo, creo que "getSkinCareCount" probablemente habría sido suficiente. La pregunta es qué necesitas distinguir. Si tiene una función que cuenta los artículos elegibles para el cuidado de la piel en las transacciones y otra que cuenta los artículos elegibles para el cuidado de la piel en otra cosa, entonces "insideTransactions" agrega valor. Pero si no significa nada hablar de tales artículos fuera de una transacción, entonces no tiene sentido saturar el nombre con información tan superflua.

Dos, creo que es muy poco realista suponer que un nombre de cualquier longitud manejable le dirá exactamente lo que hace la función en todos los casos, excepto en los más triviales. Un objetivo realista es crear un nombre que le dé al lector una pista, y que pueda recordarse más tarde. Por ejemplo, si intento encontrar el código que calcula la cantidad de antimateria que debemos consumir para alcanzar la velocidad de deformación, si miro los nombres de las funciones y veo "calibrateTransporter", "firePhasers" y "calcAntimatterBurn", es bastante claro que los dos primeros no lo son pero el tercero podría serlo. Si compruebo y descubro que ese es el que estoy buscando, será fácil recordarlo cuando regrese mañana para trabajar en este problema un poco más. Eso es lo suficientemente bueno.

Tres nombres largos que son similares son más confusos que los nombres cortos. Si tengo dos funciones llamadas "calcSalesmanPay" y "calcGeekPay", puedo adivinar cuál es cuál a simple vista. Pero si se llaman "CalculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation" y "CalculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation", tengo que estudiar los nombres para ver cuál es cuál. La información adicional en el nombre es probablemente contraproducente en tales casos. Convierte un pensamiento de medio segundo en un pensamiento de 30 segundos.

Diseñe su interfaz de la manera que desee y haga que la implementación coincida.

Por ejemplo, tal vez lo escribiría como

getTransaction().getItems(SKIN_CARE).getEligible().size()

o con secuencias Java 8:

getTransaction().getItems().stream()
    .filter(item -> item.getType() == SKIN_CARE)
    .filter(item -> item.isEligible())
    .count();

Mi regla es la siguiente: si un nombre es tan largo que tiene que aparecer en una línea propia, entonces es demasiado largo. (En la práctica, esto significa que rara vez supero los 20 caracteres).

Esto se basa en investigaciones que muestran que el número de líneas verticales visibles de código se correlaciona positivamente con la velocidad / efectividad de la codificación. Si los nombres de clase / método comienzan a dañar eso significativamente, son demasiado largos.

Agregue un comentario donde se declare el método / clase y deje que el IDE lo lleve allí si desea una descripción larga de para qué sirve.

La longitud del método en sí mismo es probablemente un mejor indicador de si está haciendo demasiado, e incluso eso solo te da una idea aproximada. Debes esforzarte por la concisión, pero la descripción es más importante. Si no puede transmitir el mismo significado en un nombre más corto, entonces el nombre en sí mismo probablemente esté bien.

Cuando va a escribir el nombre de un método la próxima vez, piense en la siguiente cita

"The man who is going to maintain your code is a phyco who knows where you stay"

El nombre del método definitivamente es demasiado largo. Mi mente tiende a divagar cuando leo nombres de métodos tan grandes. Es como leer una oración sin espacios.

Personalmente, prefiero la menor cantidad de palabras posible en los métodos. Se le ayuda si el paquete y el nombre de la clase pueden transmitir significado. Si la responsabilidad de la clase es muy concisa , no hay necesidad de un nombre de método gigante. Tengo curiosidad por qué "WithinTransaction" allí.

"getNumberOfSkinCareEligibleItemsWithinTransaction" podría convertirse en:

com.mycompany.app.product.SkinCareQuery.getNumEligibleItems ();

Luego, cuando esté en uso, el método podría verse como "query.getNumEligibleItems ()"

Un nombre de variable es demasiado largo cuando un nombre más corto permitirá una mejor legibilidad del código en todo el programa o en las partes importantes del programa.

Si un nombre más largo le permite transmitir más información sobre un valor. Sin embargo, si un nombre es demasiado largo, desordenará el código y reducirá la capacidad de comprender el resto del código. Esto suele suceder causando ajustes de línea y eliminando otras líneas de código de la página.

El truco es determinar cuál ofrecerá una mejor legibilidad. Si la variable se usa con frecuencia o varias veces en una pequeña cantidad de espacio, puede ser mejor darle un nombre corto y usar un comentario para aclarar. El lector puede consultar el comentario fácilmente. Si la variable se usa con frecuencia en todo el programa, a menudo como un parámetro o en otras operaciones complicadas, puede ser mejor recortar el nombre o usar siglas como recordatorio para el lector. Siempre pueden hacer referencia a un comentario por la declaración de variable si olvidan el significado.

Esta no es una compensación fácil de realizar, ya que debe considerar lo que el lector de código probablemente intente comprender y también tener en cuenta cómo cambiará y crecerá el código con el tiempo. Es por eso que nombrar cosas es difícil.

La legibilidad es la razón por la cual es aceptable usar i como contador de bucle en lugar de DescriptiveLoopCounterName. Debido a que este es el uso más común para una variable, puede gastar la menor cantidad de espacio en la pantalla explicando por qué existe. El nombre más largo solo va a perder tiempo al hacer que sea más difícil comprender cómo está probando la condición del bucle o indexando en una matriz.

En el otro extremo del espectro, si una función o variable se usa raramente como en una operación compleja, como pasar a una llamada de función de parámetros múltiples, puede darse el lujo de darle un nombre excesivamente descriptivo.

Como con cualquier otro lenguaje: cuando ya no describe la acción única que realiza la función.

Yo diría que use una combinación de las buenas respuestas y sea razonable.

Describa completa, clara y legiblemente lo que hace el método.

Si el nombre del método parece demasiado largo, refactorice el método para hacer menos.

Es demasiado largo cuando el nombre del método se ajusta a otra línea y la llamada al método es lo único en la línea y comienza bastante cerca del margen. Debe tener en cuenta el tamaño promedio de la pantalla de las personas que lo usarán.

¡Pero! Si el nombre parece demasiado largo, entonces probablemente sea demasiado largo. La forma de evitarlo es escribir su código de tal manera que esté dentro de un contexto y el nombre sea corto pero duplicado en otros contextos. Esto es como cuando puedes decir "ella" o "él" en inglés en lugar del nombre completo de alguien.

Es demasiado largo cuando explica de manera verbosa de qué se trata.

Por ejemplo, estos nombres son funcionalmente equivalentes.

en Java: java.sql.SQLIntegrityConstraintViolationException

en Python / Django: django.db.IntegrityError

Pregúntese, en un paquete SQL / db, ¿cuántos tipos más de errores de integridad puede encontrar? ;) Por db.IntegrityErrorlo tanto, es suficiente.

Un nombre de identificador es demasiado largo cuando excede la longitud que su compilador Java puede manejar.

Aquí hay dos formas o puntos de vista: uno es que realmente no importa cuánto sea el nombre del método, siempre que sea lo más descriptivo posible para describir lo que está haciendo el método (regla básica de las mejores prácticas de Java). Por otro lado, estoy de acuerdo con la publicación flybywire. Deberíamos usar nuestra inteligencia para tratar de reducir tanto como sea posible el nombre del método, pero sin reducir su descripción. La descripción es más importante :)

Un nombre es demasiado largo si:

• Toma más de 1 segundo leer
• Ocupa más RAM de la que asigna para su JVM
• Es algo absurdamente llamado
• Si un nombre corto tiene mucho sentido
• Si se envuelve en tu IDE

Honestamente, el nombre solo necesita transmitir su propósito a los Desarrolladores que lo utilizarán como un método API público o que tendrán que mantener el código cuando se vaya. Solo recuerda KISS (mantenlo simple y estúpido)