Open EvgenyPrikhodko opened 9 months ago
@EvgenyPrikhodko As many would not know the connection between this issue and hte last one raised, could you please flesh this out more to indicate:
Yes, ideally this would cover the root issue that StringBuilder.Append
exclusively uses Environment.NewLine
and that users may be trivially unaware of this, so if they do sb.Split('\n')
or sb.Split("\r\n")
which can differ on some platforms (miss splitting the \r
on Windows and miss all lines on Unix).
Then explain that the proposal is to add an analyzer which likes for such patterns and recommends using Environment.NewLine
instead.
It should acknowledge that there is the potential for false positives
(user did want to split on just the specified newline, even if different from the platform default) and for false negatives
(user was unaware of the string shape, but was using the right API, so changing would break).
the programmer is waiting for a lonely answer when we talk about different operating systems
@tannergooding critical error
@EvgenyPrikhodko Your posts are quite cryptic. Could you please provide more clarifying details when you make them? Thanks! :)
@EvgenyPrikhodko Your posts are quite cryptic. Could you please provide more clarifying details when you make them? Thanks! :)
@EvgenyPrikhodko Your posts are quite cryptic. Could you please provide more clarifying details when you make them? Thanks! :)
@EvgenyPrikhodko i'm referring to https://github.com/dotnet/runtime/issues/98123#issuecomment-1932832824 and https://github.com/dotnet/runtime/issues/98123#issuecomment-1932835418.
You have also not clearly and reasonably answered: https://github.com/dotnet/runtime/issues/98123#issuecomment-1932812190
For reference, the original discussion is in https://github.com/dotnet/runtime/issues/98116
... part of the problem here is that generally you shouldn't be manually splitting lines via string.Split()
. For most simple cases, a StringReader
is the better choice. That's assuming you can't read lines from whatever originating stream (such as directly reading lines from a file).
This is especially important if you're parsing a file, because you don't actually have a guarantee about the line endings in the file (outside of some custom file format, I suppose, but you shouldn't be using those if you could help it). Especially for interoperability concerns, if you're parsing text files you need to assume that you will encounter either style. So while we could(/should?) write an analyzer for flagging on platform specific string.Split("\r\n")
, doing string.Split(Environment.NewLine)
is liable to fail.
The same holds true when writing lines as well, to an extent. You shouldn't be using string.Join()
to concatenate lines, instead using StringBuilder.AppendLine()
or using StreamWriter.WriteLine()
.
@EvgenyPrikhodko As many would not know the connection between this issue and hte last one raised, could you please flesh this out more to indicate:
- what the problem is that you would like a solution for.
- what the proposed solution is here that you're looking for.
Programmer may come to an existing project and not notice when there is a lot of code that somewhere in the solution there is a StringBuilder that is platform-dependent.
Net is positioned as a cross-platform solution, or Net gives a warning, or solves problems on its own. But, get different results in different operating systems — this is bad.
Net is positioned as a cross-platform solution, or Net gives a warning, or solves problems on its own. But, get different results in different operating systems — this is bad.
There are a large number of platform-dependent behaviors. The one people tend to run into first is formatting data.
Being cross-platform doesn't necessarily mean "behaves the exact same on every platform". It means "can account for the differences between platforms". Files do not always come from the current OS, and thus may not have the line endings you expect. Writing anything that parses "lines" should account for that possibility.
@EvgenyPrikhodko As many would not know the connection between this issue and hte last one raised, could you please flesh this out more to indicate:
- what the problem is that you would like a solution for.
- what the proposed solution is here that you're looking for.
Programmer may come to an existing project and not notice when there is a lot of code that somewhere in the solution there is a StringBuilder that is platform-dependent.
Net is positioned as a cross-platform solution, or Net gives a warning, or solves problems on its own. But, get different results in different operating systems — this is bad.
Thanks. Can you please update the op?
Tagging subscribers to this area: @dotnet/area-system-globalization See info in area-owners.md if you want to be subscribed.
Author: | EvgenyPrikhodko |
---|---|
Assignees: | - |
Labels: | `api-suggestion`, `area-System.Globalization`, `untriaged`, `needs-area-label` |
Milestone: | - |
Tagging subscribers to this area: @dotnet/area-system-runtime See info in area-owners.md if you want to be subscribed.
Author: | EvgenyPrikhodko |
---|---|
Assignees: | - |
Labels: | `api-suggestion`, `area-System.Globalization`, `area-System.Runtime`, `untriaged`, `needs-area-label` |
Milestone: | - |
Background and motivation
The programmer may not know about the operation of strings
API Proposal
*
API Usage
Alternative Designs
cross-platform
Risks
No response