Unstructured thoughts about 📏 Complexity.
Coupling
- Suggestions for code refactoring based on coupling and complexity (🔗 Software Coupling and Complexity)
- E.g., a class is big and difficult to understand. Suggestions for ‘how to slice the cake’.
- For example, move a set of functions out of a class to create a dedicated class for a set of dependencies
Data sources
There are both opinionated and un-opinionated metrics.
Un-opinionated metrics don’t require anything from the developer, only rely on data that is the result of normal day-to-day work, such as
- Code hotspots (requires looking at git history)
- Dependencies (requires static code analysis)
Opinionated metrics require a certain structure or effort from developers to get the data, such as:
- Semantic Commit Messages to find buggy hotspots in the code by checking for
fix:in commit messages
Refactoring Suggestions
- Analysing similar code patterns over the codebase. Is there a recurring piece of code that could be generalised and extracted?
- Can anything be learned from underused dependencies?
Concept
📀 Data Sources For Software Complexity Metrics
- Unchanged code (good code doesn’t have to change because it works, bad code usually isn’t changed because nobody dares to touch it)
Since most data gathering should be based on runtime data of tests + version control, it can be applied to existing open-source projects as a basis. A list of big open source projects can be found in this blogpost by GitHub on open source.
It makes most sense to focus on the biggest programming languages right now. GitHub has compiled a list of top 10 programming languages, which I can use as a baseline.
Other data can be useful too, but is probably harder to realistically gather:
- Why code changed (new feature vs a bug)
Proof of Concept
A static analysis tool written in 🧑💻️ Kotlin focusing on the biggest open-source projects. ⌨️ TypeScript is one of the biggest languages right now, so the initial version will focus on that language. The open-source project used as an initial reference point is vscode.
This means I can’t dog-feed, but I prefer Kotlin as a language to work in.
Abstract Syntax Trees
More complex source code analysis requires the use of 🌳 Abstract Syntax Tree, which is language-dependent.
Concept
Since it doesn’t seem to be possible to run through the AST from within Kotlin (or Java), I’m thinking of running the TypeScript compiler in a TypeScript program and outputting the data in JSON format to be parsed by the main Kotlin program.
Charts
As part of my Design Principle “Visual”, I think it’s important to visualise data to simplify interpretation.
Considered options:
- 🧑💻️ Charts in Kotlin, but I don’t want to immediately start with a heavy-weight library like JavaFX
- 🐍 Python as a post-processing script
- 🧑💻️ Frontend Development, JavaScript/TypeScript Charting libraries