dotnet / orleans

Cloud Native application framework for .NET
https://docs.microsoft.com/dotnet/orleans
MIT License
10.07k stars 2.03k forks source link

Auto-generate documentation from code. #88

Closed jason-bragg closed 3 years ago

jason-bragg commented 9 years ago

Auto-generated documents can help provide more complete and up-to-date documentation with little effort.

I'm thinking first steps might be. 1) Select code generator - Doxygen? 2) Create basic configurations and script to generate reference manual like documentation.

Then we can refine the comments in code to improve the generated documents.

When generated documentation is of sufficient quality we can: 3) Incorporate document generation into the builds. 4) Add automation to publish documents online whenever repository is updated.

Thoughts?

ghuntley commented 9 years ago

re: autogenerated documentation see http://jacobian.org/writing/what-to-write/

Auto-generated documentation is almost worthless. At best it’s a slightly
improved version of simply browsing through the source, but most of the time
it’s easier just to read the source than to navigate the bullshit that these
autodoc tools produce. About the only thing auto-generated documentation is good
for is filling printed pages when contracts dictate delivery of a certain number
of pages of documentation. I feel a particularly deep form of rage every time I
click on a “documentation” link and see auto-generated documentation.

There’s no substitute for documentation written, organized, and edited by hand.

I’ll even go further and say that auto-generated documentation is worse than
useless: it lets maintainers fool themselves into thinking they have
documentation, thus putting off actually writing good reference by hand. If you
don’t have documentation just admit to it. Maybe a volunteer will offer to write
some! But don’t lie and give me that auto-documentation crap.

http://jacobian.org/writing/technical-style/ http://jacobian.org/writing/editors/

jthelin commented 9 years ago

There is already lots of human-written documentation in the wiki which is [at least is intended to be] along the lines that @ghuntley describes. https://github.com/dotnet/orleans/wiki

While we all try to be professional, at the end of the day we are all still Developers not Copy Editors, and I don't think any of us gets up in the morning with our first thought being "Hmm, today I feel like writing some documentation!" ;)

So, if there are specific topics that you feel are NOT already covered well in the wiki, then please flag them up as enhancement request Issues on GitHub. We will probably grumble a little (hey, we are human too!) but then will try to write up something "decent" for community review / feedback.

Also, if anyone is exploring specific areas of the code base and wants to provide any summaries / overviews / knowledge capture for those parts, then we are very open to those being incorporated into the wiki too.

At the end of the day, these are not "our" docs, they are "Our" docs belonging to the Community.


Having said that, there is also still a place for doc-comments for APIs, and in general it is good discipline for developers to write explanations for method / class purpose and meaning of each parameter, at least for the public parts of the APIs.

I think @jason-bragg query is about people's experiences and suggestions for specific good tools which help to auto-generate API docs to HTML as API's change / evolve, and which integrate well with GitHub / Jenkins-CI.

The original core team for Orleans tried to be fairly pragmatic, but we also did aim to follow the min-bar of having "decent" code-docs for all public API classes & methods. I strongly suggest that this practice is continued by all contributors going forward.

gabikliot commented 9 years ago

I agree with @jthelin-microsoft . Regarding the documentation for specific areas of the code base, we started this section: https://github.com/dotnet/orleans/wiki/Runtime-Implementation-Details and plan to extend it with description of more internal components.

sergeybykov commented 9 years ago

Also, @richorama has written a bunch of blog posts on various important topics. I'm not sure what's the best way to integrate them. Add links to a relevant wiki page?

richorama commented 9 years ago

Someone should write a book...

I don't mind contributing a chapter, but I don't think I could muster the energy to write the whole thing...

-----Original Message----- From: "Sergey Bykov" notifications@github.com Sent: ‎06/‎02/‎2015 21:26 To: "dotnet/orleans" orleans@noreply.github.com Cc: "Richard Astbury" richard.astbury@gmail.com Subject: Re: [orleans] Auto-generate documentation from code. (#88)

Also, @richorama has written a bunch of blog posts on various important topics. I'm not sure what's the best way to integrate them. Add links to a relevant wiki page? — Reply to this email directly or view it on GitHub.

jason-bragg commented 9 years ago

I apologize for being unclear in my initial proposal. By ‘reference manual’, I was referring to public API documentation. Samples such as "My First Orleans Application" (https://github.com/dotnet/orleans/wiki/My-First-Orleans-Application), descriptions of framework behaviors like "Reentrant Grains" (https://github.com/dotnet/orleans/wiki/Reentrant-Grains) , and many other such documentation needs are, in my experience, not well met by generated documentation. Auto-generated API reference documentation, has the advantage of being comprehensive, and up to date. Additionally, once the initial integration work is done, it’s extremely light wait, as the cost of maintaining it is negligible, because it requires only that developers maintain clear comments in public APIs, something we should be doing anyway.

ToddShelton commented 9 years ago

@jason-bragg are you talking about ///-style inline documentation or a separate API document?

MovGP0 commented 9 years ago

When someone wants to have a Doxygen file, the person can easily adopt the build file to do so:

 <?xml version="1.0" encoding="utf-8"?>
  <Project ... DefaultTargets="Doxygen" 
      xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- ... -->
  <DoxyGen>"C:\Program Files\doxygen\bin\doxygen.exe"</DoxyGen>
 <!-- ... -->
  <Target Name="Doxygen" Condition="Exists('bin\doxygen.exe')">
    <MakeDir Directories="$(builtdir)\docs" Condition="!Exists('$(builtdir)\docs')" />
    <Message Text="Creating documentation in $(builtdir)\docs" />
    <Exec Command="$(DoxyGen) $(builtdir)\docs" />
  </Target>
</Project>

However, I discourage to do this by default. To my experience there is not much benefit to this when the project is open source. Its way better to look at the actual code.

Also, to get an overview, an human written guide from the wiki is the better choice, since it reduces the amount of code that the user needs to read in order to start using the library. I also recommend reading the unit tests, since they represent working code that use the library.

veikkoeeva commented 9 years ago

Someone should write a book... I don't mind contributing a chapter, but I don't think I could muster the energy to write the whole thing...

Indeed. Really nice would be if it had a brief tour on some theory with regards to actor model (agents?), CAP(*), FLP and some higher level design traits. From a more engineering angle, throughput (it's interesting that embedded systems work like Orleans to guarantee throughput and then there are special purpose circuits for heavy algoritms) and latency considerations, scheduling (cooperative/preemptive), reentrancy and whatnot, design patterns pitfalls etc. Then some actual code and constructs sprinkled in so one doesn't have to try to guess how what are the actual constructs in code.

(*) I'm not sure about the right level of exposure. Perhaps something like in

richorama commented 9 years ago

Sounds good, I look forward to reading it!

-----Original Message----- From: "Veikko Eeva" notifications@github.com Sent: ‎17/‎02/‎2015 20:32 To: "dotnet/orleans" orleans@noreply.github.com Cc: "Richard Astbury" richard.astbury@gmail.com Subject: Re: [orleans] Auto-generate documentation from code. (#88)

Someone should write a book... I don't mind contributing a chapter, but I don't think I could muster the energy to write the whole thing... Indeed. Really nice would be if it had a brief tour on some theory with regards to actor model (agents?), CAP(), FLP and some higher level design traits. From a more engineering angle, throughput (it's interesting that embedded systems work like Orleans to guarantee throughput and then there are special purpose circuits for heavy algoritms) and latency considerations, scheduling (cooperative/preemptive), reentrancy and whatnot, design patterns pitfalls etc. Then some actual code and constructs sprinkled in so one doesn't have to try to guess how what are the actual constructs in code. () I'm not sure about the right level of exposure. Perhaps something like in Don't Settle for Eventual Consistency Eventual Consistency Today: Limitations, Extensions, and Beyond and the Jepsen Call Me Maybe series. — Reply to this email directly or view it on GitHub.

gabikliot commented 8 years ago

http://dotnet.github.io/docfx/ Looks relevant to what you wanted to do @jason-bragg .

jdom commented 8 years ago

We are now using DocFX, so we are closer to this goal

ReubenBond commented 3 years ago

Closing this until it's actionable. Perhaps a future DocFx release will make this easier.