★ wanayoo — archive 1999 https://github.com/sqlkata/querybuilder/issues/35Nouvelle recherche | Portail wanayoo
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XML Documentation on all public methods #35

Open
natepisarski opened this issue Dec 8, 2017 · 5 comments
Open

XML Documentation on all public methods #35

natepisarski opened this issue Dec 8, 2017 · 5 comments

Comments

@natepisarski
Copy link

@natepisarski natepisarski commented Dec 8, 2017

The Problem

Howdy! So, I've started to play around with SqlKata on a pretty large project with a lot of team members. The existing documentation has been very helpful to get started with the basics. However, I've found myself reading the code quite a bit to get an idea of how more complex scenarios work.

The Use-Case

While this makes a case for simply beefing up the existing github website, I believe it would be more helpful to include detailed XML documentation for public members and classes. Most developers I know tend to explore a new library via:

  • An IDE, by exploring XML documentation comments in the IDE's intellisense tooltip box
  • Exploring a complete reference website, which can be generated from a project with XML documentation (doxygen). This could even be hosted on the Github site.
  • Lastly, exploring the code - which becomes clearer with XML documentation comments.

The Question

Would this be a worthwhile contribution? Some developers leave these out as a choice, as to not clutter the code itself. If this is something that would be considered helpful, I'd gladly volunteer (without any promises as to timeframe) to begin writing this documentation. Thoughts?

@ahmad-moussawi
Copy link
Contributor

@ahmad-moussawi ahmad-moussawi commented Dec 8, 2017

Hi @natepisarski, the short answer is absolutely yes.
But keep in mind that the package is still in beta, while the majority of the API will stay the same, I can't guarantee that the public API will not change, especially that I am planning to add many useful features to it the soonest,

So I will appreciate in advance any effort regarding the docs 👍

@natepisarski
Copy link
Author

@natepisarski natepisarski commented Dec 8, 2017

@ahmad-moussawi That's totally okay! Updates docs after a breaking change tends to be less of an investment than writing them in the first place.

There's approaches I've seen (that are all overkill for the current state of the project) like leaving a [Documented("12-08-2017")] and checking against a history of breaking changes automatically in the unit tests.

Once I get a bit more well versed in the code I'll put up a documentation PR. I'd find it super helpful, and I bet plenty of people will as well. Thanks for being open to it 🥇

@ahmad-moussawi
Copy link
Contributor

@ahmad-moussawi ahmad-moussawi commented Dec 11, 2017

That really cool, please let me know if you I can help in this also

@IssueHuntBot
Copy link

@IssueHuntBot IssueHuntBot commented Sep 14, 2018

@BoostIO funded this issue with $10. Visit this issue on Issuehunt

@IssueHuntBot
Copy link

@IssueHuntBot IssueHuntBot commented Oct 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.