Software quality analysis: Laravel version 8.16.0

What is it?

Laravel is part of the Web Framework family.
Its official website describes it as “a web application framework with an expressive, elegant syntax. We believe development must be an enjoyable, creative experience to be truly fulfilling. Laravel attempts to take the pain out of development by easing common tasks used in the majority of web projects”

This powerful development tool aims at making the developer life easier (this is always welcome!) in such tasks as dependency injection, schema migration, etc. And on top of that, the documentation and resources are rich and detailed too.

We include Laravel systematically in our software quality monitoring of GitHub projects.
Important note: If you notice that the project’s latest versions are not visible in our monitoring, it’s normal. We regularly update our base, but not continuously, to leave time for the code to properly evolve.
So come back regularly, as new versions are added to our monitoring, and trigger new analyses.

Big picture – overall view on software quality in Laravel

Project size

Laravel is a PHP only project.
The analyzed version (8.16.0) counts :

  • over 249k lines of code (about 100k of which are effective code)
  • 1469 files
  • 15659 functions

Laravel – Project complexity

  • This project has a fairly low complexity ratio
    For version 8.16.0, complex functions represent less than 0.4% of the code volume.
  • The most complex function is 302 lines long, and has been flagged because of its multiple exit points (which is not so bad), and its (beautiful) control graph looks like this:
One of the most complex functions in project Laravel (v8.16.0)

Laravel – Technical debt

  • The overall Technical Debt is over 59 days
  • The “New Technical Debt” (for added code) is 1h34′
  • The “Modified Technical Debt” (for modified code) is 2 days and 1h
  • The “Unchanged Technical Debt” (for unmodified code) is 57 days and 4h

Software quality analysis: Why did we focus on Laravel?

The project trend indicators (Project Activity, Complexity Ratio, Technical Debt), each slightly changed one way or another (less than 5% variation).
So in essence it seems there was no radical change since the previous version. But we can see the Complexity Ratio is on a slight decrease and the Technical Debt on a slight increase.
Let’s take a look and see what’s behind this status.

Exploring the dashboard

Let’s open the Code Quality dashboard for Laravel version 8.16.0.

Code quality analysis dashboard for Laravel, version 8.16.0
  • Let’s start with the Complexity Ratio trend
Complexity volume ratio trend for project Laravel
Complexity volume ratio trend for project Laravel (until version 8.16.0)

First, as with all charts, be mindful of how it is displayed, because it can be deceptive.
Here, for example, it seems the Complexity Ratio decrease is significant since the last 8 versions.
But looking at the vertical scale, we can see that this “decrease” goes in fact from 0.42% down to 0.41%, which is not so significant after all.

But still, there is a little decrease, and that’s why the trend indicator signaled a small variation.
And looking at the project statistics (below), it is quite logical, since there are 15k+ functions, and the complex ones are very few (which is a good sign)

Software quality metrics for project Laravel
Counting metrics for project Laravel (version 8.16.0)

  • Exploring the Technical debt
    Choosing the “Technical debt” dashboard, we can look at the breakdown by ISO characteristic, the trend, or analysis by rule violations density.
Quality analysis dashboard – Technical debt of Lavarel

The “Analysis: Technical Debt” table is simple, but already provides interesting information
Remember this is an initial analysis, which can be refined with proper tuning (see our “Important note” below )

Technical debt for project Laravel
Technical debt for project Laravel (version 8.16.0)

What can we understand about Laravel’s software analysis from this table?
The “Technical Debt” is over 59 days.
That’s the cumulated time combining rule violations remediation cost, as well as complexity.
It is increasing indeed, as the trend shows, but let’s look deeper before jumping to conclusions.

Technical debt trend for project Laravel
Technical debt trend for project Laravel (until version 8.16.0)

New, Modified and Unchanged Technical Debt
These values break down the first count across code elements (aka “Artefacts”), depending if they have been created or modified since the last version, or if they have not changed at all.
In this case, we can see that unchanged artefacts are responsible for 57 days of Technical Debt, out of 59 days in total.
Which leaves:
– 1h34 Technical Debt attached to new artefacts
– 2 days 1h Technical Debt attached to modified artefacts

Putting things into perspective, we can see that actual work on the code generated a much more manageable amount of Technical Debt, once we discard the “Unchanged Technical Debt”.

Current value vs. speed

Using the current value of Technical Debt for analysis is good if we want an overall picture of the project: past and present.
But if we speak of monitoring, we need to understand the evolution, and track impacts of code change.
The speed of Technical Debt, or its variation provides important knowledge, leading to concrete actions: it is definitely easier to deal with an hour and a half of corrections, compared to 59 days.

Important note: To compute the Technical Debt on this real life code, we used a standard set of programming rules. This has helped us discuss the value of trend vs absolute value, but it is not a full image of the project itself.
To achieve a “full resolution” analysis, we’d need to calibrate the ruleset, and adjust the thresholds to fit the dev team practices.

We’ll continue exploring projects from our showcase in future “Software Quality Analysis” posts!

Further readings


Share on linkedin
Share on twitter
Share on whatsapp

Leave a Comment

Related Posts

Improving test efficiency

Improving test efficiency

Effective software teams are always looking for ways to make their members more efficient. They realize that improving the development process is an good way

Recipe for a successful software demo

Recipe for a successful software demo

Software demos are an essential part of a balanced and healthy product development cycle. From internally unveiling a new proof-of-concept to collecting feedback from external

Hey there!

Subscribe and get an email every time we’ve got a new quality piece on here.