formatting - resetear - ¿Cuál es la forma correcta de formatear el código?
resetear ps3 de fabrica (22)
Uno de los maestros que tuve, bajó la calificación de uno de mis trabajos porque había espaciado mi código lógicamente. Dijo: ''Cuando tenga que leer el código todo el día en el mundo real, no tendrá este espacio entre líneas y me lo agradecerá ".
A menos que estés separando bloques con 5 o 10 líneas de espacio en blanco (lo que volvería loco a cualquiera), tu instructor es solo ser un imbécil.
Los estándares de codificación no están grabados en piedra, y ciertamente no son los mismos para todas las tiendas de software. Todas las empresas tienen diferentes estándares de codificación. Para su valor, algunos de los estándares de codificación en mi empresa establecen explícitamente "bloques de código relacionados visualmente separados visualmente con una sola línea en blanco".
Aunque deberíamos esforzarnos por no escribir métodos largos de 200 líneas, es muy común que todos nuestros métodos cortos contengan más de un elemento de flujo de control, y debemos entender que el espacio en blanco vertical es tan importante como el espacio en blanco horizontal en la legibilidad. Puede satisfacer el principio de "método único, propósito único" incluso si coloca una línea en blanco entre un bucle for y una sentencia if en el mismo método.
[Editar para agregar] Y solo algunos comentarios más:
1) Es muy presuntuoso que varias personas en este hilo estén asumiendo que el OP está escribiendo métodos de 200 líneas, o que existe una correlación necesaria entre agregar líneas en blanco y escribir métodos descuidados.
2) Por su valor, mientras que el instructor del OP está absolutamente equivocado al suponer que sus estándares de codificación son los mismos en todas partes. Sin embargo, debe tratar el curso de programación como su propia pequeña tienda de software con sus propios estándares, por lo que su código debe escribirse de una manera que siga esos estándares.
Si su instructor lo está calificando en función de qué tan bien se ajusta su código a los estándares de codificación, insista en obtener una lista de estándares. Sé que mi calificación fue acoplada porque no se ajustaba a las normas que el instructor nunca me había dado (o si sus normas dicen "variables de prefijo con su tipo de datos"), las cabezas estarían en movimiento.
Cuando escribo código, trato de agrupar líneas de código similar, luego dejo una línea en blanco y escribo otro bloque.
Creo que esto contribuye a la pulcritud y legibilidad del código.
No soy un gran fanático de agrupar cosas sin ningún espacio entre líneas. Parece un infierno, es difícil de leer y es difícil de seguir.
Uno de los maestros que tuve, bajó la calificación de uno de mis trabajos porque había espaciado mi código lógicamente. Dijo: ''Cuando tienes que leer el código todo el día en el mundo real, no vas a poner este espacio entre líneas y me lo agradecerás ". Por supuesto, nunca lo hice y nunca lo agradeceré.
Ahora que estoy en el mundo real, la mayoría de los archivos de código que veo que no tienen absolutamente ningún interlineado están mal escritos y mal pensados.
Probablemente sea más frecuente en los lenguajes de tipo VB que en los lenguajes de tipo C, pero se aplica el mismo concepto.
Dos preguntas vienen a la mente:
- ¿Dónde dejas una línea en blanco en tu código?
- ¿Cuánto espacio de línea es demasiado?
1) Estoy de acuerdo contigo sobre el interlineado
2) En mi oficina hay mucha falta de interlineado porque "puedes ver más del código en una página de esa manera". También ponen varias declaraciones en una línea, y sobre el uso (IMHO)?: ... Lo odio.
3) No estoy de acuerdo con la frase "Es por eso que él es un maestro". Como (ex) maestro, tengo que decir que rebajaría la calificación de las personas por NO poner espacio entre las secciones antes de quitar los puntos por poner espacio. Yo tampoco creo que lo hice. Mi punto es que ser un asno es ortogonal a ser un maestro. (EDIT: esa sección se editó del original, pero lo dejo aquí para mantener la regla de 3 ...)
¡No hagas mal a los maestros!
A menos que te vuelvas loco con el espaciado vertical, no veo ningún problema en separar tu código. Sé que a la gente le gusta descartar la idea de usar pequeños métodos, pero algo que incluso si su método hace una sola cosa, esa única cosa podría requerir mucho código. No todo se puede hacer en una pantalla llena de código.
Acabo de trabajar en un código que va en la dirección opuesta; cada instrucción está separada de la siguiente por una línea en blanco. A los autores también les gustaba usar cuatro líneas de comentarios alineados a la derecha en la columna 60 en lugar de un comentario de una línea con sangría a nivel de código. Es difícil de leer y tedioso de arreglar. Otra característica del código (código C), la interrupción de un caso anterior está ''adjunta'' al caso del siguiente, pero hay una línea en blanco después del caso, que lo separa de su código. Ick!
Las líneas en blanco alrededor de los bloques de código son buenas. No tener demasiados bloques de código en una sola función es bueno. Las líneas en blanco alrededor de cada línea de código son desagradables. Demasiado o muy poco de algo bueno es algo malo.
Básicamente lo mismo que todos los demás está diciendo. COBOL tenía reglas muy distintas sobre qué era una oración y un párrafo. Supongo que, en el fondo de mi mente, sigo esos. Si tiene una declaración IF grande, no puso un período hasta el final del nido. Del mismo modo, puse una línea en blanco después de mi último} // fin si
Y sí, puse el // end if, // end for for, // end método stuff ahí. A algunas de las personas más vocales que conozco no les gusta, pero me gusta. Dicen que no deberías hacer grandes tus if if y que probablemente estás mal programado si NECESITAS el // fin de las cosas, y yo no lo NECESITO , pero me parece que es más fácil de leer. Llámame anticuado, TOC, lo que sea.
Como no tenemos un ejemplo de su idea personal de espaciado de línea "lógico", realmente no podemos decir si mereció o no una baja.
Tiendo a agrupar declaraciones o pasos similares en una secuencia antes del espaciado (como declaraciones de variables, bucles, etc.)
Considero el código como un artículo. ¿Alguna vez ha intentado leer 2 páginas de un artículo que no tiene ningún párrafo o espacio entre líneas?
Estoy de acuerdo contigo, no tener espacios de línea entre grupos lógicos es una locura.
Creo que hago algo similar, pero no hay reglas duras. Me gusta el código a espaciado en ''párrafos'' de la lógica agrupada / relacionada.
El código sin espacios de línea adicionales es terrible de leer.
En mi opinión, agregar un espacio en blanco a su código es una sugerencia de que debe dividir su función en partes más pequeñas. La limpieza de su código agregando espacios es preferible a una lista de líneas no separadas de una milla de largo. Es mejor limpiar su código separando las funciones más pequeñas.
He comenzado a seguir las pautas de diseño de Microsoft que se encuentran aquí:
Pautas de diseño para desarrolladores de bibliotecas de clases
Los espacios ayudan a que su código sea más legible y creo que el consenso aquí es que no son, en su mayor parte, una mala idea. Pero nadie parece haber señalado que junto con la línea en blanco un comentario puede no estar mal.
/* This section preps the widgets for display */
block
of some
code
/* This section passes the widgets to the display handler */
and
so
on
Recuerde que la mayoría del código se leerá muchas veces durante su vida, por lo que cualquier cosa que pueda hacer para facilitarle la vida a los futuros mantenedores es una gran ventaja.
Mi regla de oro es:
Coloque una sola línea en blanco entre los bloques de código que se puede describir con un comentario.
Pero en general estoy de acuerdo en que muchas funciones grandes con muchos espacios en blanco deben dividirse en funciones más pequeñas.
No suena pretencioso, pero creo que las líneas en blanco en el código tienen una función similar a las marcas de frase en notación musical, o saltos de línea en poesía: comunican la intención al lector sin cambiar la semántica del contenido.
Aquí hay un método que acabo de copiar y pegar de un proyecto:
public static void Startup(bool startupUser)
{
URI = "";
AutoComplete = new AutoCompleteWrapper();
SessionToken = Guid.Empty;
ExternalDataSetLock = new object();
ConfigDS.Init();
CalendarDS.Init();
CalendarDSBuilder.Init();
if (startupUser && UserName != null)
{
string autoCompleteFilename = Path.Combine(UserFolder, "autocomplete.xml");
AutoComplete.Load(autoCompleteFilename);
}
}
¿Qué hacen las líneas en blanco aquí? Aclaran que básicamente hay tres tipos diferentes de inicialización que tienen lugar en este método. Si agrego una nueva propiedad que necesita inicializarse en el inicio, sé dónde colocaré la línea que la inicializa. Las líneas en blanco también indican cómo pretendo refactorizar esta función si duplica su tamaño.
El riesgo de usar líneas en blanco es el mismo que el peligro de cualquier otro tipo de significado implícito: está implícito. La implicación que está haciendo cuando escribe el código puede no ser la implicación que la persona que lee el código entiende.
Pero misericordia, esa no es razón para no usarlos.
No voy a empezar a sugerir ningún detalle. Hay un montón de buenas sugerencias aquí y en otros lugares en el interweb.
Pero yo diría que sea consistente. Al menos dentro de una aplicación o módulo, ya que sé que refino mi enfoque de vez en cuando, pero trato de mantener todo el código en los mismos lugares buscando lo mismo.
Si eres consistente, es bastante fácil para cualquier otro desarrollador elegir tu tempo y estilo.
Por lo general, el espacio vertical es más importante que el espacio horizontal, por lo que el espaciado excesivo no es una buena idea. Creo que es una buena idea separar lógicamente bloques de código con una sola línea en blanco .
Suena como que tu profesor es mayormente un imbécil. Como dice el dicho, "los que pueden, hacen; los que no pueden están en enseñan". ;)
Sé que esta es una pregunta antigua, pero me tropecé haciendo una búsqueda de otra cosa, y tuve una observación: mire las respuestas existentes. Son generalmente cortos, pero contienen líneas en blanco.
Eso es lo que son los párrafos. Como en la escritura, las líneas son una forma rápida y visual de separar conceptos. No significa que cada párrafo anterior se debe dividir en una respuesta separada; no significa que cada código "párrafo" se debe dividir en un método separado.
Es una queja tonta. Si aún fuera posible hablar con ese profesor, explicaría qué significa "muro de texto".
Sigo las pautas de Microsoft para C # .
Edición : el estándar para C # es No luchar contra el IDE . Si presiona CTRL K+D , el IDE colocará automáticamente líneas en blanco entre las secciones de código.
Para seguir con eso, si observa el código de muestra de C # en MSDN o en cualquier otro lugar , normalmente hay una línea en blanco entre cada grupo ubicado lógicamente. Entonces habrá una línea en blanco después de todas sus variables miembro, una línea en blanco después de cada método, etc.
En respuesta a los comentarios que expresan conmoción y horror, uso un IDE para la programación de C #:
Programadores reales
Suena como si espacio líneas de código similar a usted.
Pero esta es una preferencia personal e irrelevante y todos tendrán su propia "manera correcta" de hacerlo. Lo más importante, en mi humilde opinión, es adaptar el estilo del entorno en el que se encuentra.
Además, encontrarás un código como este en el "mundo real" ... pero parece que tienes mayores aspiraciones. ;-)
EDITAR: ... no aspiraciones más altas que el "mundo real", pero más altas que la mierda mediocre común en el "mundo real". ... si tiene aspiraciones más altas que el "mundo real", sin embargo, es posible que desee ver a un profesional. ;-)
Tenemos un estándar de codificación que establece que no debemos poner más de una línea en blanco en una fila. Todo lo demás depende del desarrollador. En la práctica, hacemos lo que usted dice: intente agrupar líneas conectadas lógicamente en grupos y aislarlas con líneas en blanco.
Tu profesor probablemente tenía la mitad de la razón en que en el mundo real no tendrás el interlineado. Ciertamente, en el código de Big Ball of Mud me encuentro con que tienes suerte si consigues un espacio en línea y mucho menos comentarios de explicación.
Aparte de eso, el programador de 73 años que escribió la mayor parte de este Big Ball of Mud todavía está trabajando allí y su explicación es que los binarios deben mantenerse lo más pequeños posible, no me molesté en comprobar si los compiladores de 20 a Hace 30 años eran tan ineficientes que no podían despojar los espacios en blanco pero soy algo escéptico.
Utilizo líneas en blanco para separar las secciones lógicas en mi propio código, ya que me parece que mejora enormemente la legibilidad.
Como siempre, la mejor prueba con este tipo de inquietudes sobre la legibilidad es agarrar un trozo de código complicado que usted escribió y no ha visto durante más de un año y ver si puede comprenderlo rápidamente. ¡Si puedes, tu código será mejor que la mayoría de lo que verás en el mundo real!
Utiliza pequeños métodos para tener una baja complejidad ciclomática . La alta complejidad ciclomática en los métodos generalmente significa que su método debe dividirse en varios otros métodos, que serán más fáciles de leer y más fáciles de probar.
Creo que su código se enfrenta a este tipo de problema.
En general, un método con más de 100 líneas es demasiado grande y complejo, y luego debe ser refactorizado.
Para resumir, en lugar de dividir el código con espacios de línea, divídalo en métodos separados ...
Yo uso el interlineado muy similar a usted. El código que he encontrado en el mundo real a menudo tiende a estar distribuido de manera similar, o al menos no está tan unido que no se puede leer.