Analysing the Complexity of Angular Apps

Home » Blog » Software » Front End Development » Analysing the Complexity of Angular Apps
  • Analysing an existing application if you join a project.
  • Assessing the quality and maintainability of an application.
  • Identifying soft spots in an application which could benefit the most from refactoring.

There are numerous reasons for wanting to size up the complexity of an application. In addition to general and language-specific tools provided by IDEs and applications such as SonarLint / SonarQube it can be useful to not only take framework specifics into account but to actually make use of them to get a better overall picture of the quality and complexity of an application.

Part of my work amounts to providing my clients with an appraisal as to the state their software currently is in and to point out potential avenues of improvement.

Often, Angular applications serve as a front-end in these cases and consequently account for a crucial part of the overall complexity.

In order to not just give an intuitive assessment and on the other hand to not have to individually and manually analyse each component of an Angular app each time (being a virtuous programmer, after all) I created a Ruby command-line script for analysing the complexity of Angular apps: https://github.com/BjoernKW/Miscellaneous/blob/master/measure_angular_component_complexity.rb

The idea behind that script is predicated on the assumption that the complexity of a code entity (class, component, service …) to a large degree is contingent on its dependencies.

The script takes a path with Angular source code as an argument (e.g. ./measure_angular_component_complexity.rb src/app) and recursively counts the different types of Angular dependencies (providers, imports and declarations) in the TestBed configurations of unit tests for Angular components (services, directives, pipes, guards …) on that path.

In order to achieve this the script goes through each file ending in .spec.ts and checks (using regular expressions) where the definitions for each type of Angular dependency begin and where they end, respectively.

This allows us to infer which dependencies are required for a component to compile. This in turn provides us with a rough indicator for the complexity of single components and an application as a whole. It’s not a particularly exact measure but it’s conducive to evaluating an application in order to subsequently be able to focus on the more complex components when it comes to a more detailed analysis and possible improvements.

The script assumes 1 provider / import / declaration entry per line, as for example defined by the Angular style guide. Counting multiple entries would be possible but would require more effort. Since IDEs allow you to easily reformat source code into conforming to 1 entry per line I limited the script to this simpler method.

Apart from individual dependencies by component the script also yields a total value for the application. This is based on tokens instead of types, i.e. if a particular dependency occurs in multiple components it’ll also be considered multiple times for calculating the total value.

A German language version of this article is available at AngularJS.DE: Abschätzung der Komplexität einer Angular Anwendung

Leave a Comment

*

I agree

Privacy Preference Center

Strictly necessary

These cookies are necessary for the site to function.

PHPSESSID: Preserves user session state across page requests.

PHPSESSID

Statistics

Google Analytics statistics cookies help us to understand how visitors interact with our websites by collecting and reporting information anonymously.

You can opt out of Google Analytics tracking by clicking on the opt-out link in the banner below.

_ga: Registers a unique ID that is used to generate statistical data on how the visitor uses the website.

_gat: Used by Google Analytics to throttle request rate.

_gid: Registers a unique ID that is used to generate statistical data on how the visitor uses the website.

ga-disable-UA-25326096-9: Stores whether you have opted out of Google Analytics tracking.

_ga,_gat,_gid,ga-disable-UA-25326096-9

Privacy

These cookies are used for storing your privacy settings

gdpr%5Bprivacy_bar%5D: Privacy settings have been reviewed.

gdpr[consent_types]: The uses of your data you agreed to.

gdpr[allowed_cookies]: The cookies you allowed us to set.

gaoop_hide_info: Set if you agreed to our use of Google Analytics.

gdprprivacy_bar,gdpr[consent_types],gdpr[allowed_cookies],gaoop_hide_info

Security

We use Wordfence to secure our website against hacking attempts: https://www.wordfence.com/

Cookies set by the Wordfence plugin
To help you understand which cookies the Wordfence plugin sets, when installed on your WordPress site, we have provided the guide below. Wordfence currently sets three cookies and we explain what each cookie does, who will have the cookie set, and why the cookie helps secure your site.

wfwaf-authcookie-(hash)
What it does: This cookie is used by the Wordfence firewall to perform a capability check of the current user before WordPress has been loaded.

Who gets this cookie: This is only set for users that are able to log into WordPress.

How this cookie helps: This cookie allows the Wordfence firewall to detect logged in users and allow them increased access. It also allows Wordfence to detect non-logged in users and restrict their access to secure areas. The cookie also lets the firewall know what level of access a visitor has to help the firewall make smart decisions about who to allow and who to block.

wf_loginalerted_(hash)
What it does: This cookie is used to notify the Wordfence admin when an administrator logs in from a new device or location.

Who gets this cookie: This is only set for administrators.

How this cookie helps: This cookie helps site owners know whether there has been an admin login from a new device or location.

wfCBLBypass
What it does: Wordfence offers a feature for a site visitor to bypass country blocking by accessing a hidden URL. This cookie helps track who should be allowed to bypass country blocking.

Who gets this cookie: When a hidden URL defined by the site admin is visited, this cookie is set to verify the user can access the site from a country restricted through country blocking. This will be set for anyone who knows the URL that allows bypass of standard country blocking. This cookie is not set for anyone who does not know the hidden URL to bypass country blocking.

How this cookie helps: This cookie gives site owners a way to allow certain users from blocked countries, even though their country has been blocked.

wfvt_#,wordfence_verifiedHuman,wfwaf-authcookie-(hash),wf_loginalerted_(hash),wfCBLBypass

Close your account?

Your account will be closed and all data will be permanently deleted and cannot be recovered. Are you sure?