Article
· Sep 25 3m read

CodeInspector: Automating Custom Code Validation

Hi everyone,

In this article, I’m excited to introduce CodeInspector, a tool designed to simplify code validation by applying custom rules tailored to your development requirements. Whether you're managing a large codebase or working in an agile environment, CodeInspector helps ensure code quality by offering flexibility and adaptability to specific project needs.

Motivation

The idea behind CodeInspector was to build a tool that is both easy to implement and adaptable to different business contexts. By allowing teams to define their own validation rules, CodeInspector empowers developers to meet specific code quality standards without sacrificing flexibility. Its simplicity ensures that any team member can quickly configure and start using the tool to enforce consistent coding practices.

Features

  • Package and Class Validation: CodeInspector analyzes and validates packages and classes based on predefined custom rules.
  • Detailed Reports: It generates comprehensive issue reports that can be viewed directly in the console or returned as structured JSON for further processing.

First Steps

  1. Installation: The tool is available on the InterSystems Open Exchange as CodeInspector.
  2. Running the Application: Follow the instructions in the README file to build and start the Docker container. The application runs seamlessly inside a Docker container.
  3. Sample and Rules:
    • In the project folder, you'll find a sample directory with an example class.
    • Additionally, in the codeInspector.rules.examples folder, you’ll find two example validation rules:
      • Example Rule 1: Validates if a class does not exist in the environment.
      • Example Rule 2: Validates if a method exceeds 50 lines of code.
  4. Postman Project: The Postman collection for testing the API has been added to the /iris-dev-codeinspector/collectionPostman/CodeInspector.postman_collection.json folder.

Rest API - CodeInspector JSON Report

API Parameters

The API is available at http://localhost:9091/codeinspector/ and accepts the following parameters:

  • namespace: (required) Specifies the namespace in which the validation will be executed.
  • packages: (required) This parameter must include the names of the packages to be analyzed, separated by commas.
  • ignored: Allows you to provide a comma-separated list of package names to be excluded from the validation process.

Postman Collection

You can find the Postman Collection export in the /iris-dev-codeinspector/collectionPostman/ folder. Import CodeInspector.postman_collection.json into Postman to run API tests.

 

Console Report

To run a validation check from the console, open a terminal and execute:

Do ##class(codeInspector.Main).Execute("sample")

This will trigger the sample validation against the specified class and display the results in the console.

 

Thank you for exploring CodeInspector. At the end of the README document, you’ll find some ideas for future improvements, and I’m always open to new suggestions. I look forward to your feedback and any contributions you’d like to make!

Discussion (3)1
Log in or sign up to continue

Overall a nice idea.
the package still needs some polishing to convince

suggestion1:  fix issue to build clean docker
suggestion2:  re-enable Start+Stop message so uses see it was moving
suggestion3:  show which class you check , kind of work log
suggestion4:  also step into sub-packages e.g. not just rcc but also rcc.unittests. codeinspector could be a good start
sugesstion5: allow also MAC, INT, INC code to be checked 

First of all, it’s a pleasure to receive your suggestions. I’ve always followed your posts in the community, and it’s an honor to have you here helping me with this project.

suggestion1

  • I’ll try to resolve this before the end of the contest.

suggestion2

  • I’ll make this adjustment for the console output. As for the JSON output, I need to think about whether it’s possible.

suggestion3

  • This makes a lot of sense. I’ll implement it in the JSON report and at the end of the console output.

suggestion4

  • The tool already inspects sub-packages, but after reading the documentation, I realize that this wasn’t made clear enough.

suggestion5

  • Great idea! I’ll add it as a future enhancement.