G-0010 Always format database code consistently.

Severity Warning Guideline only Free

General

Rule Details

SonarQube Severity: Minor
Quality Area: Maintainability
Fixing Time: 1 min Local-easy
Database Support: OracleDB (v7.3.4 +)
PostgreSQL (v7.0.3 +)
Profile: Strict
Available Since: Sep 8, 2026

Reason

Consistent formatting makes database code easier to read, understand and review. It reduces the cognitive effort required to navigate unfamiliar code. It also prevents personal formatting preferences from producing unnecessary differences between files.

Using a deterministic formatter also ensures that version control diffs focus on meaningful changes, making reviews simpler and changes easier to track over time.

Rules

Rule	Description
1	Keywords and identifiers are written in lowercase. It used to be good practice to use uppercase keywords and lowercase identifiers to help visualise code structure. But practically all editors support more or less advanced colour highlighting, similar to the examples in these guidelines. Hence, we are now recommending all lowercase, as this is easier and faster for the brain to process. You may choose to prefer the old rule; however, it is important to always be consistent, for example, keywords always in uppercase and identifiers always in lowercase. Related parameters: `FormatterKeywordCase` and `FormatterIdentifierCase`.
2	3-space indentation. Tabs are not used because the indentation depends on the editor configuration. We want to ensure that the code looks the same, independent of the editor used. Hence, no tabs. But why not use 8 spaces? That's the traditional value for a tab. When writing a package function, the code in the body has an indentation of 3. That's 24 characters as a starting point for the code. We think it's too much. Especially if we try to keep a line below 100 or 80 characters. Other good options would be 2 or 4 spaces. We settled for 3 spaces as a compromise. The indentation is still clearly visible, but doesn't use too much space. Related parameters: `FormatterTabSize` and `FormatterInsertSpaces`.
3	One command per line. Every SQL command, PL/SQL or PL/pgSQL statement must start on a new line. Related parameters: `FormatterBlankLinesBetweenStatementMode`, `FormatterMinPreviousStatementLines` and `RemoveDuplicateBlankLines`.
4	Keywords `else`, `elsif`, `end`, `when` on a new line. Related parameters: `FormatterLoopKeywordOnSeparateLine`, `FormatterJoinOnKeywordOnSeparateLine` and `FormatterThenKeywordOnSeparateLine`.
5	Trailing Commas. Related parameters: `FormatterLeadingComma`, `FormatterSpaceAfterComma` and `FormatterSpaceAfterCommaInDatatypes`.
6	Call parameters aligned, operators aligned, values aligned. Related parameters: `FormatterAlignNamedArguments`, `FormatterAlignTypeDeclarations`, `FormatterAlignColumnAliases` and `FormatterAlignTableAliases`
7	SQL keywords are right-aligned within a SQL command. Related parameter: `FormatterDmlLayoutStyle` .

Example

Non-Compliant Example

create or replace package body employee_api is
procedure set_salary(in_employee_id in integer)is
co_employee_id constant employees.employee_id%type:=in_employee_id;

cursor c_employees(p_employee_id in employees.employee_id%type)is
select last_name
,first_name
,salary
from employees
where employee_id=p_employee_id
order by last_name
,first_name;

r_employee c_employees%rowtype;
l_new_salary employees.salary%type;
begin
open c_employees(p_employee_id=>co_employee_id);
fetch c_employees into r_employee;
close c_employees;

new_salary(in_employee_id=>in_employee_id
,out_salary=>l_new_salary);

-- Check whether salary has changed
if r_employee.salary<>l_new_salary then
update employees
set salary=l_new_salary
where employee_id=in_employee_id;
end if;
end set_salary;
end employee_api;

Compliant Solution - ★★★★★

create or replace package body employee_api is
   procedure set_salary(in_employee_id in integer) is
      co_employee_id constant employees.employee_id%type := in_employee_id;

      cursor c_employees(p_employee_id in employees.employee_id%type) is
         select last_name,
                first_name,
                salary
           from employees
          where employee_id = p_employee_id
          order by last_name,
                first_name;

      r_employee   c_employees%rowtype;
      l_new_salary employees.salary%type;
   begin
      open c_employees(p_employee_id => co_employee_id);
      fetch c_employees into r_employee;
      close c_employees;

      new_salary(in_employee_id => in_employee_id,
                 out_salary     => l_new_salary);

      -- Check whether salary has changed
      if r_employee.salary <> l_new_salary then
         update employees
            set salary = l_new_salary
          where employee_id = in_employee_id;
      end if;
   end set_salary;
end employee_api;

Parameters

Use parameters to customize the rule to your needs.

Parameter	Description	Default Value
DisableAllQuickFix	Comma-separated list of rules for which a quick fix should not be applied to all the problems in a file.	Core G-3130
FormatterAlignAssignments	Align assignment operators (:=) vertically. Valid: true, false.	true
FormatterAlignColumnAliases	Align column aliases vertically. Valid: true, false.	true
FormatterAlignCommentAsterisks	Align existing leading asterisks in multiline comments. Valid: true, false.	true
FormatterAlignEqualityOperators	Align equality operators (=) vertically. Valid: true, false.	false
FormatterAlignLogicalOperatorsWithKeywords	Align logical operators (AND/OR) with SQL keyword columns. Valid: true, false.	true
FormatterAlignNamedArguments	Align named arguments (=>) vertically. Valid: true, false.	true
FormatterAlignTableAliases	Align table aliases vertically. Valid: true, false.	false
FormatterAlignTrailingComments	Align trailing single-line comments within the same SQL statement. Valid: true, false.	false
FormatterAlignTypeDeclarations	Align type declarations vertically. Valid: true, false.	true
FormatterBlankLinesBetweenStatementMode	Strategy for inserting blank lines between statements. Valid: never, always, by_statement_lines.	by_statement_lines
FormatterDmlStyle	Style of DML statements. Valid: dedicated_keywords_lines, right_aligned_keywords, left_aligned_keywords_align_continuations, left_aligned_keywords_indent_continuations, padded_keywords.	right_aligned_keywords
FormatterFormattingStrategy	Overall formatting strategy. Valid: lightweight, normalised_compact, normalised_expanded.	lightweight
FormatterIdentifierCase	Case transformation policy for identifiers. Valid: upper, lower, initcap, wordcap, preserve.	preserve
FormatterInListStyle	Parentheses style for IN-lists. Valid: block, block_next_line, hanging.	block
FormatterInsertFinalNewLine	Insert a newline character at the end of the file if one does not exist. Valid: true, false.	true
FormatterInsertSpaces	Use spaces rather than tabs for indentation. Valid: true, false.	true
FormatterJoinOnKeywordOnSeparateLine	Place the ON keyword of join clauses on a separate line. Valid: true, false.	true
FormatterKeywordCase	Case transformation policy for keywords. Valid: upper, lower, initcap, wordcap, preserve.	preserve
FormatterLabelOnSeparateLine	Place PL/SQL labels on a separate line. Valid: true, false.	true
FormatterLeadingComma	Place commas at the beginning of continuation lines. Valid: true, false.	false
FormatterLeadingConcatenationOperator	Place the concatenation operator \|\| at the beginning of continuation lines. Valid: true, false.	true
FormatterLeadingLogicalOperator	Place logical operators (AND/OR) at the beginning of continuation lines. Valid: true, false.	true
FormatterLoopKeywordOnSeparateLine	Place the LOOP keyword on a separate line. Valid: true, false.	false
FormatterMaxLineSize	Maximum line length in characters. Valid: 40 to 1000.	120
FormatterMinStatementLines	Minimum number of lines in a statement before blank lines are added around the statement when mode is by_statement. Valid: 1 to 1000.	1
FormatterParameterDeclarationStyle	Parentheses style for parameter declarations. Valid: block, block_next_line, hanging.	block
FormatterPreserveSingleLineCaseExpressions	Preserve case expressions that fit on a single line. Valid: true, false	true
FormatterPreserveSingleLineStatements	Preserve statements that fit on a single line. Valid: true, false.	true
FormatterRemoveDuplicateBlankLines	Remove duplicate blank lines. Valued: true, false.	true
FormatterShortExpressionSize	Maximum length of a short expression in characters. Valid 1 to 1000.	60
FormatterSpaceAfterComma	Insert a space after commas. Valid: true, false.	true
FormatterSpaceAfterCommaInDatatypes	Insert a space after commas in datatype declarations. Valid: true, false	false
FormatterSpaceAroundOperators	Insert spaces around operators. Valid: true, false.	true
FormatterSpaceAroundParentheses	Add spaces before opening and after closing parentheses. Valid: true, false.	true
FormatterSpaceBeforeFunctionParentheses	Insert a space between a function/procedure/method name and its opening parenthesis. Valid: true, false.	false
FormatterSpaceInsideParentheses	Add spaces after opening and before closing parentheses. Valid: true, false.	false
FormatterSubqueryStyle	Parentheses style for subqueries.Valid: block, block_next_line, hanging.	block
FormatterTabSize	Number of spaces for an indentation level (tab). Valid: 2 to 8.	3
FormatterThenKeywordOnSeparateLine	Place the THEN keyword on a separate line. Valid: true, false.	false
FormatterTrimFinalNewlines	Trim all newlines after the final newline at the end of the file. Valid: true, false.	true
FormatterTrimLeadingNewlines	Trim all newlines at the start of the file before the first content line. Valid: true, false.	true
FormatterTrimTrailingWhitespace	Trim trailing whitespace on a line. Valid: true, false.	true

References

similar to Trivadis Code Style
Describes formatting rules on a higher level.
similar to Trivadis PL/SQL Formatter Settings
GitHub repository with formatter settings for Trivadis Code Style