|
|
# Analyze code quality through Emacs: a smart forensics approach and the story of a hack
Andrea
Emacs, show me how much technical debt and where it is in this
software repository!
Also how complex is this module?
And who is the main developer of this component?
Mmm, if I change this file, do I need to change something else, Emacs?
Ah, I need help of somebody to change this code! Emacs can you tell me
who knows something about this file?
The above are some questions my Emacs can answer (an M-x away).
It all started with "Your Code as a Crime Scene", an insightful book
by Adam Tornhill, and it continued with a big useful hack.
In this talk I want to show the analyses I can produce on software
repositories with my Emacs, explain how they help me in my daily work,
give a bit of context of how Adam came up with them, and show the
dirty code that makes this wonderful functionality work.
<!-- from the pad --->
- Actual start and end time (EST): Start 2020-11-29T10.34.52; End: 2020-11-29T10.55.39
# Questions
## Q3: How large of a codebase could this be used to analyze? Are there known limits in size?
### Nope, so far I could create a microservice picture at work that has a few million of lines. I did not do stress test, but I am confident that (at least the hotspots analysis) does not break.
## Q2: Have you uploaded this file somewhere (or plan to do so)? This seems very useful so I would love to have these code snippets.
### It's totally my plan to make this accessible to everyone: we need more code quality for our feature (software is everywhere)! The plan was a series of blog and learn how to publish in MELPA later.
### That's great, make sure to announce it somewhere so we know when it comes out :D. Or maybe link the git repo that you are using for this.
## Q1: What is used to measure the complexity of a LISP file, from your point of view? The nesting level per chance?
### indentation is good enough to apply in general. Even lisp gets formatted in a standard way. Probably you can come up with a more specific and precise way, but indentation is a really rough metrics to give you a general idea. So take with a pinch of salt, but exploit to find weird things.
### OK, thanks for the response.
## Copied Q&A from IRC:
### How did you summon, resize and dismiss that window so seamlessly?
- org-roam and C-x0
- How did you resize it from 2/3 to 1/3 of the frame?
- golden-ratio-mode from golden-ratio
### Have you considered doing this analysis by function instead than by file?
- I did not have chance yet to integrate that, but the theory is described in Adam's 2nd book: Software Design -Rays
# Notes
## Book by Adam Tornhill "Your Code as a Crime Scene": <https://www.adamtornhillem.com/articles/crimescene/codeascrimescene.htm>
## <https://github.com/adamtornhill/code-maat>
## Beautiful circles diagram.
## especially for big projects with many collaborators the codebase may become less transparent
## hotspots: files that have had many changes based on git history; likely sources of bugs
## Complexities of a file are measured in terms of the indentation, at least in the case of Java.
## "If a lot of lines are deleted, that's usually a good sign. If a lot of lines are added, it's a sign of technological debt"
## another beautiful diagram (big circle with files on periphery, linked together with curved lines) showing associations between changes in files: when this file gets changed, it usually means that this other file is also changed
## <https://ag91.github.io/blog/>
|
