Literate programming seems fine for heavily algorithmic stuff when there's a lot of explaining to do compared to the amount of code and the code is linear, but I was more thinking about how it works for common web apps where it's lots of mundane code that criss-crosses between files.
I say oddly, as I don't think I've seen it done for common web apps. I suspect that is largely because frameworks have not been a stable foundation to build on in a long time?
I can't help but think the old templates of old were a hint in how it would have worked fine? Have a section of the literate code that outlines the general template of a file, and where the old "your code goes here" comments used to denote where you add your logic, is instead another section that you can discuss on its own. (Anyone else remember those templates? Were common in app builders, if I recall correctly.)
- gcodepreview.py (gcpy) --- the Python functions and variables
- pygcodepreview.scad (pyscad) --- the Python functions wrapped in OpenSCAD
- gcodepreview.scad (gcpscad) --- OpenSCAD modules and variables
as explained in: https://github.com/WillAdams/gcodepreview/blob/main/gcodepre... and it worked quite well (far better than the tiled set of three text editor windows which I was using at first) and I find the ability to sequence the code for the separate files in a single master file very helpful.
I think where it shines, is where it helps you break the code up, without having to break it up in a way that makes sense for the computer. Show an outline, but then drill into a section. The overall function can then be kept as a single unit, and you can sort of punt on sub sections. I tried this just recently in https://taeric.github.io/many_sums.html. I don't know that I succeeded, necessarily. Indeed, I think I probably should have broken things into more sections. That said, I did find that this helped me write the code more than I expected it to. (I also was very surprised at how effective the goto style of thinking was... Much to my chagrin.)
I will have to look again at some of the code I've read this way.
To directly answer the question of if it helped keep the documentation in sync, as it were, that is tough. I think it helps keep the code in a section directly related to the documentation for that section. All too often, the majority of code around something is not related to what you were wanting to do. Even the general use of common code constructs gets in the way of reading what you were doing. Literate programming seems the best way I have seen to give the narrative the ability to say "here is the outline necessary for a function" and then "this particular code is to do ..." Obviously, though, it is no panacea.