Very often I get into C code where printf format strings start with \n:

printf( "\nHello" );

This in my opinion is an annoying thing that offers no advantages (rather many disadvantages!) with respect to printing "Hello\n":

  • If the first printed line begins with '\n', program output will begin with a (useless) empty line
  • If the last printed line doesn't end with '\n', program output won't end with a new line (useful when reading the output on a terminal)
  • On most terminals (on line buffered streams in general), output gets flushed when a '\n' is encountered, so a line not ending with '\n' could be shown on screen much time after it's been actually printf'd (or maybe never, if the stream never gets flushed, for instance if the program crashes)

So, why do people does like this?

  • 2
    This is a little thing that really annoys me. People who do cout << endl << ..; also drives me mad. I know there's no difference but ... – Vitor Py Jun 28 '11 at 16:14
  • Do you mean "flushing" in the sense of "new line" or as in fflush()? – LennyProgrammers Jun 28 '11 at 16:22
  • @Lenny222: in the sense of fflush(). – peoro Jun 28 '11 at 17:21
  • 1
    Ah, haven't realized, that printf() flushes on newlines, in contrast to C++ streams. – LennyProgrammers Jun 29 '11 at 7:59
  • Because they are wrong. It is generally a newbie mistake – Basile Starynkevitch Feb 11 '16 at 7:32

Generally, it is done to ensure that the statement is printed on the next line. If it is done at the end of the line, the same effect can be derived. It really is of little consequence.

Update: As long as you pick one way and stick with it, it really is not going to matter one bit. If you are really concerned then type all your statements as "\nHello\n". If you do have some lines mashing together, then this is really not that hard of a "bug" to fix. Just go back and change the offending statement.

  • 16
    The difference is if you put it at the start of the line you guarantee that it will print out on a new line. If you're working on a big codebase there may be a line printing out before yours that doesn't have a newline being appended to it. – Robert Anton Reese Jun 28 '11 at 15:37
  • 1
    This is particularly true if you are sticking in print statements for debugging purposes. – Peter Rowell Jun 28 '11 at 15:47
  • 3
    Ok, but in this way a new message ("Hello2\n") could end up on the same line of your last one (ending up in "\nHelloHello2\n"): isn't this as bad as having your message on the same line of the previous one (eg: "\nPrevious-messageHello\n")? If these two scenarios are bad in the same way, a programmer/project should adopt a standard (eg: always putting '\n' at the beginning, or at the end), but I can't see what advantages you could have by putting '\n' at the beginning of your messages... – peoro Jun 29 '11 at 0:21
  • @peoro, I think my update should offer a solution if it really bothers you. – Morgan Herlocker Jun 30 '11 at 13:43

Two words: personal preference. In the grand scheme of things, I don't think this really matters. If you're annoyed by it, ask the author of this code why they write it like that. You may get some interesting answers.

I prefer all of my newline characters at the end of each line anyway.

  • +1 - It is all preference. I prefer my newline at the end of the string as well because it seems more natural to me – Jetti Jun 28 '11 at 15:29
  • 1
    Personally, when I have enough output for this to matter, I try to keep all of the actual printfs, couts and newlines in a single function (perhaps up in main()) so I can prevent any silly bugs related to missing/extra newlines. But maybe I'm just OCD about them. – Ixrec Mar 1 '15 at 19:36

As someone who uses this idiom in some contexts — although I generally put \n at the end to ensure flushing —, I can offer a justification: I tend to use this when formatting many lines, especially if starting with an empty line, so that the \ns are aligned. This means that it is somewhat easier to (a) check that all lines do indeed include a \n or (b) to ignore them as ballast, and just read the text in the lines. In this situation it actually looks tidier to me, too, but I do find all these benefits minor.

An alternative approach to minimise syntactic ballast is to use string literals including new lines, but 6.4.5 in the C11 standard forbids them, so you have to speak nicely to your compiler and think carefully about what it will do.


A reason not mentioned (unless I missed it), is that some CLI programs will use '\r' to repeatedly update a line. For example, with status.

The next line will require a newline to get the cursor to, well, the next (new) line.

Another (very bad) example is where the programmer is aware that multiple programs may be writing to the same terminal. In this chaotic case, there is a chance that some order will be imposed by the leading '\n' flushing out buffered text before writing more and possibly scrambling the outputs of writes. But such ordering is not guaranteed, and sooner or later the other process will barge in and ruin things. Don't do this on anything you'd want to show off to your mom!

I would try to keep the above example to debugging purposes, and not subject users other than yourself to the results. This would apply with multiple unsynchronized tasks writing to the same (hopefully debug) file as well.

The case of using '\r' to write over a line of text on the screen is, however, not that rare in the CLI world.

Stuff happens, after all.


Another advantage of having "\n" at the beginning of lines occurs when you want to print some variable values in the x = 5 form.

See how the R code

cat("\n x = ", x)
cat("\n y = ", y)
cat("\n z = ", z)

is shorter than

cat("x = ", x, "\n")
cat("y = ", y, "\n")
cat("z = ", z, "\n")

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.