c# - net - remarks/>
Estilo de codificación de C#- longitud de línea/líneas de ajuste (6)
¿El ajuste de línea ayuda con la legibilidad del código?
¿Existe una etiqueta generalmente aceptada para el uso de continuaciones de línea?
Por qué usar esto:
SomeMethod(int someInt, Object someObject,
String someString, bool someBool)
{
...
}
En lugar de esto:
SomeMethod(int someInt, Object someObject, String someString, bool someBool)
{
...
}
Edición: reformuló mi pregunta desde la continuación de la línea hasta el ajuste de línea
Ahora que hemos aclarado que esto no tiene que ver con los caracteres de continuación de línea reales y simplemente el ajuste de línea, me lo dices. Esta:
IEnumerable<int> orderIDs = context.Customers.Where(c => c.CustomerID >= 1 && c.CustomerID <= 10).Select(c => c.Orders).SelectMany(o => o).OrderBy(o => o.OrderDate).Select(o => o.OrderID);
¿O esto?
IEnumerable<int> orderIDs = context
.Customers
.Where(c => c.CustomerID >= 1 && c.CustomerID <= 10)
.Select(c => c.Orders)
.SelectMany(o => o)
.OrderBy(o => o.OrderDate)
.Select(o => o.OrderID);
¿Cuál preferirías leer?
Creo que el límite de longitud de la línea se ha ido alargando (o desapareciendo) gradualmente en los últimos años, ya que todos tienen monitores de pantalla ancha de alta resolución y rara vez imprimen el código. Ninguno de los proyectos en los que he trabajado tiene una directriz oficial, solo usamos el sentido común y el salto de línea en aproximadamente el ancho de una ventana del editor (todos usan el mismo diseño básico de la ventana de Eclipse con aproximadamente la misma resolución). No veo problemas con este método.
Estoy a favor de romper líneas en puntos lógicos. El motivo es ayudar con el código fuente a controlar las funciones de diferenciación y fusión. Descubrí que comprender los cambios en este entorno es mucho más fácil si las declaraciones con muchos elementos se dividen en varias líneas.
Los monitores son grandes. Pero puede encontrarse trabajando en una computadora portátil y realizando una combinación en la que tiene ramas base, fuente y destino en ventanas separadas en la pantalla. Cuente los caracteres: cada una de estas ventanas en una computadora portátil de 17 pulgadas tiene solo unos 55 caracteres de ancho.
Si está trabajando de forma remota, descubrirá que el desplazamiento horizontal no está bien optimizado, y puede que piense en algunos reproches sobre los programadores que escriben funciones con 15 parámetros en una sola línea.
Así que piense en TODAS las formas en que debe trabajar en el código fuente y rompa líneas en lugares que satisfagan TODAS sus necesidades.
Hace algunos años leí las Mejores Prácticas de Perl de Damian Conway. Aquí hay un enlace a continuación
Perl Best Pracices en Google Books
Hay un capítulo entero que trata del diseño de código . Todos mis sentimientos sobre el diseño del código se resumen en sus escritos. Recomiendo encarecidamente ese capítulo. Se puede aplicar fácilmente a C #.
He estado tratando de seguir sus reglas para cualquier idioma que esté usando: C #, Java, Perl, JavaScript, VBScript, VB, PHP, ...
En este libro, Conway sugiere usar líneas de 78 columnas. Debo admitir que rompí la regla y me quedé con el 80, pero creo que está bien.
He integrado esta regla a cada editor que uso (Notepad ++, Komodo, Vi, Vim, Visual Studio 2005) para tener una guía visual que muestre este límite.
Algunos de ustedes podrían preguntarse cómo mostrar una guía en VS, ¿eh?
Bueno, me pareció que no era tan obvio. De hecho, debe crear un parámetro de cadena en el registro. Aquí hay una publicación que encontré en SO al respecto. Espero eso ayude.
Personalmente, me gusta poder "ver" todo. Por otra parte, tengo un monitor bastante decente. Pero en serio, me gustan las funciones bonitas y pequeñas frente a las funciones gigantescas con declaraciones "si" anidadas. Lo mismo con unas líneas de código.
Al final del día, todo depende de las preferencias personales y de lo que decidan usted y los miembros de su equipo. Se consistente. Y favorece la legibilidad para el siguiente tipo que mira tu código.
Las continuaciones de línea no se utilizan en C #, ya que se requiere un terminador de línea explícito ( ; ).
Si está preguntando, en términos de estilo, si es una buena idea dividir una línea en varias líneas, eso es discutible. Las reglas de StyleCop obligan a que una línea se defina en una sola línea o que cada elemento esté en una línea separada. Personalmente creo que esta es una buena guía, y generalmente elijo dividir una línea completamente en sus partes si es demasiado larga para que quepa en un buen editor de 80-90 caracteres.
Editar en respuesta a su nueva pregunta:
En este caso, me gustaría seguir las directrices anteriores. Personalmente, en su caso específico, dejaría esto en una línea:
SomeMethod(int someInt, Object someObject, String someString, bool someBool)
{
...
}
Esta es una declaración de método agradable y breve, y no veo ninguna razón para dividirla. Solo lo dividiría si la cantidad de argumentos y las longitudes de los tipos se volvieran demasiado largas para una línea de texto.
Sin embargo, si lo divides, lo dividiré en líneas separadas para cada argumento:
SomeMethod(
int someInt,
Object someObject,
String someString,
bool someBool)
{
...
}
De esta manera, al menos es obvio cómo y por qué se divide, y un desarrollador no saltará accidentalmente un argumento ya que dos están en una sola línea.