¿Qué tan estricto debe ser con respecto a la sangría / espacio en blanco? [cerrado]


8

Nuestro proceso de desarrollo es el siguiente

codifique la tarea -> el código y la documentación de QA de otra persona -> la tarea se fusiona en el tronco.

Recientemente, un colega se niega a pasar el código de control de calidad debido a problemas con la sangría y los espacios en blanco.

Aquí hay ejemplos de estos problemas (la sintaxis es SAS):

Espacio en blanco adicional:

        %if &syserr gt 0 %then %goto err; /*last line of code*/




/* Footer area*/

Línea adicional de espacio en blanco, y sin sangría dentro del proceso de clasificación:

 /* End Of header * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */


    proc sort data = %dataset ;
    by id; 
    run;
    %if &syserr gt 0 %then %goto err; 

    proc sort data = &second_dataset.;
    by id;
    run; 
    %if &syserr gt 0 %then %goto err; 

Espacio en blanco adicional entre pasos:

        /*join all details on for each record*/
        proc sort data = &data out = data_srt ; 
              by &conditions; 
        run;
        %if &syserr gt 0 %then %goto err;

        proc sort data = &data2.;
              by &conditions.;
        run; 
        %if &syserr gt 0 %then %goto err; 




        /*cartesian join*/
        data new_data;
              join data 
                          &data2.  ;
              by &conditions; 

        run;

La pregunta es, al ser un buen programador, ¿está revisando su código y corrigiendo todo este tipo de cosas lo correcto, o es simplemente ridículo?

Existe una complicación adicional, que debido a que no tenemos una integración continua o pruebas automatizadas, no es posible que el QAer solucione rápidamente estos problemas y confirme el código, por el riesgo de eliminar el punto y coma accidentalmente o algo así. (Para ser justos, el riesgo se aplica al desarrollador inicial que realiza estos cambios, por lo que, de cualquier manera, si se produce este error, solo debe repararse y seguir adelante).


1
No sé SAS pero el espacio en blanco extra es bastante anal. La sangría me parece un punto justo.
Erik Reppen el

@ErikReppen Por otro lado, esos ejemplos tienen 4 líneas en blanco entre segmentos de código. Eso es un poco excesivo ...
Izkata

Respuestas:


16

Sí, esa es la respuesta correcta. El estilo de sangría debe ser coherente para todo el código.

Una gran parte del valor de la sangría consistente es que es consistente. De esa forma, la gente aprende a leerlo fácilmente, lo que acelera a todos.

Mi regla general es que cualquier estilo de sangría que el equipo quiera es bueno, siempre que pueda aplicarse mecánicamente. Aplicarlo mecánicamente significa que no tiene que aprender los detalles del estándar, ni perder el tiempo haciendo espacios en blanco.

El formateo mecánico también se convierte en otra forma en que se destacan los errores. Si cree que ha encerrado el código en un bloque, la herramienta de formato lo desangrará y será obvio que se equivocó. Esto también facilita la refactorización: en el nivel trivial cuando extrae un bloque de código a una función, autoformato eliminará la sangría adicional.

Autoformato también significa que si realmente no puede vivir con el estándar que todos los demás usan, puede formatear el código de la manera que desee, luego formatearlo de nuevo antes de ingresarlo. Dado que tiene un paso de revisión, obviamente hazlo antes de la revisión y si no lo hicieras, sería recogido entonces.

GNU indent es una herramienta que se puede hacer para autoformar casi cualquier cosa. Hice una búsqueda rápida y parece que existen herramientas para formatear automáticamente el código SAS, pero las herramientas SAS no lo hacen por usted.


66
+1 por usar la herramienta. Es un poco ridículo arreglarlo a mano cuando solo puedes ejecutar una herramienta en commit hook.
imel96

1
@ imel96 A veces hay espacios en blanco intencionales para facilitar la legibilidad, que una herramienta automática arruinará. Por lo tanto, debe ser opcional, algo que puede activar cuando lo desee, no forzado con cada confirmación.
Izkata

@Izkata: Todavía no he visto una herramienta de formateo que no tenga un código de "no formatear este bit" que pueda usar. Pero también he pasado bastante tiempo desde la última vez que quise deshabilitar el autoformato. Admito usar ocasionalmente construcciones de código ligeramente extrañas para obtener el formato que quiero (condicionales multilínea con "si es verdadero y" en la primera línea, por ejemplo). Pero el condicional multilínea es un código de olor en sí mismo, por lo que agregar un poco para que sea menos ilegible es bastante IMO.
Más

@Izkata, el problema al hacer que la herramienta sea opcional es que tan pronto como una persona opte por un archivo, nadie más podrá volver a ejecutar la herramienta en ese archivo o romperán el código "no formatear este archivo". Lo que significa que deberían moverle ese archivo y decirle "arregle el formato". Cada vez que se modifica. Entonces no, opcional no funciona. Debe usar los códigos sin formato alrededor de sus bloques especiales de código / comentario.
Más

@ Ӎσᶎ Entonces arreglas la sangría que es realmente mala. No lo ejecutes a ciegas en todo el archivo. vim , por ejemplo, le permite seleccionar un fragmento del archivo y reindentizarlo automáticamente, ignorando el resto del archivo.
Izkata

5

Esto es absolutamente lo correcto. Una de las partes más importantes de la calidad del código es su legibilidad. Si no ha sangrado su código correctamente y tiene espacios en blanco al azar en todas partes, esto reduce la legibilidad del código.

En general, su equipo de desarrollo debe seguir los mismos estándares de calidad de código cuando se trata de sangría y espacios en blanco. Si otros módulos en su base de código no ponen espacios en blanco adicionales entre los pasos, este tampoco debería (a menos que, por supuesto, mejore la legibilidad).

No soy un programador de SAS, pero si estoy revisando el código y la sangría está fuera de control y no parece ordenada, ciertamente lo comento para el seguimiento y, si es realmente malo, no apruebo la revisión.


3

Como dice el tío Bob en su libro , el formato (incluso el espacio en blanco) es increíblemente importante. El software tiende a leerse con mucha más frecuencia que la escritura, por lo que nos corresponde hacerlo limpio y fácil de leer. Es un método de comunicación.

Idealmente, cuando trabajas en equipo, determinarás un estándar y todos lo seguirán. Idealmente, en lugar de marcar el estándar en las revisiones de códigos individuales, configure una herramienta que haga el trabajo por usted. (No estoy seguro de qué herramienta funcionaría para su caso; algo como checkstyle para Java o StyleCop para C #).

Así que chatearé con tu colega y veré si no puedes encontrar algunas pautas sobre el espacio en blanco. Vale la pena tomarse un par de minutos para limpiar su código si hace que las cosas sean consistentes en el futuro.


2

Después de una experiencia hace muchos años, leyendo un código F-16C / D donde se rompió la sangría, tengo que decir que obtener la sangría correcta es críticamente importante.

Es tan importante que no debe hacerse a mano y no debe arreglarse a mano. Para eso están las computadoras.

Hacen programas de computadora que pueden reformatear automáticamente el código fuente para que coincida con el estilo preferido de su empresa. Conecte uno de ellos a su sistema de control de código fuente, para que el código se cumpla automáticamente cada vez que se registre.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.