coding style - guides - Aplicación de un estilo de codificación
google style guides (8)
Hace años, cuando comencé un pequeño proyecto de desarrollo, los otros desarrolladores y yo nos sentamos y acordamos un estilo de corchete y sangría de compromiso. No era el favorito de nadie, pero era algo que realmente nadie odiaba. Escribí un archivo de configuración .indentrc a ese estilo, y tenía un disparador de check-in que ejecutaba sangría en cada archivo cuando estaba siendo registrado. Eso lo hacía para que no importara en qué estilo escribes tu código, terminaría siendo el estándar del grupo antes de que nadie más lo viera. Esto tenía la ventaja de la consistencia. Pero nunca he visto a nadie más hacerlo de esta manera antes o después.
Entonces, ¿qué dicen el resto de ustedes? ¿Gran idea o abominación?
Eso suena como una buena idea. Siempre que el estilo con el que termines no sea algo completamente extraño, esa es una buena forma de asegurarte de que tus desarrolladores usen el estilo. Y tiene el beneficio adicional de que no tienen que codificar de esa manera; se reformateará cuando comprueben sus cambios. Sería bueno tener una herramienta como esa disponible que pueda conectar a su CVS (término genérico).
Si lo limitaste a imponer el estilo sobre los frenillos y la sangría, entonces creo que es una buena idea. Sin embargo, si intentara aplicar cada uno de los estándares de formato, probablemente no lo haría. En mi opinión, hay momentos en los que tiene sentido romper el estándar. Por ejemplo, prefiero
int x = y * z;
a
int x = y*z;
porque es más fácil de leer Sin embargo, yo prefiero mucho
int a = b*c + d*e;
a
int a = b * c + d * e;
porque el espacio representa el orden de las operaciones.
Por lo tanto, su política de imposición de sangrías y llaves parece realmente buena. Pero si alguien alguna vez intentó aplicar ciegamente otras reglas de espaciado, no creo que funcione bien.
Usamos TFS con una política de registro que ejecuta un conjunto de reglas de Stylecop. Si su código no se aprueba, no puede verificarlo. Funciona muy bien. Además de un estilo constante y buenos comentarios en todo momento, también parece haber aumentado la calidad general del código, tal vez porque el desarrollador se ve obligado a describir qué método, evento, etc. se ve obligado a pensar en el código antes de comprobarlo. en.
Solo una solución MS, pero vale la pena si está disponible para ti.
Yo diría que es una buena idea. Daría un paso más y haría que todos usen el archivo de configuración en su IDE para que escriban en el estilo acordado de manera predeterminada. Si van a tener que mirar el código de todos los demás en el estilo neutral, es mejor que se acostumbren. Incluso su propio código debe estar en el estilo neutral después de un ciclo de check-in check-out, entonces, ¿por qué desarrollar un nuevo código en su propio estilo personal?
El mayor problema con el uso de formateadores de código automáticos es cuando el formateador de código no puede manejar todos los escenarios.
Por ejemplo, si tiene muchos SQL en su código, probablemente formatee el SQL automáticamente. Pero si su SQL es más largo que una línea (¿por cuánto tiempo es una línea, de todos modos?), Entonces tiene que formatearlo. Hasta ahora, aún no he visto un buen formateador que pueda manejarlo correctamente.
Ejemplo:
String sql = "SELECT * FROM USERS WHERE ID = ? AND NAME = ? AND IS_DELETED = ''N''";
vs
String sql =
"SELECT * " +
"FROM USERS " +
"WHERE ID = ? " +
" AND NAME = ? " +
" AND IS_DELETED = ''N''";
El segundo formato es más legible cuando tienes consultas realmente largas. La mayoría de los formateadores lo formatearán en una línea larga hasta la longitud de línea.
Sin embargo, si todo lo que estás haciendo es girar
if(x=1) print("blah"); else print("eep!");
dentro
if (x = 1) {
print("blah");
} else {
print("eep!");
}
entonces el formateador está bien. Hacemos algo similar en el trabajo; no es aplicado por la herramienta CVS sino por el IDE. Funciona razonablemente bien.
Creo que ya has decidido tu entorno de desarrollo. Si usa Eclipse, puede habilitar la acción Guardar formato de fuente en el editor de Java, que reformatea cada vez que lo guarde. El principal beneficio de esto es que las oportunidades de origen están marcadas en el repositorio de origen en el momento en que se realizaron, no cuando la fuente se formateó más tarde.
Hazlo un paso automático. Lo apreciarás más tarde.
Hay un proyecto llamado EditorConfig que de alguna manera puede resolver el problema. Sin embargo, actualmente solo resuelve problemas de sangría.
EditorConfig contiene complementos para muchos editores diferentes y un formato de archivo estándar. Al crear un archivo .editorconfig en la raíz de su proyecto e instalar el complemento correspondiente, el editor formateará su código cuando los escriba.
Esta es una forma general (a diferencia de indentrc , no se limita a C / C ++), pero aún puede echarle un vistazo a esta solución.
Adoptar un estilo de codificación neutral definitivamente es una buena idea. Sin embargo, solo aplicar el estilo de codificación cuando la fuente está marcada puede o no ser una buena idea (ver también las respuestas de Bill y Elie a continuación).
Usando el gancho de check-in:
Pro: permite que los codificadores escriban como lo deseen, para que no tengan que pensar en el estándar ni cambiar la forma en que escriben el código. Esto minimiza la resistencia a la política y no afectará negativamente su productividad al escribir el código.
Con: Sus programadores pueden tener solo una familiaridad con el estilo neutral, por lo que no obtendrás el beneficio completo de que todos usen el "mismo" estilo. Si los programadores alguna vez tienen que trabajar juntos en una configuración de programación de pares, todavía estarán sujetos al estilo de programación de los demás en la pantalla, que será diferente de su propio estilo o el estilo neutral.
Yendo un paso más allá, usando el estilo neutral durante el desarrollo:
Pro: fomenta la fluidez en el estilo neutral, todos pueden leer el código de todos los demás antes y después de que se registre.
Con: encontrará más resistencia de sus desarrolladores haciéndolo de esta manera. Dependiendo de su cultura, podría ser más problemático de lo que vale.