Code will be running on Windows, Mac, and ARM. Whi...
# codereview
e
Code will be running on Windows, Mac, and ARM. Which is better:
Copy code
println(results.joinToString(separator = "\n"))
Copy code
println(results.joinToString(separator = System.lineSeparator())
d
My thinking on this:
println
should handle the conversion of "\n"
👍 1
e
afaik modern Windows terminal will treat
\n
as a real newline
also ARM has nothing to do with this…
in any case I think it would be better to
Copy code
for (result in results) println(result)
anyway. no reason to build a big string in memory
e
Thanks. I wasn't really going to print the string. I just wanted to know when I need to use
System.lineSeparator()
instead of
"\n"
. My program will also be reading in a file.
d
It should be fine with just “\n”. The system will translate it for you if needed. Only caveat is if you’re writing the file in binary mode, or sending over a network.
e
it used to be common to encode files with the current encoding and system newlines, but I think the world has mostly concluded that's no longer a good idea. things need to be interchangeable so everything should be UTF-8 and
\n
👍 1
k
It depends on how old your students' versions of Windows is. In Windows 7 (and I think possibly also Windows 10), Notepad still didn't treat "\n" as a new line. Notepad on Windows 11 does.
laugh cry face palm 1
It should be fine with just “\n”. The system will translate it for you if needed. Only caveat is if you’re writing the file in binary mode, or sending over a network.
On the JVM, there's no such thing as "binary mode". That's a mode that exists in C and C++, whose standard libraries do the conversion from "\n" to "\r\n" when required for streams opened in text mode. On Windows, the console (command line window) treats the "\n" character on its own as the same as "\r\n".
d
OutputStream is binary mode, as opposed to Writer, which is text mode.
k
Oh I see, I think of it in terms of bytes vs chars, but I see that it can be thought of as binary vs text as well.
d
It’s more about “bytes” vs “codepoints decoded into bytes”