Design journal and Rich comment blocks

How often do you use Clojure's (comment ) form in your day to day development?
Do you have any other use case for it other than trying out something during development?
Do you later delete it or do you push it along to production?

When doing a lot of design work or using less familiar code, I use a separate design-journal namespace. I do not require this from other namespaces, so no need for comments.

Otherwise I use the comment form at the end of a namespace to keep a small number of experiments together, and be sure I can reload a namespace without evaluating does experiments.

I also use #_ for commenting specific lines in the 'live' code, useful for debugging, but these are usually short term.

I also use the (comment ) form to call useful functions with sample arguments, showing how to use the project or debug issues

A simple example is here:

https://practicalli.github.io/clojure-webapps/projects/banking-on-clojure/application-server-configuration.html#repl-driven-development-helpers

@λraulain I use (comment ..) every day. I leave a lot of the comment blocks in the code when it is committed. I use it both to explore the problem space and the solution space, as well as to provide "set up" code for use with the REPL. You'll see that sort of thing in several of my open source projects too, for example https://github.com/seancorfield/usermanager-example/blob/master/src/usermanager/main.clj#L212-L219

Another, longer example is in next.jdbc: https://github.com/seancorfield/next-jdbc/blob/develop/src/next/jdbc/connection.clj#L283

I also generally have a (comment ...) block at the bottom of my files. It's often my scratchpad for building up functions and implementations. Sometimes I migrate them into tests.
https://gitlab.com/jamesleonis/dht-cljc/-/blob/master/src/dht_cljc/infohash.cljc#L58

Start by reviewing the discussion and the linked examples in practicalli's Clojure documentation, usermanager-example, next-jdbc, and dht-cljc. The issue has no named file, test, or concrete change; work is only complete once the intended documentation or project change is agreed and specified.