El dios de los concursos de programación
Sin embargo, los nombres aparentemente simples también son un dolor de cabeza para muchos programadores. Algunos amigos, al nombrar variables, incluso nombrarán los nombres familiares en inglés en inglés. Si la parte que necesita ser nombrada no está expresada en inglés, pueden usar simplemente Pinyin.
Algunos zapatos infantiles no se pueden recordar a la vez. Nombrarlo directamente con pinyin más letras como aa, bb, etc. no tiene ningún significado representativo. Su legibilidad es pobre. Quizás lo escribieron hoy y olvidaron lo que significaba cuando regresaron una semana después.
Entonces, ¿muchas personas siempre piensan en qué método de nomenclatura se debe utilizar antes de escribir código? Para los pacientes obsesivo-compulsivos que cambian con frecuencia entre lenguajes convencionales como C, Java, Python, etc., cambiar de idioma y estilos de nombres no debería ser demasiado confuso.
Ya que hay tantos nombres por hacer, ¿por qué no hacerlo? En este número, Async le ofrece algunas reglas simples a seguir al elegir un buen nombre. vamos a ver.
— 01 —
Hacer honor al nombre
Hacer honor al nombre es fácil de decir. Nos gustaría subrayar que este asunto es muy grave. Elegir un buen nombre lleva tiempo, pero ahorra más tiempo del que cuesta. Preste atención al nombre y reemplace el antiguo tan pronto como encuentre uno mejor. Al hacer esto, las personas que lean su código (incluido usted mismo) estarán más felices.
El nombre de la variable, función o clase ya debería responder a todas las grandes preguntas. Debería decirle por qué existe, qué hace y cómo debe utilizarlo. Si el nombre requiere comentario adicional, no lo merece.
El nombre d no dice nada. No evoca en el lector la sensación del paso del tiempo, y mucho menos en términos de días. Debemos elegir nombres que representen objetos y unidades de medida:
Elegir un nombre que refleje el significado original facilita que las personas comprendan y modifiquen el código. ¿Cuál es el propósito del siguiente código?
¿Por qué es tan difícil explicar qué hace el código anterior? No hay expresiones complejas, el espaciado y la sangría son normales, solo se usan tres variables y dos constantes, y ni siquiera hay otras clases o métodos polimórficos involucrados, solo (o lo que parece ser) una lista de matrices.
El problema no es la simplicidad del código, sino la ambigüedad del código: hasta qué punto el contexto no se refleja claramente en el código. El código anterior requiere que conozcamos las respuestas a las siguientes preguntas:
(1) ¿Qué tipo de cosas hay en la lista?
(2)¿Cuál es el significado de las entradas marcadas con temperaturas bajo cero en la lista?
(3)¿Cuál es el significado del valor 4?
(4)¿Cómo utilizar la lista devuelta?
Las respuestas a las preguntas no se reflejan en los fragmentos de código, pero los fragmentos de código están donde deberían estar. Por ejemplo, estábamos desarrollando un juego Buscaminas y descubrimos que el disco era una lista de celdas llamada Lista, así que cambiamos su nombre a GameBoard.
Cada celda del disco está representada por una matriz simple. También descubrimos que la entrada marcada bajo cero es un valor de estado, y un valor de estado de 4 significa "marcado". Simplemente cambiar el nombre por algo significativo mejorará considerablemente el código:
Tenga en cuenta que la simplicidad del código no se ha modificado. La cantidad de operadores y constantes sigue siendo la misma, la cantidad de anidamientos sigue siendo la misma, pero el código se vuelve mucho más claro.
Puedes ir un paso más allá y escribir otra clase para representar las celdas en lugar de una matriz int. Esta clase contiene una función literal (llamada isFlagged), enmascarando así el número mágico [1]. Entonces obtienes una nueva versión de la función:
Puedes saber fácilmente qué está pasando simplemente cambiando el nombre. Ese es el poder de elegir un buen nombre.
— 02 —
Evitar engañosos
Los programadores deben evitar dejar pistas falsas para ocultar la intención original del código. Se deben evitar palabras que tengan el significado opuesto.
Por ejemplo, hp, aix y sco no deben usarse como nombres de variables, porque todos son nombres propietarios de plataformas Unix o plataformas similares a Unix. Incluso si está escribiendo un programa de cálculo trigonométrico, hp puede parecer una buena abreviatura [2], pero también puede proporcionar información incorrecta.
No utilice accountList para hacer referencia a un grupo de cuentas a menos que sea un tipo de lista real. Las listas de palabras tienen un significado especial para los programadores. Si el contenedor que contiene la cuenta no es una lista real, provocará un juicio erróneo.
Por lo tanto, es mejor usar accountGroup o loteOfAccounts, o incluso usar Cuentas directamente.
Tenga cuidado al utilizar nombres que parezcan similares en apariencia. Por ejemplo, ¿cuánto tiempo se tarda en diferenciar entre un controlador Xyzcontroller que procesa eficientemente una cadena en un lugar y un controlador Xyzcontroller que procesa eficientemente una cadena en otro lugar del módulo? Las formas de estas dos palabras son muy similares.
El mismo concepto escrito de la misma manera es información. La ortografía inconsistente puede dar lugar a malentendidos. Nos gusta la función de finalización automática de código del entorno de programación Java moderno. Escriba las primeras letras del nombre y haga clic en la combinación de teclas de acceso rápido (si está disponible) para obtener una lista de posibles formas del nombre.
Es muy útil si los nombres similares se colocan juntos en orden alfabético y las diferencias son obvias, porque lo más probable es que los programadores no lean sus comentarios detallados o incluso este tipo de comentario Lista de métodos, seleccione un objeto. directamente mirando su nombre.
Un ejemplo terrible de nombre engañoso es el uso de L minúscula y O mayúscula como nombres de variables, especialmente cuando se usan en combinación. El problema, por supuesto, es que se parecen exactamente a las constantes "uno" y "cero".
Los lectores pueden pensar que esto es pura ficción, pero vemos código lleno de esos nombres. En un momento, el autor del código sugirió escribir los nombres de las variables en una fuente diferente para hacerlos más claros, pero solo si esta solución se comunicaba verbalmente y por escrito a todos los futuros desarrolladores. Más tarde, simplemente hacer una simple operación de cambio de nombre resolvió el problema y no causó otros problemas.
— 03 —
Hacer distinciones significativas
Si los programadores escriben código solo para satisfacer las necesidades de un compilador o intérprete, eso es un problema. Por ejemplo, debido a que dos cosas diferentes en el mismo ámbito no pueden tener el mismo nombre, puede cambiar el nombre de una de ellas casualmente y, a veces, simplemente escribirlo mal. El resultado será un error después de que el compilador corrija el error ortográfico.
Simplemente agregar una secuencia o tonterías no es suficiente, incluso si es suficiente para satisfacer al compilador. Si los nombres deben ser diferentes, entonces sus significados también deberían ser diferentes.
Nombrar con una secuencia numérica (a1, a2...aN), que es lo opuesto a nombrar por significado. Un nombre así es puramente engañoso: simplemente no proporciona información correcta ni ninguna pista sobre la intención del autor. Pruébelo:
Esta función sería mejor si los nombres de los parámetros se cambiaran a origen y destino.
La tontería es otra distinción sin sentido. Digamos que tienes una categoría de producto. Si hay otra clase llamada ProductInfo o ProductData, tienen nombres diferentes pero el mismo significado. La información y los datos, como A, an y the, son cosas sin sentido con significados vagos.
Tenga en cuenta que es correcto utilizar los prefijos a y the siempre que reflejen una diferencia significativa. Por ejemplo, puede utilizar para variables de dominio y para parámetros de función [5]. Pero si ya tiene una variable llamada zork y desea llamar a una variable llamada theZork, surgirán problemas.
Tonterías superfluas. La palabra variable no debe aparecer en el nombre de la variable. La palabra tabla no debe aparecer en el nombre de la tabla. ¿NameString es mejor que Name? ¿Podría ser el nombre una carroza? De ser así, se trataría de una infracción de las normas engañosas.
Supongamos que hay una clase llamada Cliente y una clase llamada ClienteObjeto.
¿Cuál es la diferencia entre los dos? ¿Qué método expresa mejor el historial de pagos de un cliente?
Existe una aplicación que refleja esta situación. Por el bien de las partes interesadas, lo cambiamos, pero el código de error es realmente así:
¿Cómo sabe el programador qué función llamar?
Si no hay un acuerdo claro, entonces no hay diferencia entre las variables moneyAmount y money, no hay diferencia entre customerInfo y customer, no hay diferencia entre accountData y account, y no hay diferencia entre Mensaje y mensaje. Para distinguir nombres, distribúyalos de manera que los lectores puedan reconocer la diferencia.
— 04 —
Utiliza nombres fáciles de leer.
Los seres humanos somos buenos recordando y utilizando palabras. Una parte considerable del cerebro se dedica a contener y procesar palabras. Las palabras se pueden leer. Es una pena que un área tan grande del cerebro humano se dedique a procesar el habla, si no se utiliza adecuadamente.
No puedo pronunciar el nombre y me siento como un pájaro estúpido al hablar de él. "Oye, aquí, en la parte superior del cuadro de tres chee enntee hay un número entero llamado Peeess Zee Kyew [7], ¿ves?". Esto no es poca cosa, porque la programación es una actividad social.
Una empresa escribió un genymdhms (día, año, mes, día, hora, minuto, segundo) en el programa, que generalmente se lee como "Gen Why EMM·Di·Aiqi·EMM ESS" [8 ]. Tengo la mala costumbre de deletrear cada palabra, así que digo "gen-yah-mudda-hims" tan pronto como abro la boca.
Muchos diseñadores y analistas siguieron su ejemplo, lo que parecía una tontería. Conocíamos la historia, así que pensamos que era interesante. Es gracioso, pero en realidad es un intento de resistirse a los malos nombres. Al explicar el significado de los nombres de las variables a los nuevos desarrolladores, siempre pronuncian palabras tontas acuñadas en lugar de palabras formales en inglés. Comparar
Ahora se lee como palabras humanas: "¡Hola Mike, mira este registro!". Genera la marca de tiempo[9] configurada para mañana. ¿No puedes hacer esto? "
— 05 —
Utilice nombres que permitan búsquedas
Un problema con los nombres de una sola letra y las constantes numéricas es que pueden ser difíciles de encontrar en texto grande.
Encontrar MAX_CLASSES_PER_STUDENT es fácil, pero encontrar el número 7 es problemático, puede ser parte de algún nombre de archivo u otra definición de constante y aparece en varias expresiones utilizadas para diferentes propósitos si la constante es un número largo. escapará de la búsqueda y provocará un error.
Además, e no es un buen nombre de variable para buscar. Es la letra más utilizada en el idioma inglés y puede aparecer en todos los programas. cada programa. En un fragmento de código se puede ver que los nombres largos son mejores que los nombres cortos, y los nombres buscados son mejores que el código escrito por mí.
Pensé que los nombres de una sola letra lo eran. solo se usa para variables locales en métodos cortos. La longitud del nombre debe corresponder al tamaño de su alcance [N5]. Si es probable que una variable o constante se use en muchos lugares del código, se le debe dar un nombre que sea fácil de buscar. :
Nota. La suma en el código anterior no es un nombre particularmente útil, pero al menos se puede buscar. Usar un nombre que exprese la intención parece alargar el código de la función, pero piénselo. WORK_DAYS_PER_WEEK es mucho más fácil de encontrar que el número 5, en la lista solo nombres que reflejen la intención del autor
— 06 —
Evite la codificación. Ya hay demasiado código, por lo que no hay necesidad de preocuparse. Codificar tipos o rangos en nombres aumenta innecesariamente la carga de decodificación. No hay ninguna razón por la que cada nueva persona deba conocer otro "lenguaje" de codificación además del código con el que está trabajando. con (eso es normal para resolver problemas). Es una carga innecesaria. Los nombres codificados suelen ser difíciles de pronunciar y propensos a errores.
Notación húngara
Cuando la longitud del nombre importaba, rompimos la regla de la codificación innecesaria y ahora nos arrepentimos. El lenguaje Fortran requiere que la primera letra refleje el tipo, lo que conduce al surgimiento de la codificación. Las primeras versiones del lenguaje BASIC permitían sólo una letra más un número. Esta situación se ve agravada por la notación húngara [10] (HN).
En la era de la API del lenguaje C de Windows, HN es muy importante. Todos los nombres en ese momento eran identificadores de números enteros, punteros largos, punteros nulos o una de varias implementaciones de cadena (con diferentes usos y propiedades). En aquel entonces, los compiladores no verificaban los tipos y los programadores necesitaban la notación húngara para ayudarles a recordar los tipos.
Los lenguajes de programación modernos tienen sistemas de tipos más ricos y los compiladores también recuerdan y aplican los tipos. Y los programadores tienden a utilizar clases más pequeñas y métodos más cortos para que la definición de cada variable esté a la vista.
Los programadores de Java no necesitan codificación de tipos porque los objetos están fuertemente tipados y el entorno de edición de código es lo suficientemente avanzado como para detectar errores de tipo antes de que comience la compilación. Por lo tanto, HN y otros tipos de formas de codificación son puramente redundantes en la actualidad. Hacen que sea más difícil modificar el nombre o el tipo de una variable, función o clase, dificultan la lectura del código y crean la posibilidad de que el sistema de codificación engañe al lector.
Prefijo de miembro
No es necesario utilizar el prefijo m_ para representar variables miembro. Las clases y funciones deben ser lo suficientemente pequeñas como para eliminar la necesidad de prefijos de miembros. Debe utilizar un entorno de edición que le permita resaltar o colorear miembros.
Además, las personas aprenden rápidamente a ignorar los prefijos (o sufijos) y solo ven la parte significativa del nombre. Cuanto más código miras, menos prefijos ves. Al final, el prefijo se convirtió en un desperdicio desagradable y en un símbolo de los viejos clásicos.
Interfaces e implementaciones
A veces hay casos especiales en los que se utiliza codificación. Por ejemplo, está creando una fábrica abstracta para crear formas, que es una interfaz implementada por una clase concreta. ¿Cómo nombrar fábricas y clases específicas? ¿IShapeFactory y ShapeFactory? Me gusta la interfaz sencilla. La yo inicial ha sido abusada hasta el punto de ser, en el mejor de los casos, intrusiva y, en el peor, una tontería.
No quiero que los usuarios sepan que les di una interfaz, solo quiero que sepan que esto es un ShapeFactory. Si tuviera que elegir entre una interfaz y una implementación para codificar, preferiría elegir la implementación. ShapeFactoryImp, incluso el feo CShapeFactory, es mejor que el nombre de la interfaz de codificación.
-Fin-
Código limpio
Autor: [US] Robert C. Martin
Traductor: Lei Han
p>Introducción al contenido:
La calidad del software depende no solo de la arquitectura y la gestión del proyecto, sino también de la calidad del código. Esto es algo que tanto los desarrolladores ágiles como los tradicionales deben admitir.
Este libro plantea la idea de que la calidad del código es directamente proporcional a su limpieza. El código limpio es de calidad confiable y sienta una buena base para el mantenimiento y las actualizaciones posteriores. Como líder en el campo de la programación, el autor de este libro proporciona una serie de prácticas efectivas de operación de código limpio. Estas prácticas están incorporadas en este libro como reglas (o "revelación"), complementadas con ejemplos positivos y negativos de proyectos reales. Siempre que siga estas reglas, podrá escribir código limpio, mejorando así de manera efectiva la calidad del código.
Este libro está dirigido a todos los programadores y directores técnicos que estén interesados en mejorar la calidad del código. Las reglas introducidas en el libro provienen de los muchos años de experiencia práctica del autor y cubren muchos aspectos de la programación, desde la denominación hasta la refactorización. Aunque se dice que es "el hogar", tiene un gran valor de referencia.