Is there a "markup language" to describe a debugging session?

I want to document my debugging sessions in a text file but I don’t know if anyone did this before.

I came up with this kind of “language” that is a mix between Markdown and C++, but I still wonder if something equivalent exists already.


<span style="color:#323232;">// When you click on the button
</span><span style="color:#323232;"># [click button]
</span><span style="color:#323232;">- A::f()
</span><span style="color:#323232;">// - ... other method calls, don't document if you don't need to
</span><span style="color:#323232;">
</span><span style="color:#323232;"># A::f()
</span><span style="color:#323232;">// "..." for "parameters" where you don't need the details
</span><span style="color:#323232;">- Stuff::g(...)
</span><span style="color:#323232;">- Stuff::h(...)
</span><span style="color:#323232;">
</span><span style="color:#323232;">// <Class> is a fake template thing to show the possible types of an object
</span><span style="color:#323232;"># <SubStuffA | SubStuffB> Stuff::g(...)
</span><span style="color:#323232;">- Stuff::g() {} // empty but I use v/=> for virtual call
</span><span style="color:#323232;">  v/=> SubStuffA::g()
</span><span style="color:#323232;">  v/=> SubStuffB::g()
</span><span style="color:#323232;">
</span><span style="color:#323232;"># SubStuffA::g()
</span><span style="color:#323232;">
</span><span style="color:#323232;"># SubStuffB::g()
</span><span style="color:#323232;">
</span><span style="color:#323232;"># Stuff::h(...)
</span>

I document methods in the order of appearance in the code.

If you have any good idea about a reliable way to document a list of function calls, I’m interested!

Lodra,
@Lodra@programming.dev avatar

I certainly don’t have an answer for you. Sorry 🙂

I’m super curious about your motives and goals though. Why do you want to do this??

0x1C3B00DA,
@0x1C3B00DA@fedia.io avatar

I could see walking through a debug session document with a junior dev to guide them on how to debug classes of issues better. Or if they're running into a bug and ask for your help, you could write out the first few debugging steps and let them take it from there. That might be easier to understand than "I'd check service X and see if it's processing Y like it should or just passing it on to Z". Having a defined way to explain how to debug an issue could be useful

  • All
  • Subscribed
  • Moderated
  • Favorites
  • experienced_devs@programming.dev
  • ngwrru68w68
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • thenastyranch
  • magazineikmin
  • megavids
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • provamag3
  • JUstTest
  • All magazines