Hi community!

I want to introduce you a new powerful feature from our static code analyzer objectscriptQuality. 

Each time a new IRIS version is released, you need to prepare a roadmap for migration in which you need to spend a lot of time on testing to find where your code is not accomplishing with the newer version. Or maybe you need your code to be compatible with multiple IRIS or Caché versions.

You can now simplify the task running the analysis for the different IRIS and Caché database versions, so you will get the failing code before you start to test.

objectscriptQuality allows you

Since some months ago we automatized source code analysis for projects on Github, so anyone with an open source project can have its code analyzed with no cost.

You only need to create the file ".github/workflows/objectscript-quality.yml" in your project with following contents:

name: objectscriptquality
on: push

jobs:
  linux:
    name: Linux build
    runs-on: ubuntu-latest

    steps:
    - name: Execute ObjectScript Quality Analysis
      run: wget https://raw.githubusercontent.com/litesolutions/objectscriptquality-jenkins-integration/master/iris-community-hook.sh && sh ./iris

Error management on InterSystems languages has been evolving along time. Next, we will show the different implementations and why you should use the TRY/THROW/CATCH mechanism.

You can read official error recommendations here.

InterSystems will not mark as obsoletes the non-recommended error management methods to allow giving support to legacy applications. We recommend using tools like objectscriptQuality to detect that legacy unrecommended usage along with many other possible issues and bugs.

$ZERROR

$ZERROR is the older error management mechanism, supporting different implementations fro

Currently, many of you has some knowledge about CachéQuality (which is being renamed to objectscriptQuality) for analyzing objectscript code using the rules we have predefined. Probably you have tested it and have found too many warnings in your projects. I'm sure there are issues which are really important for you and some others which you would like to dismiss.

We have more than 90 rules to test different code situations and warn about a problem or a possible bug in code. But using all the rules is not always the desired situation (as I said before, maybe some rules are not useful for your

Hi! We have received a request to create a new rule on CachéQuality to identify when a developer uses double quotes (" ") within any SQL statement.

We have been asked many times about SQL validation rules, and we would like to open a debate to allow everyone discuss what would you like to be checked on a SQL statement.

Current examples are for basic situations:

• Using SQL.Statement class:

Set stmt = ##CLASS(%SQL.Statement).%New()
Set query = "Select Val1, Val2 FROM Table WHERE Val1=""SomeCondition"""

• Using embedded SQL

&SQL(SELECT Val1, Val2
                INTO :val1, :val2
      

Hi Community!

We are proud to annouce our latest release of CachéQuality to help you to find and solve coding errors, refactoring, help to follow you coding guidelines, etc. You can check the latest release notes here.

As a developer, usually I'm concerned about how my code health is, and how the other coders code can affect to my own work.  And I'm quite sure most of us feel very similar.

In our company we use a Static Code Analysis tool to analyze code for different languages to ensure we are writing high quality and easily maintainable code by following a few best practices in terms of code structure and content. And the question was: why should be different for Caché ObjectScript language?