Using Git Hooks to Ensure Code Quality.

To maintain high code quality in your repository, it's helpful to perform static code analysis before committing changes. In this blog post, we’ll show how you can automate this process for MATLAB code in combination with a Git repository.

We'll integrate CC4M (Code Checker for MATLAB) into a Git pre-commit hook to automatically verify code compliance against the guidelines before allowing it to be committed. Here’s how it works:

• When a commit is initiated, the Git pre-commit hook executes CC4M on the relevant MATLAB files.

• If CC4M reports no violations, the commit proceeds normally.

• If violations are detected, a report is generated and presented to the user; and the user is prompted in the Git client: "Violations found, do you still want to commit? (y/N)". Answer either

  • N to cancel the commit to address the reported issues, or
  • y to proceed with the commit despite the detected violations.

In the sections below, we’ll walk through setting up the pre-commit hook and the script that triggers CC4M. The example is created on a Windows machine. Both the pre-commit bash script and the called MATLAB function are available from GitHub.

Updated version

In an earlier version of this blog, a direct call to CC4M using MATLAB was used in the pre-commit hook. This approach requires a start of MATLAB and a start of CC4M with every commit, which is a huge performance hit - even with the reduced MATLAB startup times since 2025. Hence in the update of this blog, we introduce an approach were the pre-commit hook reuses the same MATLAB session with every commit. This optionally is even the session you are currently using.

Another enhancement is making use of a new CC4M feature: you can configure what is checked. Only the changed lines of code, the complete file, or just the changed function(s) or method(s) within the applicable file.

The pre-commit hook

The pre-requisites and the installation procedure are documented very will in the GitHub repository (https://github.com/MonkeyProof-Solutions-BV/CC4M-githooks/tree/3-connect-with-running-session---if-possible#installation).

The last 2 steps of the installation procedure are to copy and adapt the hook-script. Here we discuss the last step detail. The pre-commit hook has a top section that contains the various flags to adapt to your installation and desired CC4M settings.

###################################################################################################
#                                                                                                 #
#                                       Configurable settings                                     #
#                                       Adapt to your situation                                   #
#                                                                                                 #
###################################################################################################

# Location of the MATLAB installation to use.
matlabRoot="/c/Program Files/MATLAB/R2025b"

The matlabRoot parameter shall point to a MATLAB installation that includes CC4M.

# Configuration file
# Default: "MonkeyProof Coding Standard for MATLAB" (from the predefined configurations).
configFile=MonkeyProofMATLABCodingStandard
#configFile="c:\myfolder\myconf.xml"

The configFile parameter shall point to a desired configuration file. Here a predefined configuration is used, the MonkeyProof Coding Standard for MATLAB.

# List of extensions to include.
supportedExtensions="\.m$|\.mlx$|\.mlapp$|\.slx$|\.mdl$"

The provided value for supportedExtensions include all supported formats for CC4M. This set can be limited to for example M-files only.

# Only rules with severity level equal to or higher than "severityAllow" will be included.
# Violations of rules with severity level equal to or higher than "severityBlock" will block the commit.
severityBlock=0
severityAllow=10

The severityBlock parameter sets the severity boundary for a hard block of the commit. If there is a violation found by a check with a severity between "1" (the highest severity) and the value of this parameter - the commit is blocked. So a value of "0" prevent the commit hook from blocking the commit.

The severityAllow parameter sets the severity boundary that prevents an automated commit. If there is a violation found by a check with a severity between the value for severityBlock (the lowest severity that is automatically blocking a commit) and the value of this parameter - the commit can still be approved manually. The question "Violations found, do you still want to commit? (y/N)" will be shown in the git client and the commit can be approved or canceled.

Note: Tortoise-Git does not allow this interactivity - and will directly cancel the commit in case of any violation found.

# Scope of the changes that will be checked. Can "file", "block" or "line"
changedOnlyScope="block"

Since CC4M version 2.21 it is possible to filter the violations reported to the relevant block of code or even the changed lines only. For the pre-commit hook the scope is set to "block", so in case some functionality a function has changed, the complete function needs to comply with the desired guidelines. This is good practice - for example when making a change to a method in a larger class file, CC4M will only report any violations in the changed method(s) or property blocks. In this way rework for compliance is limited to the changed functionality.

# License-related settings
# In case of a floating license:
#export MONKEYPROOF_FLOATING_LICENSE_SERVER=<server:port>
# In case of a license file:
#export MONKEYPROOF_LICENSE_FILE_FOLDER=<folder where license file is saved.>

Final settings have to do with the location of the CC4M license. In case the license configuration is not done from within MATLAB (for example via the startup script) the location of the CC4M license file or server can be defined in the pre-commit hook.

Conclusion and discussion

With this you can set up a Git pre-commit hook to prevent a commits if CC4M finds violations on your coding guidelines.

While this approach uses local Git hooks, you can also version control your hook logic or include it in shared developer tooling to ensure consistency across teams.

If you have feedback, suggestions, or questions - feel free to contact us