coding-style - general - coding styles
Estándar de formato de ancho de línea (10)
¿Sigues un estándar para envolver líneas largas en el código fuente? ¿Qué longitud de línea le resulta más cómoda de leer?
A veces encuentro personas que programan en monitores de pantalla ancha y les gusta utilizar todo su ancho para mostrar el código fuente. Prefiero las líneas más cortas, alrededor de 80-100 caracteres, pero me es difícil tratar de convencer a mis colegas con la popularidad cada vez mayor de los dispositivos de pantalla ancha.
Editar:
Preguntas similares:
Aparentemente tengo líneas de hasta 258 caracteres de longitud (contando pestañas como dos caracteres) en uno de mis proyectos recientes, así que ahí está mi respuesta. =)
Me atengo a la regla de las 80 líneas (y trato de convencer a todos a hacer lo mismo). Algunas razones:
- Puede abrir 2 (o más) editores a la vez.
- Lo mismo con las herramientas de comparación. - la mayoría (¿todos?) muestran los dos (algunos tres (¿algunos más?)) archivos uno al lado del otro.
- A veces es necesario trabajar desde un lugar remoto, en una estación de trabajo diferente o en una computadora portátil, y de repente, su código de 120 carácteres a líneas muy formateado se ve horrible.
No debería tener que desplazarse horizontalmente para leer el código. ¡Pero pantallas más grandes no significan líneas más largas! También hay un límite de cuánto debe continuar en una sola línea.
Entonces digo: mantenlo a 70-80 caracteres como siempre. Las pantallas más grandes solo significan que el IDE tiene más espacio.
Prefiero las líneas más largas por una simple razón: puedo incluir más código en mi ventana. Hay una gran diferencia entre tener que desplazarse verticalmente para leer una función y poder encajarla en una sola pantalla. Si todo está en línea, de modo que la función se desplace por la parte inferior mientras que la mitad derecha de la pantalla está vacía, considero que es una gran pérdida. Tenga en cuenta que abrir dos ventanas de editor tampoco ayuda aquí.
Programo casi exclusivamente en una computadora portátil, así que estoy de acuerdo con las líneas más cortas. Por supuesto, normalmente estoy diseñando pantallas para PDA, por lo que puedo salirse con la tuya. Pero si el código se comparte entre desarrolladores, terminará en la computadora portátil de alguien eventualmente, y las barras de desplazamiento me hacen llorar.
También depende de otras convenciones que estés usando. En un trabajo, estábamos programando en Java y la convención era usar identificadores largos y descriptivos, lo que significaba que solo un par de ellos podía caber en una línea sin toparse con el límite de 80 caracteres. Pensé que era bastante estúpido teniendo en cuenta que a cada desarrollador de la compañía se le había proporcionado un monitor de pantalla panorámica que podía caber fácilmente 200 caracteres. Con la consistencia del hardware así, no tiene sentido imponer un límite de línea estúpidamente pequeño.
Utilizamos un estándar de codificación de 80 caracteres en línea. La razón original para la limitación de 80 caracteres no es relevante hoy en día, pero se debe elegir un número ...
Además de lo obvio (organización del código y legibilidad), generalmente descubrí que las líneas largas son el resultado de un estilo incorrecto y que dicha regla mejora la calidad del código y reduce los errores. Simplemente compare los siguientes ejemplos:
status = do_something();
if (status == error)
{
do_error_handling();
return;
}
/* do you regular flow */
status = do_more();
if (status == error)
{
do_error_handling();
return;
}
/* do more of you regular flow and keep you line 80 chars*/
en cambio
status = do_something();
if (status == succes)
{
/* do you regular flow */
status = do_more();
if (status == success)
{
/* do you regular flow */
/* nest again and get line behind visible screen */
}
else
{
/* do error handling */
}
}
else
{
/* do error handling */
}
El segundo ejemplo es mucho menos legible de mantener y probablemente genere algún problema en el camino ...
Editar
Se reemplazó goto con do_error_handling() en el código para evitar discusiones no relevantes.
Como mencioné antes de los 80 caracteres que no son relevantes hoy en día, solo un número 100 es bueno también.
Para cualquiera que encuentre el segundo ejemplo más legible anótelo algunas veces más con código real e intente leer de nuevo :)
Utilizo alrededor de 72-75 columnas para asegurarme de que puedo imprimir el código en páginas con formato de carta sin demasiados problemas. También uso espacios en lugar de pestañas y soy cuidadoso con el diseño.
Para notar cuando estoy saliendo del margen derecho, a menudo pongo una línea de texto que puedo usar como regla. Configuro la ventana de visualización IDE para que la regla se ajuste al ancho horizontal y luego me aseguro de no salir de ella.
Lo hago en documentos .txt, así como .c, .java, .cpp, archivos por lotes, etc. Esto hace que sea más fácil enviar fragmentos en el correo electrónico, publicar en blogs, poner comentarios, etc. La regla es a menudo justo debajo de una línea superior que identifica el archivo y el formato del texto:
/* example.txt 0.00 UTF-8 dh:2008-11-09
*---|----1----|----2----|----3----|----4----|----5----|----6----|----7----*
*/
Por supuesto, se usa la convención de comentarios del tipo particular de archivo.
Pantalla más grande - Fuente más grande. Uso Conslas con Conslas 14pt maximizado a una resolución de pantalla de 1280x800. Intento abarcar aproximadamente el 80-90% de ancho de pantalla.
No comprometa la legibilidad de las reglas dogmáticas sobre el número exacto de caracteres en una fila. El desplazamiento horizontal no es deseable, pero una línea de 81 caracteres es más fácil de leer que una indentación: una versión envolvente.
Es probable que 80 caracteres no sean adecuados para programar estilos con sangrías grandes y / o nombres de variables detallados. Mantenga la cantidad de complejidad lógica hasta un máximo por línea, no la cantidad de caracteres.