This blog post is based on my German article with the same title, published in issue 1/2026 of the Red Stack Magazin.

Measuring Software Quality

Imagine you are part of a team where code changes to a feature or bug fix branch are only merged into the develop or main branch following a review. Sometimes you are the author and sometimes one of the reviewers. I am currently part of a team that works in this way. In addition to quality assurance, knowledge sharing is also an important aspect. But how can we assess code quality?

This well-known meme by Thom Holwerda says, “The only valid measurement of code quality is WTFs per minute.” This seems to be a good metric. However, this metric does have some flaws.

• It is subjective.
• It does not provide any information about what is being assessed.
• It does not help new team members to adapt quickly.
• And it cannot be automated in a meaningful way.

Sooner or later, a team has no choice but to agree on a set of rules. They can be informal or formal. Typical coding guidelines cover topics such as naming conventions, formatting, code complexity, and language usage rules. The aim is to define and comply with quality standards relating to maintainability, reliability, performance and security. Written coding guidelines also simplify the onboarding of new team members.

Automation

Manually checking compliance with coding guidelines as part of a review is so time-consuming that no one can afford to do it properly. Therefore, we have to automate as many checks as possible. This is possible for many aspects. The rest still have to be checked manually.

In other words, we need a tool suite for automatic rule checking. dbLinter is such a tool suite. It is a new product developed and continuously improved by Grisselbav and United Codes. dbLinter uses the IslandSQL parser, which is updated quarterly with every release update of the Oracle AI Database for SQL, PL/SQL, SQL*Plus and SQLcl.

dbLinter is the successor to the decommissioned db* CODECOP suite. dbLinter consists of a central repository, a web GUI and client tools. These include a CLI, a SonarQube plugin and a VS Code extension.

Visual Studio Code Extension

The VS Code extension is compatible with all IDEs that implement the Visual Studio Code Extension API. Specifically: Visual Studio Code, Theia IDE, VSCodium, Cursor, Windsurf, Void, Kiro and Antigravity.

dbLinter for VS Code is available in both the Visual Studio Marketplace and the Open VSX Registry. Therefore, it can be conveniently installed directly from the IDE. The extension is free to use as part of the Anonymous and Starter plans (see dbLinter Pricing Plans).

It is important to note that your code is always analysed locally, meaning that it never leaves your network. The configuration is read from the central repository, enabling the client to identify the active rules and parameters. These configurations, along with others, are managed using the Web GUI.

dbLinter currently offers 187 rules. This includes all the rules from the decommissioned Trivadis PL/SQL & SQL Coding Guidelines. Figure 2 shows the configuration of my 14 favourite rules. A violation of one of these rules is a bug. There is almost no room for interpretation here. The following chapters provide two examples.

Top-N Queries with ROWNUM

The query in Listing 1 is based on the well-known EMP table owned by the database user SCOTT. It returns two rows.

select ename,
       sal,
       hiredate,
       rownum as rank
  from emp
 where rownum <= 2
 order by sal desc;

select ename,
       sal,
       hiredate,
       rownum as rank
  from emp
 where rownum <= 2
 order by sal desc;

ENAME             SAL HIREDATE         RANK
---------- ---------- ---------- ----------
ALLEN            1600 20.02.1981          2
SMITH             800 17.12.1980          1

ENAME             SAL HIREDATE         RANK
---------- ---------- ---------- ----------
ALLEN            1600 20.02.1981          2
SMITH             800 17.12.1980          1

However, the result barely meets the requirements. I would have expected the two employees with the highest salaries to be returned. Why is this not the case? The query is formulated in such a way that two rows are randomly selected and then sorted in descending order by salary. The result depends on the execution plan and the physical storage of the data.

In VS Code, rule violations are displayed under Problems (see Figure 3). There is also a Core G-3185 link that opens the rule details in the Web GUI.

Rule G-3185 in the web GUI is explained based on a similar case in the HR schema (see Figure 4). There are two solutions here. One that can be applied in all Oracle Database versions and one that works from version 12c onwards. Listing 2 shows the traditional solution, which uses an inline view. Of course, nowadays I would always prefer a solution using the row_limiting_clause.

We can also see that the rule is used in six configurations. Clicking on “(details)” opens a pop-up window in which changes can be made. This allows you to configure the rules directly from the IDE.

select e.*,
       rownum as rank
  from (
          select ename,
                 sal,
                 hiredate
            from emp
           order by sal desc
       ) e
 where rownum <= 2;

select e.*,
       rownum as rank
  from (
          select ename,
                 sal,
                 hiredate
            from emp
           order by sal desc
       ) e
 where rownum <= 2;

ENAME             SAL HIREDATE         RANK
---------- ---------- ---------- ----------
KING             5000 17.11.1981          1
SCOTT            3000 19.04.1987          2

ENAME             SAL HIREDATE         RANK
---------- ---------- ---------- ----------
KING             5000 17.11.1981          1
SCOTT            3000 19.04.1987          2

NVL vs. COALESCE

One often underestimated rule is “G-4230: Always use a COALESCE instead of a NVL command, if parameter 2 of the NVL function is a function call or a SELECT statement”. This rule is about performance, which is relevant to all of us, especially when it is poor. This is why this rule is important.

with
   function slow_function return integer is
   begin
      sys.dbms_session.sleep(0.2);
      return null;
   end slow_function;
select ename, nvl(mgr, slow_function()) as mgr
  from emp;

with
   function slow_function return integer is
   begin
      sys.dbms_session.sleep(0.2);
      return null;
   end slow_function;
select ename, nvl(mgr, slow_function()) as mgr
  from emp;

Listing 3 demonstrates a case in which the use of NVL results in an execution time of approximately 2.8 seconds. If COALESCE is used instead of NVL, the execution time is only about 0.2 seconds. The reason is that NVL always evaluates the second parameter, even if the first parameter is not null. COALESCE works differently: the second parameter is only evaluated if the first parameter is null. This performance difference originates from the fact that the EMP table contains 14 rows, but only one of these returns an empty MGR.

In this case, using COALESCE is definitely the better solution. So, should NVL always be replaced by COALESCE? No. There are two special cases:

1. NVL supports implicit data type conversion.
   select nvl(mgr, '1') from emp works, but select coalesce(mgr, '1') from emp causes an ORA-00932 error. However, implicit type conversions should be avoided anyway. The code should be adjusted accordingly.
   
2. Optimisations of NVL can lead to better execution plans.
   Such optimisations currently only exist for NVL and not for COALESCE. Therefore, it is better to continue using NVL in these cases. See The Magical NVL Function by Monika Lewandowska for an example.

Quick Fixes

dbLinter knows these special cases. It offers appropriate alternative solutions. See Figure 5.

dbLinter can apply quick fixes to different sections. For example, for a single violation of a rule, for all violations of a rule, or for all violations of all rules in the editor window.

The “@dbLinter ignore markers” are special comments used to ignore rule violations. There are various legitimate reasons for doing this. For example, in the case of false positives (dbLinter bugs) or exceptions to the rule. A comment such as -- @dbLinter ignore(G-4230): NVL forever can have the following scopes: line, statement or file, depending on where the comment is positioned.

Code Analysis and AI

The solution proposals in Figure 5, indicated by the yellow lamp symbol, are quick fixes from dbLinter. However, the last two menu options come from GitHub Copilot.

When Copilot suggests a solution to a rule violation, dbLinter provides the necessary context, including the file and the exact location of the violation, as well as the name of the violated rule. This gives Copilot access to the rule definition online, enabling it to suggest a reasonable solution in many cases. In other words, dbLinter enhances the support offered by tools such as Copilot, Cline and Windsurf.

Rules are useful for AI tools. They provide a framework that leads to better results. However, there is no guarantee that all rules will be followed. Ultimately, code generated or expanded by AI becomes part of our code base. This is why it is important to check AI-generated code according to the same rules as manually created code.

In other words, AI does not enforce standards. But dbLinter can do that.

Conclusion

Software quality is a matter of definition. dbLinter offers many rules. Not all of them are useful and applicable to every project. The dbLinter rules can therefore be seen as a large buffet. You choose what you like and what is healthy. But not too much at once. Nevertheless, there are some rules that, in my opinion, should be followed in every project. I have presented two of them in this blog post.

Install dbLinter for VS Code to identify the rules that will be most helpful for your projects. The rules in Figure 2 are certainly a good starting point.

If you have any questions, please feel free to contact me. Alternatively, you can create issues directly in the dbLinter GitHub repository.

The post Fighting Bad PL/SQL & SQL with VS Code appeared first on Philipp Salvisberg's Blog.

No, SYSDATE is not deterministic. However, it behaves very similarly to a deterministic function within an Oracle Database SQL statement.

Background

On a customer site, we used faketime on the OS to change the date and time for testing purposes. As long as you only travel forward in time, the Oracle Database behaves fine. The solution worked well for the last 8 years. However, this approach had some drawbacks, such as the need for a full-blown VM (we cannot change the time in an isolated manner within a Docker container), disabling time synchronisation processes and issues with third-party software due to failed sanity/license checks. This approach prevented us from simplifying the architecture of the testing environment.

We were exploring alternatives to travel in time only within the Oracle Database. One option was to set FIXED_DATE, and another to replace calls to SYSDATE, SYSTIMESTAMP, CURRENT_DATE, CURRENT_TIMESTAMP and LOCALTIMESTAMP with custom functions that added an offset to the current date/time. For the latter, I’d like to share some simplified test results.

But before that, let’s look at some definitions.

Definitions

Wikipedia defines a deterministic algorithm in computer science as follows:

In computer science, a deterministic algorithm is an algorithm that, given a particular input, will always produce the same output, with the underlying machine always passing through the same sequence of states. Deterministic algorithms are by far the most studied and familiar kind of algorithm, as well as one of the most practical, since they can be run on real machines efficiently.

The Oracle Database PL/SQL Language Reference defines deterministic for the deterministic_clause as follows:

• A function is deterministic if the DETERMINISTIC clause appears in either a declaration or the definition of the function.
• The DETERMINISTIC clause may appear at most once in a function declaration and at most once in a function definition.
• A deterministic function must return the same value on two distinct invocations if the arguments provided to the two invocations are the same.
• A DETERMINISTIC function may not have side effects.
• A DETERMINISTIC function may not raise an unhandled exception.
• If a function with a DETERMINISTIC clause violates any of these semantic rules, the results of its invocation, its value, and the effect on its invoker are all undefined.

How to Check?

There are two ways to check if a function is deterministic. Firstly, you can query the data dictionary like this:

select deterministic 
  from dba_procedures
 where procedure_name = 'SYSDATE';

select deterministic 
  from dba_procedures
 where procedure_name = 'SYSDATE';

DETERMINISTIC
-------------
NO

DETERMINISTIC
-------------
NO

Secondly, you can check the source code to see if it contains a deterministic_clause. SYSDATE is defined in the STANDARD package as a wrapper to the kernel function pessdt and has no deterministic_clause.

create or replace package STANDARD AUTHID CURRENT_USER is …
  function SYSDATE return DATE;
    pragma FIPSFLAG('SYSDATE', 1452); …
end;

create or replace package STANDARD AUTHID CURRENT_USER is …
  function SYSDATE return DATE;
    pragma FIPSFLAG('SYSDATE', 1452); …
end;

create or replace package body STANDARD is …
  -- Bug 1287775: back to calling ICD.
  -- Special: if the ICD raises ICD_UNABLE_TO_COMPUTE, that means we should do
  -- the old 'SELECT SYSDATE FROM DUAL;' thing.  This allows us to do the
  -- SELECT from PL/SQL rather than having to do it from C (within the ICD.)
  function sysdate return date is
    d date;
  begin
    d := pessdt;
    return d;
  exception
    when ICD_UNABLE_TO_COMPUTE then
      select sysdate into d from sys.dual;
      return d;
  end; …
end;

create or replace package body STANDARD is …
  -- Bug 1287775: back to calling ICD.
  -- Special: if the ICD raises ICD_UNABLE_TO_COMPUTE, that means we should do
  -- the old 'SELECT SYSDATE FROM DUAL;' thing.  This allows us to do the
  -- SELECT from PL/SQL rather than having to do it from C (within the ICD.)
  function sysdate return date is
    d date;
  begin
    d := pessdt;
    return d;
  exception
    when ICD_UNABLE_TO_COMPUTE then
      select sysdate into d from sys.dual;
      return d;
  end; …
end;

So, SYSDATE is clearly non-deterministic.

Interesting are the comments regarding bug 1287775 (APPSST:PERF: SERVER SIDE PL/SQL SHOULD NOT USE SQL TO OBTAIN SYSDATE). It does not seem to be entirely about performance. The last update of the bug was in mid-2021. I was unable to find out why a pessdt call may fail, and why getting SYSDATE via a query from dual should solve the problem. Anyway, it’s not essential for this blog post.

Comparing SYSDATE to a Non-Deterministic Function

Let’s create a non-deterministic function APPDATE that returns SYSDATE. Then, we compare the SYSDATE and APPDATE results in a PL/SQL cursor.

create or replace function appdate return date is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/

create or replace function appdate return date is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/

Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:28:29 2025-10-13 08:28:29
2 2025-10-13 08:28:29 2025-10-13 08:28:30
3 2025-10-13 08:28:29 2025-10-13 08:28:31
4 2025-10-13 08:28:29 2025-10-13 08:28:32
5 2025-10-13 08:28:29 2025-10-13 08:28:33


PL/SQL procedure successfully completed.

Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:28:29 2025-10-13 08:28:29
2 2025-10-13 08:28:29 2025-10-13 08:28:30
3 2025-10-13 08:28:29 2025-10-13 08:28:31
4 2025-10-13 08:28:29 2025-10-13 08:28:32
5 2025-10-13 08:28:29 2025-10-13 08:28:33


PL/SQL procedure successfully completed.

You see, the results are different except for the first row. We had to set the fetch array size to one to ensure the sleep call on line 25 affects each fetched record. Otherwise, you would see the effect between the batch of records defined by the default fetch size.

Comparing SYSDATE to a Deterministic Function

Let’s make the APPDATE function deterministic and rerun the script.

create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/

create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/

Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:29:00 2025-10-13 08:29:00
2 2025-10-13 08:29:00 2025-10-13 08:29:00
3 2025-10-13 08:29:00 2025-10-13 08:29:00
4 2025-10-13 08:29:00 2025-10-13 08:29:00
5 2025-10-13 08:29:00 2025-10-13 08:29:00


PL/SQL procedure successfully completed.

Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:29:00 2025-10-13 08:29:00
2 2025-10-13 08:29:00 2025-10-13 08:29:00
3 2025-10-13 08:29:00 2025-10-13 08:29:00
4 2025-10-13 08:29:00 2025-10-13 08:29:00
5 2025-10-13 08:29:00 2025-10-13 08:29:00


PL/SQL procedure successfully completed.

Now we have the same result. SYSDATE is evaluated once for the whole query as the deterministic function APPDATE. There is obviously some special treatment of SYSDATE in the Oracle Database code for SQL statements. It handles it similarly to a deterministic function or a bind variable. That’s good. This matches the read consistency concepts. We do not want to get different results of SYSDATE in a single query.

But how does it behave in PL/SQL?

SYSDATE in PL/SQL

24 years ago, someone posted a puzzle in the forum of dbasupport.com that covered the same topic. I snitched the code from there and adapted it slightly.

set serveroutput on size unlimited
declare
   i binary_integer := 0;
begin
   while sysdate = sysdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

set serveroutput on size unlimited
declare
   i binary_integer := 0;
begin
   while sysdate = sysdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

Left the loop after 2957099 iterations


PL/SQL procedure successfully completed.

Left the loop after 2957099 iterations


PL/SQL procedure successfully completed.

It appears to be an endless loop, but it is not. The two SYSDATE calls are evaluated independently, and eventually they return different results. Of course, the number of iterations varies. Therefore, the algorithm could be used as a kind of random number generator.

APPDATE in PL/SQL

Let’s use the deterministic variant of the APPDATE function in the same script.

create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

Function APPDATE compiled

declare 
*
ERROR at line 1:
ORA-01426: numeric overflow
ORA-06512: at line 5

https://docs.oracle.com/error-help/db/ora-01426/


More Details :
https://docs.oracle.com/error-help/db/ora-01426/
https://docs.oracle.com/error-help/db/ora-06512/

Function APPDATE compiled

declare 
*
ERROR at line 1:
ORA-01426: numeric overflow
ORA-06512: at line 5

https://docs.oracle.com/error-help/db/ora-01426/


More Details :
https://docs.oracle.com/error-help/db/ora-01426/
https://docs.oracle.com/error-help/db/ora-06512/

Luckily, the maximum value of a binary integer is 2,147,483,647. With a NULL statement on line 12, the script would run endlessly. It looks like the APPDATE function is evaluated only once within the WHILE statement.

We told the PL/SQL compiler that the APPDATE function is deterministic. So the same input (none in this case) always produces the same output. This is a lie. However, the compiler is a nice component and trusts us. So it can come up with some optimisations to improve the runtime of our code and produce a solution that calls APPDATE only once. And boom, we have an endless loop.

Let’s verify this.

PLSQL_OPTIMIZE_LEVEL

The PL/SQL compiler knows the following four optimisation levels:

• 0 = Oracle Database 9i style with some minor improvements
• 1 = Various optimisations, does not move code, therefore required when debugging PL/SQL
• 2 = More optimisations, including moving code around, this is the default in 19c/23ai
• 3 = Even more optimisations

The documentation leaves us in the dark about what each level does exactly. However, one thing is sure. The higher the level, the more aggressive the optimisation.

So let’s try the previous code with level 0.

alter session set plsql_optimize_level = 0;
create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

alter session set plsql_optimize_level = 0;
create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

Session altered.


Function APPDATE compiled

Left the loop after 3224661 iterations


PL/SQL procedure successfully completed.

Session altered.


Function APPDATE compiled

Left the loop after 3224661 iterations


PL/SQL procedure successfully completed.

Ha, this worked. No endless loop. We get a similar result with level 1. However, levels 2 and 3 lead to an endless loop.

This example should illustrate that we should not lie to the compiler. Sooner or later, another optimisation in a newer version could break our code.

Conclusion

In fact, the previous paragraph could be a good conclusion. However, at the beginning of this post, I mentioned a real use case where we were evaluating an alternative to the faketime library. We opted for FIXED_DATE because it is simple to apply and worked for the application under test. The application uses SYSDATE exclusively for business-relevant dates and times. SYSTIMESTAMP, CURRENT_DATE, CURRENT_TIMESTAMP and LOCALTIMESTAMP, which are unaffected by FIXED_DATE, are used only for logging purposes.

The idea of providing a custom function that returns SYSDATE with a centrally defined offset might have worked in our case. But providing a solution that behaves like SYSDATE is much more challenging than I thought. We would need something that is evaluated once in a SQL statement and per call in other cases. Passing SYSDATE as a default parameter to a deterministic function does the trick. Either way, I’m glad we opted for the simpler solution, which meant there was no need to change the code base.

The post Is SYSDATE Deterministic? #JoelKallmanDay appeared first on Philipp Salvisberg's Blog.

Today I proudly announce that the Joint Venture between United Codes and Grisselbav released the initial version of the dbLinter Rules Repository website. This is the first publicly available component of the dbLinter tool suite.

What is dbLinter?

dbLinter is a suite for checking and improving the quality of database applications. Quality is assessed using static code analysis and database queries based on a configuration. A configuration is primarily centrally managed. It contains file patterns, rules, validators, SQL-based tests, parameters, and connect information for read-only database access within checks and tests.

Is it Free?

dbLinter is a commercial and subscription-based product. However, there are two free subscription plans foreseen. Anonymous without registration and Free requiring registration with a valid email address. You need a login to manage configurations.

And of course, access to the dbLinter Rules Repository website is also free.

What Are the Rules Based on?

Most of the rules are taken over from the decommissioned Trivadis PL/SQL & SQL Coding Guidelines. The origin is documented per rule under the Reference section. See for example G-1080: Avoid using the same expression on both sides of a relational comparison operator or a logical operator. This rule exists in 4 different rule repositories.

Over 180 Rules – This is Ridiculous!

You do not need to enable all rules. I compare it to a breakfast buffet. You pick what you like and how much you want.

Furthermore, not all rules have the same severity. The most important rules are marked as Blocker. Pick some of these to start with.

What’s Next?

Coding guidelines are really helpful, especially if you can use them to review your code automatically while it’s being developed in your favourite IDE. Of course you want them also as part of a CI/CD pipeline. However, finding problems while typing code is far more efficient.

Therefore the next component will be a VS Code extension. Here’s an example of how it will look like:

Stay tuned.

The post dbLinter Rules Repository appeared first on Philipp Salvisberg's Blog.