4 ms·

I do this a lot: "Often I stoop to the level of caching my findings in a docstring/comment." I am not ashamed of this. When my co-workers have to read what I

I do this a lot: "Often I stoop to the level of caching my findings in a docstring/comment." I am not ashamed of this. When my co-workers have to read what I wrote, this kind of information makes clear what the function does. If I don't do this, then they will eventually figure it out by running it at the REPL and examining the input and the output, but if I document that in the docstring, I have saved them a lot of time. I also make it possible for them to actually read the code -- otherwise they can't really read it, expect by repeating it at the REPL.

danneu 13y ago
Yeah, you're right. I would love if every Clojure function came with an example input and output. What I meant to suggest is that my docstring example is something that could be expressed in code.
- zeckalpha 13y ago
  This would let you run tests, too: https://en.wikipedia.org/wiki/Doctest https://en.wikipedia.org/wiki/Doctest On the other hand, why not just make it statically typed and list the types for each function?
- freshhawk 13y ago
  A friend of mine has been doing similar things with the Swagger documentation spec (https://developers.helloreverb.com/swagger/ https://developers.helloreverb.com/swagger/) While browsing the docs in a web browser you can fill out some fields for input and see what the output for that input is. My friend forked it and extracts and lists any example data so you can click to load that example into those fields (my idea!). I tried it out and it's a very nice way to learn/explore a new API, especially testing edge cases where the docs are ambiguous. It really hits a sweet spot when you have documentation browsing, live execution and example data. I think creating a similar interface combining docstrings, the repl and example data from test fixtures would be a nice tool to have (I find doctests to be one of those things that are better in theory than in practice as they get too long and maintenance is annoying, although perhaps a more literate style in your source code would change that).
- john2x 13y ago
  You would think that being most functions being pure, that these types of docsctrings would be more common (or standard, even).
- urlwolf 13y ago
  This is exactly what R does. It's a huge timesaver. Best. docs. ever.

danneu 13y ago

Yeah, you're right. I would love if every Clojure function came with an example input and output. What I meant to suggest is that my docstring example is something that could be expressed in code.

zeckalpha 13y ago
This would let you run tests, too: https://en.wikipedia.org/wiki/Doctest https://en.wikipedia.org/wiki/Doctest On the other hand, why not just make it statically typed and list the types for each function?
freshhawk 13y ago
A friend of mine has been doing similar things with the Swagger documentation spec (https://developers.helloreverb.com/swagger/ https://developers.helloreverb.com/swagger/) While browsing the docs in a web browser you can fill out some fields for input and see what the output for that input is. My friend forked it and extracts and lists any example data so you can click to load that example into those fields (my idea!). I tried it out and it's a very nice way to learn/explore a new API, especially testing edge cases where the docs are ambiguous. It really hits a sweet spot when you have documentation browsing, live execution and example data. I think creating a similar interface combining docstrings, the repl and example data from test fixtures would be a nice tool to have (I find doctests to be one of those things that are better in theory than in practice as they get too long and maintenance is annoying, although perhaps a more literate style in your source code would change that).
john2x 13y ago
You would think that being most functions being pure, that these types of docsctrings would be more common (or standard, even).
urlwolf 13y ago
This is exactly what R does. It's a huge timesaver. Best. docs. ever.