docs: inheritdoc at class level

[say25]

Signed-off-by: Steven Yeh [email protected]

This PR

• Moves inheritdoc to the class level so it doesn't need to be done on every method.

Related Issues

#102

Notes

Follow-up Tasks

How to test

• Docs only, I guess validate that the docs are still on all the methods?

[codecov-commenter]

Codecov Report

Merging #108 (5a89cab) into main (6d820cb) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #108   +/-   ##
=======================================
  Coverage   94.54%   94.54%           
=======================================
  Files          20       20           
  Lines         532      532           
  Branches       37       37           
=======================================
  Hits          503      503           
  Misses         16       16           
  Partials       13       13           

Impacted Files	Coverage Δ
src/OpenFeature/OpenFeatureClient.cs	98.74% <ø> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[toddbaert]

I really like this in theory, but dotnet/roslyn#42392 seems to make this impractical at the moment. I can't seem to find a way to make the compiler or my IDE not complain about this.

@say25 if you can find a solution, please let me know, but until then I think having inheritdoc on every member is better than disabling the check.

[say25]

I really like this in theory, but dotnet/roslyn#42392 seems to make this impractical at the moment. I can't seem to find a way to make the compiler or my IDE not complain about this.

@say25 if you can find a solution, please let me know, but until then I think having inheritdoc on every member is better than disabling the check.

Yea I'm going to just close this, @cdonnellytx and I work together and he pointed out this issue to me as well. Seems that doc generation is impacted in this way

[toddbaert]

Thanks, regardless!

[toddbaert]

@say25 If you're looking for another way to contribute, I can think of 2 options (no pressure at all, of course):

• create a summary of things that need doing to bring this repo more in-line with the org's repo-reqs. See an example for another repo .

• if the above seems uninteresting, you might be interested in simply taking on one of these issues without creating a summary... for example, implementing SBOM generation via CycloneDX.

[say25]

I'll keep that in mind, I think at the moment this project is satisfying our needs