Skip to content

[Analyzer proposal]: Simplify calls to string.Substring and Memory/Span.Slice #68946

Closed
dotnet/roslyn-analyzers
#6814

Description

@GrabYourPitchforks

Inspired by Steve's comment at #68937 (comment).

We should consider promoting usage of Substring/Slice(offset) over Substring/Slice(offset, length) for "slice to the end of the buffer" scenarios. In both cases it makes the code a little easier to read and is less error-prone since it doesn't require the caller to get the length check correct. And for Slice specifically, it will result in slightly better codegen.

// Detect these patterns
someString.Substring(expression, someString.Length - expression);
someMemory.Slice(expression, someMemory.Length - expression);
someSpan.Slice(expression, someSpan.Length - expression);

// And replace them with these:
someString.Substring(expression);
someMemory.Slice(expression);
someSpan.Slice(expression);

Any analyzer / fixer would need to be a little smart and ensure that evaluating neither this nor expression has side effects, otherwise changing the number of occurrences from 2 to 1 would result in an observable behavioral change. This means that we might not be able to trigger the analyzer / fixer if this or expression contains a property accessor, unless we can reason that the property accessor is a dumb field wrapper.

The prevalent patterns that I saw in #68937 were:

value.Substring(local, value.Length - local);
value.Substring(local1 + local2, value.Length - local1 - local2);
value.Substring(local1 + local2, value.Length - (local1 + local2));
value.Substring(field, value.Length - field);
value.Substring(field + const, value.Length - field - const);
value.Substring(field + const, value.Length - (field + const));

Suggested category: Maintainability
Suggested severity: Info

Activity

  1. ghost added
    untriagedNew issue has not been triaged by the area owner
    on May 6, 2022
  2. added
    api-suggestionEarly API idea and discussion, it is NOT ready for implementation
    on May 6, 2022
  3. carlossanlop commented on May 12, 2022

    @carlossanlop
    Contributor

    @GrabYourPitchforks your proposal looks ready for review, especially since you already found a bunch of cases in #68937 .

  4. added
    api-ready-for-reviewAPI is ready for review, it is NOT ready for implementation
    and removed
    api-suggestionEarly API idea and discussion, it is NOT ready for implementation
    untriagedNew issue has not been triaged by the area owner
    on May 12, 2022
  5. added this to the 7.0.0 milestone on May 12, 2022
  6. terrajobst commented on Jun 23, 2022

    @terrajobst
    Contributor

    Video

    • Looks good as proposed

    Category: Maintainability
    Severity: Info

  7. added
    api-approvedAPI was approved in API review, it can be implemented
    and removed
    api-ready-for-reviewAPI is ready for review, it is NOT ready for implementation
    on Jun 23, 2022
  8. modified the milestones: 7.0.0, 8.0.0 on Jul 6, 2022
  9. added
    help wanted[up-for-grabs] Good issue for external contributors
    on Nov 15, 2022
  10. buyaa-n commented on Nov 15, 2022

    @buyaa-n
    Contributor

    Estimates:

    Analyzer: Small
    Fixer: Small

  11. TonyValenti commented on Dec 4, 2022

    @TonyValenti

    Instead of using Substring, would it be better to use the slice syntax?

    Ie. String[x..] ?

  12. dstarosta commented on Jul 21, 2023

    @dstarosta

    I wish it would also report a missing check for length when the optimization is not applicable. That is one of the biggest sources of bugs I have seen with .NET in my experience.

  13. cybertyche commented on Jul 22, 2023

    @cybertyche

    Instead of using Substring, would it be better to use the slice syntax?

    Ie. String[x..] ?

    Given that there is already another analyzer that does that particular recommendation (move from string.Substring(foo) to string[foo..]) it does seem prudent to go directly to the slice syntax rather than create a syntax that another analyzer is just going to flag.

  14. cybertyche commented on Jul 23, 2023

    @cybertyche

    On the other hand, the rule that suggests the slice syntax as a simplification of substring is an IDE not a CA warning. It might therefore be good to do it in two parts, one that removes the second parameter (CA) and one that then suggests moving to the slice syntax (IDE).

  15. modified the milestones: 8.0.0, Future on Jul 24, 2023
  16. mpidash commented on Jul 25, 2023

    @mpidash
    Contributor

    I would like to work on this analyzer if that is ok.

  17. carlossanlop commented on Jul 25, 2023

    @carlossanlop
    Contributor

    @mpidash thank you for offering your help! I'm assigning the issue to you.

    If you have any questions, feel free to ask @mavasani, @Youssef1313, @buyaa-n or I for help.

  18. removed
    help wanted[up-for-grabs] Good issue for external contributors
    on Sep 21, 2023
  19. ghost locked as resolved and limited conversation to collaborators on Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

api-approvedAPI was approved in API review, it can be implementedarea-System.Runtimecode-analyzerMarks an issue that suggests a Roslyn analyzercode-fixerMarks an issue that suggests a Roslyn code fixer

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions