¿Por qué la gente pone '\ n' al principio de las cadenas?

7

Muy a menudo me meto en el código C donde las cadenas de formato printf comienzan con \n :

printf ("\ nHello");

En mi opinión, esto es una cosa molesta que no ofrece ventajas (¡más bien muchas desventajas!) con respecto a la impresión "Hello\n" :

  • Si la primera línea impresa comienza con '\n' , la salida del programa comenzará con una línea vacía (inútil)
  • Si la última línea impresa no termina con '\n' , la salida del programa no terminará con una nueva línea (útil cuando se lee la salida en un terminal)
  • En la mayoría de los terminales (en general, los flujos almacenados en búferes en línea), la salida se vacía cuando se encuentra un '\n' , por lo que una línea que no termina con '\n' puede mostrarse en la pantalla mucho tiempo después de que haya sido realmente printf ' d (o tal vez nunca, si la secuencia nunca se vacía, por ejemplo, si el programa falla)

Entonces, ¿por qué a la gente le gusta esto?

    
pregunta peoro 28.06.2011 - 17:23

4 respuestas

16

En general, se hace para garantizar que la declaración se imprima en la siguiente línea. Si se hace al final de la línea, se puede derivar el mismo efecto. Realmente tiene poca importancia.

Actualización : siempre que elija una forma y se mantenga con ella, realmente no importará en absoluto. Si está realmente preocupado, escriba todas sus declaraciones como "\ nHello \ n". Si tienes algunas líneas combinadas, entonces esto no es tan difícil de solucionar. Simplemente regrese y cambie la declaración ofensiva.

    
respondido por el Morgan Herlocker 28.06.2011 - 17:27
5

Dos palabras: preferencia personal. En el gran esquema de las cosas, no creo que esto realmente importe. Si te molesta, pregúntale al autor de este código por qué lo escriben así. Puede obtener algunas respuestas interesantes.

De todos modos, prefiero todos mis caracteres de nueva línea al final de cada línea.

    
respondido por el Bernard 28.06.2011 - 17:26
3

Como alguien que usa este lenguaje en algunos contextos, aunque generalmente pongo \n al final para asegurar el enrojecimiento, puedo ofrecer una justificación: tiendo a usar esto cuando formateo muchas líneas, especialmente si empiezo con un vacío. línea, de modo que el \n s están alineados. Esto significa que es algo más fácil (a) comprobar que todas las líneas sí incluyen un \n o (b) ignorarlas como balasto, y simplemente leer el texto en las líneas. En esta situación, a mí también me parece más ordenado, pero creo que todos estos beneficios son menores.

Un enfoque alternativo para minimizar el balasto sintáctico es usar literales de cadena que incluyen nuevas líneas, pero 6.4.5 en estándar C11 los prohíbe, por lo que debe hablarle bien a su compilador y pensar cuidadosamente sobre lo que hará.

    
respondido por el PJTraill 11.02.2016 - 04:26
3

Un motivo que no se menciona (a menos que lo haya perdido), es que algunos programas CLI usarán '\ r' para actualizar una línea repetidamente. Por ejemplo, con estado.

La siguiente línea requerirá una nueva línea para obtener el cursor hacia, bueno, la siguiente (nueva) línea.

Otro ejemplo (muy malo) es cuando el programador es consciente de que varios programas pueden estar escribiendo en el mismo terminal. En este caso caótico, existe la posibilidad de que se imponga un cierto orden al '\ n' que borra el texto del búfer antes de escribir más y posiblemente mezclar las salidas de las escrituras. Pero tal orden no está garantizado, y tarde o temprano el otro proceso irrumpirá y arruinará las cosas. ¡No hagas esto con nada que quieras mostrarle a tu madre!

Intentaría mantener el ejemplo anterior para propósitos de depuración y no someter a los usuarios a los resultados que no sean usted. Esto se aplicaría con múltiples tareas no sincronizadas que se escriben en el mismo archivo (con suerte, depuración) también.

El caso de usar '\ r' para escribir sobre una línea de texto en la pantalla, sin embargo, no es tan raro en el mundo CLI.

Las cosas pasan, después de todo.

    
respondido por el Hugh Buntu 22.03.2017 - 01:00

Lea otras preguntas en las etiquetas