From abd15734ca999b24051ccac7bb4f60d5c17e6fde Mon Sep 17 00:00:00 2001 From: Bhavin Gandhi Date: Sat, 12 Dec 2020 00:46:37 +0530 Subject: Formatting, typos - talk 21-35 --- 2020/info/24.md | 67 ++++++++++++++++++++++++++++++++------------------------- 1 file changed, 38 insertions(+), 29 deletions(-) (limited to '2020/info/24.md') diff --git a/2020/info/24.md b/2020/info/24.md index 256e7f42..70ec13fd 100644 --- a/2020/info/24.md +++ b/2020/info/24.md @@ -28,49 +28,58 @@ dirty code that makes this wonderful functionality work. -- Actual start and end time (EST): Start 2020-11-29T10.34.52; End: 2020-11-29T10.55.39 - +- 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. - +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. -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. - +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. -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. - +- OK, thanks for the response. ## 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 +org-roam and C-x 0 +- 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 - +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": -- -- 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 -- - +- Book by Adam Tornhill "Your Code as a Crime Scene": + . +- . +- 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. +- . -- cgit v1.2.3