Products
In-IDE
IDE extension that lets you fix coding issues before they exist!
Discover SonarLint
SaaS
Setup is effortless and analysis is automatic for most languages
Discover SonarCloud
Self-Hosted
Fast, accurate analysis; enterprise scalability
Discover SonarQube

Secrets
ABAP
Ansible
Apex
AzureResourceManager
C
C#
C++
CloudFormation
COBOL
CSS
Dart
Docker
Flex
Go
HTML
Java
JavaScript
JCL
Kotlin
Kubernetes
Objective C
PHP
PL/I
PL/SQL
Python
RPG
Ruby
Scala
Swift
Terraform
Text
TypeScript
T-SQL
VB.NET
VB6
XML

ABAP static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your ABAP code

Filtered: 18 rules found

performance

Having SQL "SELECT" statements without "WHERE" conditions is security-sensitive
Security Hotspot
"JOIN" should be used instead of nested "SELECT" statements
Code Smell
"SELECT INTO TABLE" should be used
Code Smell
"EXIT" and "CHECK" statements should not be used in "SELECT" loops
Code Smell
SQL "LIKE" clauses should not start with wildcard characters
Code Smell
"SORTED" or "HASHED" internal tables should be accessed with a key
Code Smell
A SQL "SELECT" statement should not involve too many tables
Code Smell
Native SQL should not be statically embedded
Code Smell
To "SELECT", "INSERT" or "DELETE" several lines in databases, internal tables should be used in place of loop control structure
Code Smell
SQL "DISTINCT" operator should not be used to prevent bypassing the SAP buffering
Code Smell
Columns to be read with a "SELECT" statement should be clearly defined
Code Smell
Subqueries and "JOIN" clauses should not be used
Code Smell
Subroutine parameters should be passed by reference rather than by value
Code Smell
SQL EXISTS subqueries should not be used
Code Smell
SQL aggregate functions should not be used to prevent bypassing the SAP buffer
Code Smell
Duplications in driver tables should deleted before the tables are used
Code Smell
Mass operations should be used with internal tables instead of loops
Code Smell
The "LIKE" operator should be used very carefully in SQL "WHERE" condition
Code Smell

"SORTED" or "HASHED" internal tables should be accessed with a key

Code Smell

MajorSonarSource default severity
click to learn more

performance

Internal tables can quickly become a source of performance problems if not accessed correctly, SORTED and HASHED tables should always be accessed with the appropriate key or partial key.

Noncompliant Code Example

Compliant Solution

READ TABLE it INTO work_area INDEX 1.

Available In:

Catch issues on the fly,
in your IDE

Detect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

Developer
Edition

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Sonar helps developers write Clean Code.
Privacy Policy | Cookie Policy

In-IDE

SaaS

Self-Hosted