¿Estás obligado a eliminar el cruft sintáctico?

Question

Cuando se encuentra con el código que no es agradable a la vista, ¿qué tan probable es que lo refactorice? Sé que la estética del código es mayormente subjetiva, pero me molesta mucho el código "feo" y me resulta difícil resistir el impulso de limpiarlo.

No me gusta:

de función pesada anidación

AndFinally(AndThenDoThis(DoThis(strVar, 1, DoThat("February"))), FetchValue(0)) 

Cualquier más un paréntesis, comas y símbolos de unión de los necesarios

CType(ctlGrid.DataSource, DataView).RowFilter = "HourlyRate > 100.00" 

y consideraría la adición de una método (o método de extensión) para obtener

ctlGrid.DataView.RowFilter = "HourlyRate > 100.00" 

alternativamente, que cambiaría:

rows = tblEmp.Select("AnnualEarnings > " & dEarnings.ToString & " AND Position = '" & strPosition & "'") 

a esto:

rows = tblEmp.Select("AnnualEarnings > ? AND Position = ?", dEarnings, strPosition) 

Ahora bien, esto es un poco extremo, pero incluso me tomará un idioma común, como encontrar el primer elemento en una matriz y proporcionar un método para ello:

row = tblEmps.Select("Position = 'Manager'")(0) 

ser viene (y, creo, es más fácil de leer):

row = tblEmps.Select("Position = 'Manager'").First 

Cuando veo esto me vuelve loca

frmMain.grdEmployees.colName.Bold = True 
frmMain.grdEmployees.colName.Font = "Arial" 
frmMain.grdEmployees.colName.BackColor = "lightyellow" 

y, con respecto a lo que me resulta más fácil de leer, termino hasta con:

With frmMain.grdEmployees.colName 
    .Bold = True 
    .Font = "Arial" 
    .BackColor = "lightyellow" 
End With 

Podría seguir y seguir con este tipo de cosas. Ejerzo gran cuidado para que la refactorización solo ocasionalmente resulte en la introducción de un error, por lo general de corta duración y bajo impacto.

No todos en nuestra compañía están de acuerdo con este tipo de cosas, pero creo que es una gran ayuda para el mantenimiento a largo plazo. Leí "Don't Make Me Think "de Steve Krug hace unos años. Diría que este libro (aunque está orientado al diseño web) favorece el código escrito de tal manera que minimiza el esfuerzo mental necesario para digerirlo. En la mayoría de los casos, para mí, esto significa expresar el mismo código en menos líneas, pero nunca de una manera engañosa y ofuscante.

¿Qué tan motivado está para mejorar la estética de los códigos? ¿Cuándo se va suficientemente solo y qué tipo de "fealdad" lo obliga a dar un paso? en? ¿se considera que esta práctica más beneficiosa o más perjudicial?

Answer 1

Para mí, lo más importante no es la estética, sino si alguien más puede entender el código más tarde.

Las llamadas a funciones anidadas suelen ser un no-no, porque la carga cognitiva de comprender toda la expresión se vuelve alta. Y podría haber efectos secundarios en las llamadas anidadas, que empeoran las cosas. Por lo tanto, es bueno romper el agrupamiento e introducir variables temporales, también porque puede escribir comentarios en el código y explicar de qué se tratan los resultados intermedios.

Introducir una nueva notación para trivialidades (como su ejemplo (0) frente a .Primero) no es bueno, porque no mejora la comprensión: está creando una nueva abstracción o concepto sin valor agregado. ¿Por qué escribir i.addOne() si puedes hacerlo con i ++? Todo el mundo sabe de qué se trata "++", pero no podían saber qué hace addOne() sin leer su documentación. Entonces es solo una forma de agregar carga cognitiva.

Usted se refiere a la refactorización, pero refactorizar no significa simplemente cambiar el diseño del código y la estética, sino también cambios estructurales en todo el programa. Continuando con su ejemplo, las llamadas a funciones anidadas f (x (y (z (q)))) pueden indicar la necesidad de refactorizar más allá de la estética: averiguar por qué son necesarias las llamadas anidadas y luego empaquetarlas en una nueva abstracción . Por supuesto, la refactorización también podría consistir en cambiar el modelo completo de objetos, un gran esfuerzo.

Answer 2

en la mayoría de las organizaciones, hay una pauta establecida por el estilo.

Answer 3

tiene sentido.

Voy a utilizar esto como un ejemplo.
firstManagerow = tblEmps.Select("Position = 'Manager'").First

Es mejor definir las variables en los lugares, donde será mejor usarlas en la depuración.

Esto podría convertirse en un método con un nombre descriptivo apropiado.

rows = tblEmp.Select("AnnualEarnings > " & dEarnings.ToString & " AND Position = '" & strPosition & "'")

Answer 4

que tratan de deshacerse de esas cosas feas aswell, ReSharper me ayuda mucho en el desarrollo de aplicaciones .NET que me diera pistas sobre inicializadores de objeto, por ejemplo.

También puede configurar su IDE para configurar las reglas de formato de código fuente adecuadas que usted y su equipo deberían usar. Esto no elimina las situaciones en las que desea ver formateadores de cadenas o quizás algunas líneas adicionales, pero creo que ayudará mucho. Por lo demás, hay reafilamiento :).

Answer 5

Cuando comencé a programar, cada línea de código que vi me obligaba a editarla. Mirando hacia atrás, perdí mucho tiempo en eso. En estos días, todavía arreglo lo que considero que es un código feo, pero solo cuando está en un archivo que estoy cambiando por razones prácticas.

Evite la tentación de editar una base de código completa por motivos estilísticos.

Answer 6

Estoy a favor de la estética del código, pero la necesidad de cambiar el código existente, especialmente si es código de trabajo, debe resistirse tanto como sea posible. Las pautas para el estilo del código deben establecerse y aplicarse, pero el código existente debe tratarse con cuidado: es muy fácil cambiar realmente cómo se comporta el código.

Answer 7

Aunque he leído en bastantes libros sobre el uso de nombres de variables descriptivas, cuando escribo una función corta que funciona con solo unas pocas variables, por lo general opto por nombres cortos (incluso genéricos). Los nombres largos y descriptivos pueden consumir una gran cantidad de bienes inmuebles visuales y, para funciones básicas, lo considero excesivo. Si las funciones básicas crecen para abarcar complejidad adicional y se introducen más variables, expandiré los nombres para mejorar la claridad.

For i As Integer = 0 To tblEmps.Rows.Count - 1 
    Console.WriteLine(tblEmps.Rows(i)("Name")) 
Next 

veo ninguna razón por la i debería ser más descriptivo.

Answer 8

Hay muchas posibles respuestas contradictorias a esta derivada de diversas consideraciones, pero muchos de sus ejemplos son cuestiones de estilo para los que puede diferir opinión ...

• ¿Existe un estándar establecido? Si es así, ¿existe una cultura establecida para refaccionar el código existente y asegurarse de que el desarrollador que lo escribió esté al tanto? Si no, te arriesgas a ofender el sentido del estilo de otra persona y entrar en una guerra de edición. Si no hay un preventivo (en forma de estándares y revisiones), entonces hay preguntas más importantes que si debe "arreglarlo".
• ¿Hay alguna repetición que se adapte a la refactorización? Introducir un método para manejar un solo caso simple no siempre es apropiado
• ¿Está trabajando en ese código o solo lo está usando? Si no necesita ensuciarse las manos y el código funciona, considere dejarlo solo.
• ¿Estás escribiendo potencialmente más código e introduciendo más complejidad en aras de la estética? Introducir demasiados métodos nuevos puede ser tan confuso como muchos paréntesis anidados.

El equipo con el que trabajo tiene discusiones regulares en cuestiones de estilo, y algunas veces acordamos un estándar, pero a menudo en asuntos de menor importancia reconocemos que es mejor estar de acuerdo en desacuerdo y ser cortés en evitar ediciones drásticas donde solo se involucra una diferencia de opinión.

En última instancia, el costo de tiempo y riesgo de todas estas ediciones se suma y debe sopesarse contra el tiempo más productivamente utilizado.

Answer 9

Solo refactorice si necesita suponer que se trata de una empresa comercial. Su ejemplo de jerarquización de funciones pesadas sería cuando la eliminación de errores en varias líneas hace la vida mucho más fácil. Deshacerse de los paréntesis es mucho más fácil cometer errores. Sí, podría verse mejor, pero lo bueno realmente no es más legible/mejor. Es simplemente más en el estilo que estás acostumbrado a ver.

Answer 10

tengo la sensación de dos cuestiones distintas aquí:

1. debería escribir refactorizar para mejorar la claridad?
2. ¿Se debería refactorizar el código por ninguna otra razón que para mejorar la claridad?

En mi opinión, la respuesta a la primera pregunta suele ser "sí". Todo el código debería, idealmente, ser más o menos autodocumentado. Menos tiempo dedicado a intentar comprender el código significa que hay más tiempo disponible para gastar y corregir cuando falla. Cuando te sumerges en el código para arreglar algo, puede valer la pena esforzarte por aclarar cualquier cosa que te haga rascarte la cabeza.

Pero eso nos lleva a esa segunda pregunta sutilmente peligrosa. "Cuando te sumerges en el código para arreglar algo" es por mucho la parte más significativa de esa declaración. Si no tiene ningún motivo para cambiar algo más que para facilitar la lectura, ¡por favor, cierre su editor!

La refactorización prematura debe tratarse como una optimización prematura, y por las mismas razones. Cuando se trata de eso, los errores vienen del código. Cuanta más codificación hagas, más errores generarás. Si tiene un código que, según su leal saber y entender, no contiene ningún error, no tiene a dónde ir excepto cuesta abajo. Usted puede no introduzca ninguno, pero ciertamente no lo hará si no lo toca! Al refaccionar, aclarar, reorganizar o cambiar el código que funciona actualmente según lo previsto, usted (y su empleador) están haciendo un flaco servicio al incurrir en un riesgo garantizado de un beneficio teórico.

Si ya estás allí por alguna otra razón, adelante y hazlo más fácil para ti o para quien vaga por ese camino después de ti. Pero nunca refactoriza código de trabajo, incluso si se verá más bonito después.

Answer 11

Puede hacer que "la función pesada de anidación" mucho mejor simplemente cambiando el formato, alineando las partes del mismo nivel de anidamiento en la misma columna, por ejemplo:

AndFinally (AndThenDoThis 
      (DoThis (strVar, 
         1, 
         DoThat("February"))), 
      FetchValue(0)) 

De esta manera, la "limpieza" no puede causar errores (a menos que la sintaxis de su idioma sea sensible al espacio en blanco), y el flujo de todo el asunto realmente se vuelve claro.

Answer 12

La belleza está en el ojo del espectador.

Estoy seguro de que hay personas que volverán a configurar su código porque piensan que no es bonito. ¿Qué harás entonces? ¿Refactorizarlo de nuevo? Terminarás en un círculo vicioso.

Así que por favor resista la tentación de refactorizar código solo porque su código es más bonito.

Answer 13

Tenía un compañero de trabajo (que ya no estaba con nosotros) que continuamente 'arreglaba' el código feo. El problema fue que invariablemente lo rompió, e invariablemente lo hizo feo de alguna otra manera. Un día una clase tendría una mano llena de métodos de 10 o 20 líneas de longitud, al día siguiente tendría 30 métodos de una o dos líneas de longitud, y al menos uno de los comportamientos de las clases sería malo.

Si no está roto, no lo arregles.