Intento ser más bien descriptivo con mis nombres de funciones, cuando sea posible. Esto ocasionalmente da como resultado nombres de funciones en el rango de veinte a treinta caracteres, como "GetActionFromTypeName" o "GetSelectedActionType". ¿En qué punto las funciones tardan demasiado en administrarse (no demasiado tiempo para el compilador)?¿Cuándo es un nombre de función demasiado largo?
Si hay una forma más corta pero descriptiva de nombrar la función, el nombre de la función es demasiado largo.
Más específicamente, si existe una palabra que se puede quitar sin introducir ambigüedad, el nombre es demasiado largo. –
Siempre que las funciones realmente hagan lo que su nombre sugiere que hagan y no va a entrar al código de golf, creo que es algo bueno.
Cuando no hace todo que dice que lo hace. ;)
Sí; Steve McConnell en "Code Complete" (al menos la primera edición) está de acuerdo. – iokevins
Cuando se empieza a pensar en él :)
Iba a decir cuándo tienes que mover los ojos, pero esto es más o menos lo mismo. – job
Cuando no se puede leer en voz alta ya sin respirar en el medio = D
En mi opinión un nombre de función debe ser exactamente como se siempre que sea necesario para describir cuál es su propósito. Si cree que el nombre de la función es demasiado largo, puede ser una indicación de que intenta hacer demasiadas cosas y debe refactorizarse.
No creo que el nombre de un método pueda ser demasiado largo, siempre que sea descriptivo. Si el nombre de un método supera los 40 caracteres, veré si puedo transmitir el mismo significado en pocas palabras. Si no, viviré con el nombre largo por claridad.
Yo diría que cuando encuentre encontrar abreviaturas para sus nombres al referirse a ellos. También me parece demasiado cuando las personas comienzan a describir las condiciones previas/posteriores/parámetros en los nombres o dar pistas sobre la implementación. (como getVersionInformationFormTheDatabase() o doSomethingWithoutCheckingFooFirst())
TheFunctionNameBecomesTooLongWhenItBecomesTooHardToReadItAndUnderstandIt, por el contrario it_dependends_on_nameing_convention_how_hard_function_reading_is_sometimes_long_names_are_readable.
Estoy bastante seguro de haber visto las dos funciones anteriores en la biblioteca estándar de PHP. –
En mi humilde opinión, es mucho más importante que las funciones sean descriptivas. IDE ayuda mucho a evitar el problema de errores o algo así. Creo que está bien usar abreviaturas a veces, siempre que sean coherentes a través del código (no hay abreviaturas diferentes para la misma cosa, ni la misma abreviatura para dos cosas diferentes.
El nombre de una función es demasiado largo cuando comienza a sobre-describir lo que hace, o cuando dificulta la legibilidad del código.
Bien puesto. Mantenga los nombres claros y concisos, pero aún descriptivos. – Mark
Creo que esto es especialmente importante para los nombres públicos, no deben ser demasiado largos, pero cuánto tiempo es demasiado subjetivo. mejor un nombre más largo y descriptivo que un nombre demasiado corto.
Para métodos privados incluso los nombres muy largos realmente no son un problema en mi opinión.
Si el nombre de la función es "demasiado largo", es probable que la función también sea demasiado larga y tenga demasiada responsabilidad. Muchos programadores inteligentes dicen que una función debería hacer una cosa y una sola cosa. Una función cuyo nombre tiene que ser largo para describir con precisión lo que hace es probable que sea un buen candidato para la refactorización en multiple smaller and simpler private functions que, en consecuencia, tienen nombres más cortos.
Tratando de evitar la subjetividad:
Cuando los nombres llegan a ser aproximadamente 1/3 de lo que su longitud de la línea típica es, entonces estás estirarla. A la mitad de la longitud de la línea, ya te has ido demasiado. Una afirmación por línea se vuelve bastante difícil cuando los nombres ocupan toda la línea. Más allá de eso, la mayoría de los IDE admiten completitud (ahorrándole al programador escribir la mayoría de los nombres), así que lo más importante, en mi opinión, es asegurar que el nombre sea lo más único posible tan pronto como sea posible.
Creo que debería preocuparse más cuando el nombre de una función es demasiado corto o no es lo suficientemente descriptivo. Mientras su función haga lo que su nombre describe (y todo su nombre lo describe), está bien nombrado. A menudo escribo funciones con nombres largos como getPropertyNameArrayFromObject (aunque tiendo a subrayar en lugar de camelize), que podría llamarse getObjPropArr u otra cosa, pero no sería tan descriptivo. Tiendo a alejarme de las abreviaturas porque se vuelven ambiguas cuando trabajas en otra cosa y vuelves al código.
Por otro lado, considere muchas funciones PHP integradas, como stricmp, que realmente deberían llamarse algo similar a caseInsensitiveStringComparison.
Y hay casos en los que escribo intencionalmente nombres de funciones muy cortos que no son descriptivos en absoluto. A veces solo quiero una breve función de JavaScript para actuar como un atajo. Por ejemplo, generalmente aligo $ (id) a document.getElementById (id) porque me cansé de tipear eso.
Los nombres de los métodos pueden ser muy largos dependiendo del idioma (Maximum Method Name Length). En algún punto, va a usar esa función o método y escribir una oración para los nombres de las funciones parece innecesario.
Mantenga su código mantenible, use comentarios en su lugar.
Si un compilador tiene algunas limitaciones en los nombres de variables, a menudo es de 64 o 128 caracteres o en algún punto intermedio. En el pasado, 32 personajes también han sido populares. Si tienen un límite, a menudo simplemente toman los primeros n caracteres e ignoran el resto.
La regla general es que el nombre de la función proporciona una descripción muy breve de lo que está haciendo. La mayoría de tales descripciones deberían caber fácilmente dentro de 32 caracteres. (Use CamelCase para separar las palabras.) Debido a que la mayoría de los IDE ahora proveen la finalización del código, hacer errores con los nombres de las funciones tiende a ser raro. Pero hágalo más fácil asegurándose de que la mayoría de las funciones difieran entre sí con los primeros 8 caracteres. Deben evitarse algo como DateCalculationAddMonth, DateCalculationAddWeek, DateCalculationAddYear y DateCalculationAddDay. Use AddMonthDateCalculation, AddWeekDateCalculation, AddYearDateCalculation y AddDayDateCalculation. (Por cierto, estos son ejemplos tontos pero espero que entiendas mi deriva.)
En realidad, podría ser mejor agregar (agrupar) tus funciones a una clase separada. Con el ejemplo tonto anterior, podría simplemente crear una clase DateCalculation y agregar cuatro funciones (estáticas/de clase) (AddMonth, AddWeek, AddYear y AddDay) a esa clase. Básicamente, esto sería más útil cuando tienes muchas funciones similares que tendrían nombres muy largos si no los agrupas en clases separadas.
¡Ah, una pregunta sin respuesta!
Tiendo a encontrar si no puedo encapsularlo en pocas palabras, entonces hay algo con el diseño (paracribiendo desde Code Complete).
Así que, aunque estoy contento con FindArticlesWithoutTitles, probablemente me disgustaría FindArticlesWithoutTitlesThenApplyDefaultStyles. Esto es simplemente incorrecto; o el nombre es demasiado técnico y no describe su función real (los títulos sin artículos a menudo necesitan estilos para ser reparados, por lo que sería FixArticleStyles) o deberían ser dos funciones: FindArticlesWithoutTitles/ApplyDefaultStyles.
También: la frecuencia tiene mucho que ver con eso. Si se usa con frecuencia, quiero que sea corto, para reducir el resplandor del código; los nombres largos repetitivos hacen que el código sea feo de leer y un dolor al escribir. Si siempre encuentro FindArticlesWithoutTitles, podría acortar a FindNoTitles según el contexto apropiado o tal vez solo a FindArticles si no tengo otras funciones para buscar artículos.
Tenga en cuenta en este ejemplo que el hábito de nombrar funciones con un título completamente descriptivo fue lo que encontró el error de diseño. Al descubrir que el nombre correcto sería "FindArticlesWithoutTitlesThenApplyDefaultStyles", en realidad descubrió que la función estaba haciendo demasiado. Una tendencia a abreviar los nombres enmascararía este hecho. Haga sus nombres descriptivos. Si la descripción es demasiado larga, acorte la función, no el nombre. –
Pero yo diría que no es tan sencillo, el verboso de una persona es el minimalismo de otra persona. Tengo una función que hace lo siguiente: abre un archivo, lee cada línea del archivo, valida, compara con las filas de la base de datos, y todo lo que no está en la base de datos se almacena en un diccionario C#. Eso suena como un montón de cosas, pero dividir esto en varias funciones dificultaría mucho más la lectura. Es más simple envolverlo en una función llamada LoadSymbolsFile, que tiene sentido dentro del contexto de la clase. La función es privada y se llama una vez. –
Puede ser un poco fuera de tema, pero como lo pidió específicamente para un función nombre directriz (en contraposición a decir, método), pensé que iba a citar a Linus Torvalds en nombrar (a pesar de que más se refiere a las variables, pero aún así, los principios son válidos).
Capítulo 3: Naming
C es un lenguaje Spartan, y así debe sea su denominación. A diferencia de los programadores Pascal Modula-2 y , los programadores C no usan nombres lindos como ThisVariableIsATemporaryCounter. Un programador de C llamaría a esa variable "tmp", que es mucho más fácil de escribir, y no menos difícil de comprender a .
Los nombres cortos y descriptivos combinan bien con funciones cortas y específicas ... que combinan bien con la reutilización de código.
Cuando contiene información que es evidente a partir del contexto (por ejemplo, incrementInteger (int x), largo Longid), inútil (por ejemplo, ObsoleteIncrementer, RobertsCarFactory), incomprensible (por ejemplo, TheFunctionThatRobertWorkedOnLastWeekButDidntFinish), numérico (por ejemplo, id1, id2, id3) o no ayuda a comprender o contiene un olor a código. Tenga en cuenta que aunque algunos de los nombres anteriores deben ser eliminados, es posible que necesite rellenarlos con información útil para mantenerlos únicos y hacerlos comprensibles, como en person_id para id1, employer_id para id2, etc.
La función el nombre es demasiado largo cuando podría ahorrarle trabajo para usar uno más corto.
La razón por la que usualmente buscamos nombres de funciones descriptivas es porque nos ahorra trabajo. (haciendo que sea más fácil de entender y mantener el código).Lo que se deduce lógicamente que no se debe dar a sus nombres de funciones que son tan largos que le cuesta más tiempo (haciendo que el código más difícil de leer, por ejemplo)
De Code Complete (primera edición, página 188)
"Gorla, Benander y Benander descubrieron que el esfuerzo requerido para depurar un programa COBOL se minimizaba cuando las variables tenían nombres que promediaban de 10 a 16 caracteres (1990). Los programas con nombres promedio de 8 a 20 caracteres eran casi tan fáciles de depurar".
Esto constituye la única discusión empírica de una directriz razonable para la longitud de nombre variable que he visto. Todo lo demás depende de la opinión y la comodidad.
No creo que esta discusión empírica sea directamente aplicable, ya que no se refiere a nombres de funciones, solo nombres de variables. – mtnpaul
IMO, es demasiado largo cuando tiene una conjunción en él. "Cuando", "Y", "Entonces", ... algo así. Seguir la regla de la responsabilidad única debe permitir que los nombres de las funciones sean lo suficientemente largos para ser descriptivos y lo suficientemente cortos como para no ser ridículamente molestos.
Hazte una pregunta más interesante: ¿Por qué hacemos que los nombres de las funciones sean largos? Es para describir lo que hace la función. Bueno, a mi juicio esta hipótesis:
La cantidad de descripción necesaria en un nombre de función es inversamente proporcional a la cantidad de información disponible para el mismo tipo.
Para ilustrar este punto, si viste una función como esta ...
public <A> A id(A a);
... ¿qué pensaría usted que hace? La información tipo te dice todo lo que necesitas saber. Exceptuando los efectos secundarios y las excepciones, , solo hay una cosa que esta función podría hacer.
Por supuesto, probablemente trabaje en un lenguaje que permite efectos secundarios sin restricciones, por lo que la función podría, por ejemplo, escribir en un archivo. Pero si lo hace , entonces su tipo es una mentira. Trabajar en un lenguaje que declara efectos en tipos le permite usar nombres muy escuetos sin pérdida de descriptivo.
A veces el límite de 30 caracteres en muchos contextos en Oracle SQL y PL/SQL se sentía como una restricción terrible, pero a la reflexión nos ha hecho pensar muchas veces acerca de cómo nombrar las cosas para que sean entendidas rápidamente por alguien leyendo el código más tarde.
Si no pudiéramos describir adecuadamente el propósito de una tabla, vista, función, procedimiento, paquete, etc. usando 30 caracteres sin usar abreviatura excesiva, solo necesitaba un poco más de pensamiento, y tal vez una capa adicional de abstracción para agrupar cosas relacionadas juntas.
Los nombres de las funciones y los métodos comienzan a ser demasiado largos cuando el desarrollador se olvida de la naturaleza descriptiva de los argumentos (asumiendo argumentos significativos y nombres de variables). Por ejemplo:
my $template = HTML::Template->new(filename => 'home.html');
$template->param(title => 'Home Page');
$html = $template->output;
es transparente en lo que hace incluso si conoce ningún Perl y nunca han oído hablar de HTML::Template.
He visto demasiado a menudo la tentación de llamar a ese output método algo así como RenderHTMLViewFromTemplateObject. Si todas las bibliotecas utilizadas tienen tales convenciones de nomenclatura, me resulta simplemente imposible seguir lo que está sucediendo.
El nombre de una función se alarga demasiado cuando tiene que usar un editor sin completar el código. – schnaader
Los nombres de mis funciones tienen la misma longitud cuando uso vim ... –
Bueno, los usuarios de vim también tienden a escribir bastante rápido. OK, los programadores en general tienden a escribir mejor las habilidades ... pero con la finalización del código aún funciona mejor. – schnaader