Krdytkyu

On POSIX systems (basically any linux, BSD, whatever open-source based system you can find), a line is defined to be a string of characters that's terminated by a newline n. This is the basic assumption all the standard command line tools build upon, including (but not limited to) wc, grep, sed, awk, and vim. This is also the reason why some editor (like vim) always add a n at the end of a file, and why earlier standards of C required headers to end with a n character.

Btw: Having n terminated lines makes processing of text much easier: You know for sure that you've got a complete line when you've got that terminator. And you know for sure that you need to look at more characters if you didn't encounter that terminator yet.

Of course, this is on the input side of programs, but program output is very often used as program input again. So, your output should stick to the convention for the sake of allowing seamless input into other programs.

In addition to what other have mentioned, I feel like there is a much simpler reason: it's the standard. Whenever anything prints to STDOUT, it almost always assumes that it is already on a new line, and thus doesn't need to start a new one. It also assumes the next line to be written will act the same way, so it helpfully ends by starting a new line.

If you output leading-newline lines interleaved with standard trailing-newline lines," it will end up looking like this:

Trailing-newline-line

Trailing-newline-line



Leading-newline-line

Leading-newline-line

Leading-newline-lineTrailing-newline-line

Trailing-newline-line



Leading-newline-lineTrailing-newline-line

Trailing-newline-line

Trailing-newline-line

...which is presumably not what you want.

If you use only leading newlines in your code and only run it in an IDE, it may turn out okay. As soon as you run it in a terminal or introduce other people's code that will write to STDOUT alongside your code, you'll see undesirable output like above.

Since the highly up-voted answers have already given excellent technical reasons why trailing newlines should be preferred, I will approach it from another angle.

In my opinions, the followings make a program more readable:

1. a high signal-to-noise ratio (aka simple but not simpler)


2. important ideas come first

From the above points, we can argue that trailing newlines are better. Newlines are formatting "noise" when compared to the message, the message should stand out and thus should come first (syntax-highlighting can help too).

Using trailing newlines simplifies later modifications.

As a (very trivial) example based on the OP's code, suppose you need to produce some output before the "Initializing" message, and that output comes from a different logical part of the code, in a different source file.

When you run the first test and find "Initializing" is now appended to the end of a line of some other output, you have to search through the code to find where it got printed, and then hope changing "Initializing" to "nInitializing" doesn't screw up the format of something else, in different circumstances.

Now consider how to are going to handle the fact that your new output is actually optional, so your change to "nInitializing" sometimes produces an unwanted blank line at the start of the output ...

Do you set a global (shock horror??!!!) flag saying whether there was any preceding output and test it to print "Initializing" with an optional leading "n", or do you output the "n" along with your earlier output and leave future code readers wondering why this "Initializing" doesn't have a leading "n" like all the other output messages do?

If you consistently output trailing newlines, at the point where you know you have reached the end of the line that needs to be terminated, you sidestep all those issues. Note, that might require a separate puts("n") statement at the end of some logic that outputs a line piece by piece, but the point is you output the newline at the earliest place in the code where you know you need to do it, not somewhere else.

Why use trailing newlines instead of leading with printf?

Closely match C spec.

The C library defines a line as ending with a new-line character 'n'.

A text stream is an ordered sequence of characters composed into lines, each line consisting of zero or more characters plus a terminating new-line character. Whether the last line requires a terminating new-line character is implementation-defined. C11 §7.21.2 2

Code that writes data as lines will then match that concept of the library.

printf("Initializing"); // Write part of a line

printf("nProcessing"); // Finish prior line & write part of a line

printf("nExiting");    // Finish prior line & write an implementation-defined last line



printf("Initializingn");//Write a line 

printf("Processingn");  //Write a line

printf("Exiting");       //Write an implementation-defined last line

Re: last line requires a terminating new-line character. I'd recommend to always write a final 'n' on output and tolerate its absence on input.

Spell checking

My spell checker complains. Perhaps your does too.

  v---------v Not a valid word

"nProcessing"



 v--------v OK

"Processingn");

Leading newlines can often make it easier to write the code when there are conditionals, for example,

printf("Initializing");

if (jobName != null)

    printf(": %s", jobName);

init();

printf("nProcessing");

(But as has been noted elsewhere you may need to flush the output buffer before doing any steps that takes much CPU time.)

Hence a good case can be made for both ways of doing it, however personly I don't like printf() and would use a custom class to build up the output.

Leading newlines don't work well with other library functions, notably puts() and perror in the Standard Library, but also any other library you're likely to use.

If you want to print a pre-written line (either a constant, or one already formatted - e.g. with sprintf()), then puts() is the natural (and efficient) choice. However, there's no way for puts() to end the previous line and write an unterminated line - it always writes the line terminator.