Why use trailing newlines instead of leading with printf?

up vote
21
down vote

favorite

3

I heard that you should avoid leading newlines when using printf. So that instead of printf("nHello World!") you should use printf("Hello World!n")

In this particular example it does not make sense, since the output would be different, but consider this:

printf("Initializing");

init();

printf("nProcessing");

process_data();

printf("nExiting");

compared to:

printf("Initializingn");

init();

printf("Processingn");

process_data();

printf("Exiting");

I cannot see any benefit with trailing newlines, except that it looks better. Is there any other reason?

c

share|improve this question

asked yesterday

Broman

24029

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  This question is on the border between "issues with code" (which is off-topic) and "conceptual software design" (which is on-topic). It may get closed, but don't take it too hard. I think adding concrete code examples was the right choice nevertheless.
  – Kilian Foth
  yesterday
  

  
  
  
  


• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  The last line would merge with the command prompt on linux without a trailing newline.
  – GrandmasterB
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If it "looks better" and it has no downside, that's a good enough reason to do it, IMO. Writing good code is no different to writing a good novel or a good technical paper - the devil is always in the detail.
  – alephzero
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @GrandmasterB: I believe that depends on your shell. bash will print the prompt immediately wherever the cursor may be, but zsh will put a mark there and start the prompt on the next line.
  – Daniel Pryden
  17 hours ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Do init() and process_data() print anything themselves? What would you expect the result to look like if they did?
  – Bergi
  16 hours ago
  
  
  

  
  
  
  

 | 
show 1 more comment

up vote
21
down vote

favorite

3

I heard that you should avoid leading newlines when using printf. So that instead of printf("nHello World!") you should use printf("Hello World!n")

In this particular example it does not make sense, since the output would be different, but consider this:

printf("Initializing");

init();

printf("nProcessing");

process_data();

printf("nExiting");

compared to:

printf("Initializingn");

init();

printf("Processingn");

process_data();

printf("Exiting");

I cannot see any benefit with trailing newlines, except that it looks better. Is there any other reason?

c

share|improve this question

asked yesterday

Broman

24029

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  This question is on the border between "issues with code" (which is off-topic) and "conceptual software design" (which is on-topic). It may get closed, but don't take it too hard. I think adding concrete code examples was the right choice nevertheless.
  – Kilian Foth
  yesterday
  

  
  
  
  


• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  The last line would merge with the command prompt on linux without a trailing newline.
  – GrandmasterB
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If it "looks better" and it has no downside, that's a good enough reason to do it, IMO. Writing good code is no different to writing a good novel or a good technical paper - the devil is always in the detail.
  – alephzero
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @GrandmasterB: I believe that depends on your shell. bash will print the prompt immediately wherever the cursor may be, but zsh will put a mark there and start the prompt on the next line.
  – Daniel Pryden
  17 hours ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Do init() and process_data() print anything themselves? What would you expect the result to look like if they did?
  – Bergi
  16 hours ago
  
  
  

  
  
  
  

 | 
show 1 more comment

up vote
21
down vote

favorite

3

up vote
21
down vote

favorite

3

3

I heard that you should avoid leading newlines when using printf. So that instead of printf("nHello World!") you should use printf("Hello World!n")

In this particular example it does not make sense, since the output would be different, but consider this:

printf("Initializing");

init();

printf("nProcessing");

process_data();

printf("nExiting");

compared to:

printf("Initializingn");

init();

printf("Processingn");

process_data();

printf("Exiting");

I cannot see any benefit with trailing newlines, except that it looks better. Is there any other reason?

c

share|improve this question

asked yesterday

Broman

24029

I heard that you should avoid leading newlines when using printf. So that instead of printf("nHello World!") you should use printf("Hello World!n")

In this particular example it does not make sense, since the output would be different, but consider this:

printf("Initializing");

init();

printf("nProcessing");

process_data();

printf("nExiting");

compared to:

printf("Initializingn");

init();

printf("Processingn");

process_data();

printf("Exiting");

I cannot see any benefit with trailing newlines, except that it looks better. Is there any other reason?

c

c

share|improve this question

asked yesterday

Broman

24029

share|improve this question

asked yesterday

Broman

24029

share|improve this question

share|improve this question

asked yesterday

Broman

24029

asked yesterday

Broman

24029

asked yesterday

Broman

24029

24029

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  This question is on the border between "issues with code" (which is off-topic) and "conceptual software design" (which is on-topic). It may get closed, but don't take it too hard. I think adding concrete code examples was the right choice nevertheless.
  – Kilian Foth
  yesterday
  

  
  
  
  


• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  The last line would merge with the command prompt on linux without a trailing newline.
  – GrandmasterB
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If it "looks better" and it has no downside, that's a good enough reason to do it, IMO. Writing good code is no different to writing a good novel or a good technical paper - the devil is always in the detail.
  – alephzero
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @GrandmasterB: I believe that depends on your shell. bash will print the prompt immediately wherever the cursor may be, but zsh will put a mark there and start the prompt on the next line.
  – Daniel Pryden
  17 hours ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Do init() and process_data() print anything themselves? What would you expect the result to look like if they did?
  – Bergi
  16 hours ago
  
  
  

  
  
  
  

 | 
show 1 more comment

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  This question is on the border between "issues with code" (which is off-topic) and "conceptual software design" (which is on-topic). It may get closed, but don't take it too hard. I think adding concrete code examples was the right choice nevertheless.
  – Kilian Foth
  yesterday
  

  
  
  
  


• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  The last line would merge with the command prompt on linux without a trailing newline.
  – GrandmasterB
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If it "looks better" and it has no downside, that's a good enough reason to do it, IMO. Writing good code is no different to writing a good novel or a good technical paper - the devil is always in the detail.
  – alephzero
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @GrandmasterB: I believe that depends on your shell. bash will print the prompt immediately wherever the cursor may be, but zsh will put a mark there and start the prompt on the next line.
  – Daniel Pryden
  17 hours ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Do init() and process_data() print anything themselves? What would you expect the result to look like if they did?
  – Bergi
  16 hours ago
  
  
  

  
  
  
  

2

2

This question is on the border between "issues with code" (which is off-topic) and "conceptual software design" (which is on-topic). It may get closed, but don't take it too hard. I think adding concrete code examples was the right choice nevertheless.
– Kilian Foth
yesterday

This question is on the border between "issues with code" (which is off-topic) and "conceptual software design" (which is on-topic). It may get closed, but don't take it too hard. I think adding concrete code examples was the right choice nevertheless.
– Kilian Foth
yesterday

10

10

The last line would merge with the command prompt on linux without a trailing newline.
– GrandmasterB
18 hours ago

The last line would merge with the command prompt on linux without a trailing newline.
– GrandmasterB
18 hours ago

If it "looks better" and it has no downside, that's a good enough reason to do it, IMO. Writing good code is no different to writing a good novel or a good technical paper - the devil is always in the detail.
– alephzero
18 hours ago

If it "looks better" and it has no downside, that's a good enough reason to do it, IMO. Writing good code is no different to writing a good novel or a good technical paper - the devil is always in the detail.
– alephzero
18 hours ago

@GrandmasterB: I believe that depends on your shell. bash will print the prompt immediately wherever the cursor may be, but zsh will put a mark there and start the prompt on the next line.
– Daniel Pryden
17 hours ago

@GrandmasterB: I believe that depends on your shell. bash will print the prompt immediately wherever the cursor may be, but zsh will put a mark there and start the prompt on the next line.
– Daniel Pryden
17 hours ago

2

2

Do init() and process_data() print anything themselves? What would you expect the result to look like if they did?
– Bergi
16 hours ago

Do init() and process_data() print anything themselves? What would you expect the result to look like if they did?
– Bergi
16 hours ago

 | 
show 1 more comment

6 Answers
6

active

oldest

votes

up vote
96
down vote



accepted

A fair amount of terminal I/O is line-buffered, so by ending a message with n you can be certain that it will be displayed in a timely manner. With a leading n the message may or may not be displayed at once. Often, this would mean that each step displays the progress message of the previous step, which causes no end of confusion and wasted time when you try to understand a program's behaviour.

share|improve this answer

answered yesterday

Kilian Foth

86.7k32235262

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  This is particularly important when using printf for debugging a program that crashes. Putting the newline at the end of a printf means that stdout to the console gets flushed at each printf. (Note that when stdout is redirected to a file, the std libraries will usually do block buffering instead of line buffering, so that makes printf debugging a crash quite hard even with newline at the end.)
  – Erik Eidt
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @ErikEidt Note that you should use fprintf(STDERR, …) instead, which is generally not buffered at all for diagnostic output.
  – Deduplicator
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Deduplicator Writing diagnostic messages to the error stream has its downsides as well - many scripts assume a program has failed if something is written to the error stream.
  – Voo
  18 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  16
  

  
  
  
  
  
  

  
  @Voo: I would argue that any program that assumes writes to stderr indicate a failure is itself incorrect. The exit code of the process is what indicates whether or not it failed. If it was a failure, then the stderr output will explain why. If the process exited successfully (exit code zero) then stderr output should be considered informational output for a human user, with no particular machine-parseable semantic (it might contain human-readable warnings, for example), while stdout is the actual output of the program, possibly suitable for further processing.
  – Daniel Pryden
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @Voo: What programs are you describing? I'm not aware of any widely-used software package that behaves like you describe. I do know that there are programs that do, but it's not like I just made up the convention I describe above: that's the way the vast majority of programs in a Unix or Unix-like environment work, and to my knowledge, the way the vast majority of programs always have. I certainly wouldn't advocate for any program to avoid writing to stderr simply because some scripts don't handle it well.
  – Daniel Pryden
  17 hours ago
  
  
  

  
  
  
  

 | 
show 3 more comments

up vote
23
down vote

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.

share|improve this answer

edited 19 hours ago

answered 21 hours ago

cmaster

5,80311120

• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  This is one of the oldest debates in software engineering: is it better to use newlines (or, in a programming language, another "end of statement" marker like a semicolon) as line terminators or line separators? Both approaches have their pros and cons. The Windows world has mostly settled on the idea that the newline sequence (which is typically CR LF there) is a line separator, and thus the last line in a file doesn't need to end with it. In the Unix world, though, a newline sequence (LF) is a line terminator, and many programs are built around this assumption.
  – Daniel Pryden
  21 hours ago
  

  
  
  
  


• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  POSIX even defines a line as "A sequence of zero or more non-newline characters plus a terminating newline character."
  – pipe
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Given that as @pipe says, it's in the POSIX specification, we can probably call it de jure as opposed to de facto as the answer suggests?
  – Baldrickk
  19 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Baldrickk Right. I have updated my answer to be more affirmative, now.
  – cmaster
  19 hours ago
  

  
  
  
  

add a comment | 

up vote
6
down vote

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.

share|improve this answer

edited 18 hours ago

answered 18 hours ago

alephzero

16914

New contributor

alephzero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment | 

up vote
3
down vote

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.

share|improve this answer

edited 15 hours ago

answered 15 hours ago

The Guy with The Hat

1689

add a comment | 

up vote
2
down vote

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).

share|improve this answer

answered 14 hours ago

Alex Vong

1992

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Yes, "okn" is much better than "nok"...
  – cmaster
  13 hours ago
  
  
  

  
  
  
  

add a comment | 

up vote
0
down vote

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.

share|improve this answer

answered 22 hours ago

Ian

4,1411225

add a comment | 

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f381711%2fwhy-use-trailing-newlines-instead-of-leading-with-printf%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(function () {
$("#show-editor-button input, #show-editor-button button").click(function () {
var showEditor = function() {
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
};

var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True') {
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');

$(this).loadPopup({
url: '/post/self-answer-popup',
loaded: function(popup) {
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');

pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
}
})
} else{
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true) {
showEditor();
}
}
});
});

6 Answers
6

active

oldest

votes

6 Answers
6

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
96
down vote



accepted

A fair amount of terminal I/O is line-buffered, so by ending a message with n you can be certain that it will be displayed in a timely manner. With a leading n the message may or may not be displayed at once. Often, this would mean that each step displays the progress message of the previous step, which causes no end of confusion and wasted time when you try to understand a program's behaviour.

share|improve this answer

answered yesterday

Kilian Foth

86.7k32235262

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  This is particularly important when using printf for debugging a program that crashes. Putting the newline at the end of a printf means that stdout to the console gets flushed at each printf. (Note that when stdout is redirected to a file, the std libraries will usually do block buffering instead of line buffering, so that makes printf debugging a crash quite hard even with newline at the end.)
  – Erik Eidt
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @ErikEidt Note that you should use fprintf(STDERR, …) instead, which is generally not buffered at all for diagnostic output.
  – Deduplicator
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Deduplicator Writing diagnostic messages to the error stream has its downsides as well - many scripts assume a program has failed if something is written to the error stream.
  – Voo
  18 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  16
  

  
  
  
  
  
  

  
  @Voo: I would argue that any program that assumes writes to stderr indicate a failure is itself incorrect. The exit code of the process is what indicates whether or not it failed. If it was a failure, then the stderr output will explain why. If the process exited successfully (exit code zero) then stderr output should be considered informational output for a human user, with no particular machine-parseable semantic (it might contain human-readable warnings, for example), while stdout is the actual output of the program, possibly suitable for further processing.
  – Daniel Pryden
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @Voo: What programs are you describing? I'm not aware of any widely-used software package that behaves like you describe. I do know that there are programs that do, but it's not like I just made up the convention I describe above: that's the way the vast majority of programs in a Unix or Unix-like environment work, and to my knowledge, the way the vast majority of programs always have. I certainly wouldn't advocate for any program to avoid writing to stderr simply because some scripts don't handle it well.
  – Daniel Pryden
  17 hours ago
  
  
  

  
  
  
  

 | 
show 3 more comments

up vote
96
down vote



accepted

A fair amount of terminal I/O is line-buffered, so by ending a message with n you can be certain that it will be displayed in a timely manner. With a leading n the message may or may not be displayed at once. Often, this would mean that each step displays the progress message of the previous step, which causes no end of confusion and wasted time when you try to understand a program's behaviour.

share|improve this answer

answered yesterday

Kilian Foth

86.7k32235262

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  This is particularly important when using printf for debugging a program that crashes. Putting the newline at the end of a printf means that stdout to the console gets flushed at each printf. (Note that when stdout is redirected to a file, the std libraries will usually do block buffering instead of line buffering, so that makes printf debugging a crash quite hard even with newline at the end.)
  – Erik Eidt
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @ErikEidt Note that you should use fprintf(STDERR, …) instead, which is generally not buffered at all for diagnostic output.
  – Deduplicator
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Deduplicator Writing diagnostic messages to the error stream has its downsides as well - many scripts assume a program has failed if something is written to the error stream.
  – Voo
  18 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  16
  

  
  
  
  
  
  

  
  @Voo: I would argue that any program that assumes writes to stderr indicate a failure is itself incorrect. The exit code of the process is what indicates whether or not it failed. If it was a failure, then the stderr output will explain why. If the process exited successfully (exit code zero) then stderr output should be considered informational output for a human user, with no particular machine-parseable semantic (it might contain human-readable warnings, for example), while stdout is the actual output of the program, possibly suitable for further processing.
  – Daniel Pryden
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @Voo: What programs are you describing? I'm not aware of any widely-used software package that behaves like you describe. I do know that there are programs that do, but it's not like I just made up the convention I describe above: that's the way the vast majority of programs in a Unix or Unix-like environment work, and to my knowledge, the way the vast majority of programs always have. I certainly wouldn't advocate for any program to avoid writing to stderr simply because some scripts don't handle it well.
  – Daniel Pryden
  17 hours ago
  
  
  

  
  
  
  

 | 
show 3 more comments

up vote
96
down vote



accepted

up vote
96
down vote



accepted

A fair amount of terminal I/O is line-buffered, so by ending a message with n you can be certain that it will be displayed in a timely manner. With a leading n the message may or may not be displayed at once. Often, this would mean that each step displays the progress message of the previous step, which causes no end of confusion and wasted time when you try to understand a program's behaviour.

share|improve this answer

answered yesterday

Kilian Foth

86.7k32235262

A fair amount of terminal I/O is line-buffered, so by ending a message with n you can be certain that it will be displayed in a timely manner. With a leading n the message may or may not be displayed at once. Often, this would mean that each step displays the progress message of the previous step, which causes no end of confusion and wasted time when you try to understand a program's behaviour.

share|improve this answer

answered yesterday

Kilian Foth

86.7k32235262

share|improve this answer

share|improve this answer

answered yesterday

Kilian Foth

86.7k32235262

answered yesterday

Kilian Foth

86.7k32235262

answered yesterday

Kilian Foth

86.7k32235262

86.7k32235262

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  This is particularly important when using printf for debugging a program that crashes. Putting the newline at the end of a printf means that stdout to the console gets flushed at each printf. (Note that when stdout is redirected to a file, the std libraries will usually do block buffering instead of line buffering, so that makes printf debugging a crash quite hard even with newline at the end.)
  – Erik Eidt
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @ErikEidt Note that you should use fprintf(STDERR, …) instead, which is generally not buffered at all for diagnostic output.
  – Deduplicator
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Deduplicator Writing diagnostic messages to the error stream has its downsides as well - many scripts assume a program has failed if something is written to the error stream.
  – Voo
  18 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  16
  

  
  
  
  
  
  

  
  @Voo: I would argue that any program that assumes writes to stderr indicate a failure is itself incorrect. The exit code of the process is what indicates whether or not it failed. If it was a failure, then the stderr output will explain why. If the process exited successfully (exit code zero) then stderr output should be considered informational output for a human user, with no particular machine-parseable semantic (it might contain human-readable warnings, for example), while stdout is the actual output of the program, possibly suitable for further processing.
  – Daniel Pryden
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @Voo: What programs are you describing? I'm not aware of any widely-used software package that behaves like you describe. I do know that there are programs that do, but it's not like I just made up the convention I describe above: that's the way the vast majority of programs in a Unix or Unix-like environment work, and to my knowledge, the way the vast majority of programs always have. I certainly wouldn't advocate for any program to avoid writing to stderr simply because some scripts don't handle it well.
  – Daniel Pryden
  17 hours ago
  
  
  

  
  
  
  

 | 
show 3 more comments

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  This is particularly important when using printf for debugging a program that crashes. Putting the newline at the end of a printf means that stdout to the console gets flushed at each printf. (Note that when stdout is redirected to a file, the std libraries will usually do block buffering instead of line buffering, so that makes printf debugging a crash quite hard even with newline at the end.)
  – Erik Eidt
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @ErikEidt Note that you should use fprintf(STDERR, …) instead, which is generally not buffered at all for diagnostic output.
  – Deduplicator
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Deduplicator Writing diagnostic messages to the error stream has its downsides as well - many scripts assume a program has failed if something is written to the error stream.
  – Voo
  18 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  16
  

  
  
  
  
  
  

  
  @Voo: I would argue that any program that assumes writes to stderr indicate a failure is itself incorrect. The exit code of the process is what indicates whether or not it failed. If it was a failure, then the stderr output will explain why. If the process exited successfully (exit code zero) then stderr output should be considered informational output for a human user, with no particular machine-parseable semantic (it might contain human-readable warnings, for example), while stdout is the actual output of the program, possibly suitable for further processing.
  – Daniel Pryden
  18 hours ago
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  @Voo: What programs are you describing? I'm not aware of any widely-used software package that behaves like you describe. I do know that there are programs that do, but it's not like I just made up the convention I describe above: that's the way the vast majority of programs in a Unix or Unix-like environment work, and to my knowledge, the way the vast majority of programs always have. I certainly wouldn't advocate for any program to avoid writing to stderr simply because some scripts don't handle it well.
  – Daniel Pryden
  17 hours ago
  
  
  

  
  
  
  

8

8

This is particularly important when using printf for debugging a program that crashes. Putting the newline at the end of a printf means that stdout to the console gets flushed at each printf. (Note that when stdout is redirected to a file, the std libraries will usually do block buffering instead of line buffering, so that makes printf debugging a crash quite hard even with newline at the end.)
– Erik Eidt
20 hours ago

This is particularly important when using printf for debugging a program that crashes. Putting the newline at the end of a printf means that stdout to the console gets flushed at each printf. (Note that when stdout is redirected to a file, the std libraries will usually do block buffering instead of line buffering, so that makes printf debugging a crash quite hard even with newline at the end.)
– Erik Eidt
20 hours ago

9

9

@ErikEidt Note that you should use fprintf(STDERR, …) instead, which is generally not buffered at all for diagnostic output.
– Deduplicator
18 hours ago

@ErikEidt Note that you should use fprintf(STDERR, …) instead, which is generally not buffered at all for diagnostic output.
– Deduplicator
18 hours ago

1

1

@Deduplicator Writing diagnostic messages to the error stream has its downsides as well - many scripts assume a program has failed if something is written to the error stream.
– Voo
18 hours ago

@Deduplicator Writing diagnostic messages to the error stream has its downsides as well - many scripts assume a program has failed if something is written to the error stream.
– Voo
18 hours ago

16

16

@Voo: I would argue that any program that assumes writes to stderr indicate a failure is itself incorrect. The exit code of the process is what indicates whether or not it failed. If it was a failure, then the stderr output will explain why. If the process exited successfully (exit code zero) then stderr output should be considered informational output for a human user, with no particular machine-parseable semantic (it might contain human-readable warnings, for example), while stdout is the actual output of the program, possibly suitable for further processing.
– Daniel Pryden
18 hours ago

@Voo: I would argue that any program that assumes writes to stderr indicate a failure is itself incorrect. The exit code of the process is what indicates whether or not it failed. If it was a failure, then the stderr output will explain why. If the process exited successfully (exit code zero) then stderr output should be considered informational output for a human user, with no particular machine-parseable semantic (it might contain human-readable warnings, for example), while stdout is the actual output of the program, possibly suitable for further processing.
– Daniel Pryden
18 hours ago

9

9

@Voo: What programs are you describing? I'm not aware of any widely-used software package that behaves like you describe. I do know that there are programs that do, but it's not like I just made up the convention I describe above: that's the way the vast majority of programs in a Unix or Unix-like environment work, and to my knowledge, the way the vast majority of programs always have. I certainly wouldn't advocate for any program to avoid writing to stderr simply because some scripts don't handle it well.
– Daniel Pryden
17 hours ago

@Voo: What programs are you describing? I'm not aware of any widely-used software package that behaves like you describe. I do know that there are programs that do, but it's not like I just made up the convention I describe above: that's the way the vast majority of programs in a Unix or Unix-like environment work, and to my knowledge, the way the vast majority of programs always have. I certainly wouldn't advocate for any program to avoid writing to stderr simply because some scripts don't handle it well.
– Daniel Pryden
17 hours ago

 | 
show 3 more comments

up vote
23
down vote

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.

share|improve this answer

edited 19 hours ago

answered 21 hours ago

cmaster

5,80311120

• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  This is one of the oldest debates in software engineering: is it better to use newlines (or, in a programming language, another "end of statement" marker like a semicolon) as line terminators or line separators? Both approaches have their pros and cons. The Windows world has mostly settled on the idea that the newline sequence (which is typically CR LF there) is a line separator, and thus the last line in a file doesn't need to end with it. In the Unix world, though, a newline sequence (LF) is a line terminator, and many programs are built around this assumption.
  – Daniel Pryden
  21 hours ago
  

  
  
  
  


• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  POSIX even defines a line as "A sequence of zero or more non-newline characters plus a terminating newline character."
  – pipe
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Given that as @pipe says, it's in the POSIX specification, we can probably call it de jure as opposed to de facto as the answer suggests?
  – Baldrickk
  19 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Baldrickk Right. I have updated my answer to be more affirmative, now.
  – cmaster
  19 hours ago
  

  
  
  
  

add a comment | 

up vote
23
down vote

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.

share|improve this answer

edited 19 hours ago

answered 21 hours ago

cmaster

5,80311120

• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  This is one of the oldest debates in software engineering: is it better to use newlines (or, in a programming language, another "end of statement" marker like a semicolon) as line terminators or line separators? Both approaches have their pros and cons. The Windows world has mostly settled on the idea that the newline sequence (which is typically CR LF there) is a line separator, and thus the last line in a file doesn't need to end with it. In the Unix world, though, a newline sequence (LF) is a line terminator, and many programs are built around this assumption.
  – Daniel Pryden
  21 hours ago
  

  
  
  
  


• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  POSIX even defines a line as "A sequence of zero or more non-newline characters plus a terminating newline character."
  – pipe
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Given that as @pipe says, it's in the POSIX specification, we can probably call it de jure as opposed to de facto as the answer suggests?
  – Baldrickk
  19 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Baldrickk Right. I have updated my answer to be more affirmative, now.
  – cmaster
  19 hours ago
  

  
  
  
  

add a comment | 

up vote
23
down vote

up vote
23
down vote

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.

share|improve this answer

edited 19 hours ago

answered 21 hours ago

cmaster

5,80311120

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.

share|improve this answer

edited 19 hours ago

answered 21 hours ago

cmaster

5,80311120

share|improve this answer

share|improve this answer

edited 19 hours ago

edited 19 hours ago

edited 19 hours ago

answered 21 hours ago

cmaster

5,80311120

answered 21 hours ago

cmaster

5,80311120

answered 21 hours ago

cmaster

5,80311120

5,80311120

• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  This is one of the oldest debates in software engineering: is it better to use newlines (or, in a programming language, another "end of statement" marker like a semicolon) as line terminators or line separators? Both approaches have their pros and cons. The Windows world has mostly settled on the idea that the newline sequence (which is typically CR LF there) is a line separator, and thus the last line in a file doesn't need to end with it. In the Unix world, though, a newline sequence (LF) is a line terminator, and many programs are built around this assumption.
  – Daniel Pryden
  21 hours ago
  

  
  
  
  


• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  POSIX even defines a line as "A sequence of zero or more non-newline characters plus a terminating newline character."
  – pipe
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Given that as @pipe says, it's in the POSIX specification, we can probably call it de jure as opposed to de facto as the answer suggests?
  – Baldrickk
  19 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Baldrickk Right. I have updated my answer to be more affirmative, now.
  – cmaster
  19 hours ago
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  This is one of the oldest debates in software engineering: is it better to use newlines (or, in a programming language, another "end of statement" marker like a semicolon) as line terminators or line separators? Both approaches have their pros and cons. The Windows world has mostly settled on the idea that the newline sequence (which is typically CR LF there) is a line separator, and thus the last line in a file doesn't need to end with it. In the Unix world, though, a newline sequence (LF) is a line terminator, and many programs are built around this assumption.
  – Daniel Pryden
  21 hours ago
  

  
  
  
  


• 
  
  
  

  
  12
  

  
  
  
  
  
  

  
  POSIX even defines a line as "A sequence of zero or more non-newline characters plus a terminating newline character."
  – pipe
  20 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Given that as @pipe says, it's in the POSIX specification, we can probably call it de jure as opposed to de facto as the answer suggests?
  – Baldrickk
  19 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @Baldrickk Right. I have updated my answer to be more affirmative, now.
  – cmaster
  19 hours ago
  

  
  
  
  

12

12

This is one of the oldest debates in software engineering: is it better to use newlines (or, in a programming language, another "end of statement" marker like a semicolon) as line terminators or line separators? Both approaches have their pros and cons. The Windows world has mostly settled on the idea that the newline sequence (which is typically CR LF there) is a line separator, and thus the last line in a file doesn't need to end with it. In the Unix world, though, a newline sequence (LF) is a line terminator, and many programs are built around this assumption.
– Daniel Pryden
21 hours ago

This is one of the oldest debates in software engineering: is it better to use newlines (or, in a programming language, another "end of statement" marker like a semicolon) as line terminators or line separators? Both approaches have their pros and cons. The Windows world has mostly settled on the idea that the newline sequence (which is typically CR LF there) is a line separator, and thus the last line in a file doesn't need to end with it. In the Unix world, though, a newline sequence (LF) is a line terminator, and many programs are built around this assumption.
– Daniel Pryden
21 hours ago

12

12

POSIX even defines a line as "A sequence of zero or more non-newline characters plus a terminating newline character."
– pipe
20 hours ago

POSIX even defines a line as "A sequence of zero or more non-newline characters plus a terminating newline character."
– pipe
20 hours ago

Given that as @pipe says, it's in the POSIX specification, we can probably call it de jure as opposed to de facto as the answer suggests?
– Baldrickk
19 hours ago

Given that as @pipe says, it's in the POSIX specification, we can probably call it de jure as opposed to de facto as the answer suggests?
– Baldrickk
19 hours ago

1

1

@Baldrickk Right. I have updated my answer to be more affirmative, now.
– cmaster
19 hours ago

@Baldrickk Right. I have updated my answer to be more affirmative, now.
– cmaster
19 hours ago

add a comment | 

up vote
6
down vote

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.

share|improve this answer

edited 18 hours ago

answered 18 hours ago

alephzero

16914

New contributor

alephzero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment | 

up vote
6
down vote

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.

share|improve this answer

edited 18 hours ago

answered 18 hours ago

alephzero

16914

New contributor

alephzero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment | 

up vote
6
down vote

up vote
6
down vote

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.

share|improve this answer

edited 18 hours ago

answered 18 hours ago

alephzero

16914

New contributor

alephzero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

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.

share|improve this answer

edited 18 hours ago

answered 18 hours ago

alephzero

16914

New contributor

alephzero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

share|improve this answer

share|improve this answer

edited 18 hours ago

edited 18 hours ago

edited 18 hours ago

answered 18 hours ago

alephzero

16914

New contributor

alephzero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

answered 18 hours ago

alephzero

16914

answered 18 hours ago

alephzero

16914

16914

New contributor

alephzero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

New contributor

alephzero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

alephzero is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment | 

add a comment | 

up vote
3
down vote

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.

share|improve this answer

edited 15 hours ago

answered 15 hours ago

The Guy with The Hat

1689

add a comment | 

up vote
3
down vote

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.

share|improve this answer

edited 15 hours ago

answered 15 hours ago

The Guy with The Hat

1689

add a comment | 

up vote
3
down vote

up vote
3
down vote

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.

share|improve this answer

edited 15 hours ago

answered 15 hours ago

The Guy with The Hat

1689

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.

share|improve this answer

edited 15 hours ago

answered 15 hours ago

The Guy with The Hat

1689

share|improve this answer

share|improve this answer

edited 15 hours ago

edited 15 hours ago

edited 15 hours ago

answered 15 hours ago

The Guy with The Hat

1689

answered 15 hours ago

The Guy with The Hat

1689

answered 15 hours ago

The Guy with The Hat

1689

1689

add a comment | 

add a comment | 

up vote
2
down vote

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).

share|improve this answer

answered 14 hours ago

Alex Vong

1992

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Yes, "okn" is much better than "nok"...
  – cmaster
  13 hours ago
  
  
  

  
  
  
  

add a comment | 

up vote
2
down vote

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).

share|improve this answer

answered 14 hours ago

Alex Vong

1992

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Yes, "okn" is much better than "nok"...
  – cmaster
  13 hours ago
  
  
  

  
  
  
  

add a comment | 

up vote
2
down vote

up vote
2
down vote

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).

share|improve this answer

answered 14 hours ago

Alex Vong

1992

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).

share|improve this answer

answered 14 hours ago

Alex Vong

1992

share|improve this answer

share|improve this answer

answered 14 hours ago

Alex Vong

1992

answered 14 hours ago

Alex Vong

1992

answered 14 hours ago

Alex Vong

1992

1992

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Yes, "okn" is much better than "nok"...
  – cmaster
  13 hours ago
  
  
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Yes, "okn" is much better than "nok"...
  – cmaster
  13 hours ago
  
  
  

  
  
  
  

1

1

Yes, "okn" is much better than "nok"...
– cmaster
13 hours ago

Yes, "okn" is much better than "nok"...
– cmaster
13 hours ago

add a comment | 

up vote
0
down vote

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.

share|improve this answer

answered 22 hours ago

Ian

4,1411225

add a comment | 

up vote
0
down vote

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.

share|improve this answer

answered 22 hours ago

Ian

4,1411225

add a comment | 

up vote
0
down vote

up vote
0
down vote

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.

share|improve this answer

answered 22 hours ago

Ian

4,1411225

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.

share|improve this answer

answered 22 hours ago

Ian

4,1411225

share|improve this answer

share|improve this answer

answered 22 hours ago

Ian

4,1411225

answered 22 hours ago

Ian

4,1411225

answered 22 hours ago

Ian

4,1411225

4,1411225

add a comment | 

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f381711%2fwhy-use-trailing-newlines-instead-of-leading-with-printf%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

This page is only for reference, If you need detailed information, please check here