== Why is this an issue?

The ``++READ TABLE ... WITH KEY ...++`` statement performs a linear search of ``++STANDARD++`` tables, which is very inefficient in most cases.


This rule raises an issue when a ``++READ TABLE ... WITH KEY ...++`` statement does not finish with ``++BINARY SEARCH++``. No issue will be raised for ``++HASHED++`` and ``++SORTED++`` tables.


=== Noncompliant code example

[source,abap]
----
TYPES BEGIN OF t_mytable, 
    myfield TYPE i
END OF t_mytable. 

DATA myworkarea TYPE t_mytable.

DATA mytable TYPE STANDARD TABLE OF t_mytable.

SORT mytable BY myfield.

READ TABLE mytable 
    WITH KEY myfield = 42
    INTO myworkarea. " Noncompliant
----


=== Compliant solution

[source,abap]
----
TYPES BEGIN OF t_mytable, 
    myfield TYPE i
END OF t_mytable. 

DATA myworkarea TYPE t_mytable.

DATA mytable TYPE STANDARD TABLE OF t_mytable.

SORT mytable BY myfield.

READ TABLE mytable 
    WITH KEY myfield = 42
    INTO myworkarea
    BINARY SEARCH. " Compliant

DATA my_hashed_table TYPE HASHED TABLE OF t_mytable 
    WITH UNIQUE KEY myfield.

DATA my_sorted_table TYPE SORTED TABLE OF t_mytable 
    WITH UNIQUE KEY myfield.

READ TABLE my_hashed_table 
    WITH KEY myfield = 42
    INTO myworkarea. " Compliant

READ TABLE my_sorted_table 
    WITH KEY myfield = 42
    INTO myworkarea. " Compliant
----

ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Add "BINARY SEARCH" to this "READ" statement.


endif::env-github,rspecator-view[]