Skip to content

Conversation

hishamco
Copy link
Member

@hishamco hishamco commented Apr 15, 2025

No description provided.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These docs aren't really adding anything useful.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having docs is better than nothing :) But I will add extra info

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. Docs that don't provide information beyond what's obvious from the code at a cursory glance, or even just the method signatures, is just noise. This is especially true for implementations of interfaces that nobody will directly use, so there's no advantage for IntelliSense.

And I'm saying this as someone who encourages and likes documentation, and whose team has Readme and interface docs enforced.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs only explain what's obvious from the names already. Add information that goes beyond that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Example:

"Contract for handling setup events." should become "Implementations of this interface provide methods that are invoked during different steps of the setup phase."

Copy link
Member

@Piedone Piedone Apr 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current docs on this interface are still only restating the obvious. If you really want to document it (and this being an internally used simple service I don't think it's beneficial to put any more effort into this), then add information about the why, not the what. The latter is trivial here, the former is what you have to dig into the code for.

Same for SetupUserIdGenerator. That really doesn't need /// XML docs, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then add information about the why, not the what

I disagree; normally, the docs in APIs let the users understand the type, its properties and methods, and extra remarks if needed. Regarding "Why," this could be explained in web docs or a tutorial

Again having docs even with little details is better than nothing :) that's why almost the APIs are not documented

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really, it is not.

Here we have an interface called Setup User Id Generator. What's obvious from this, since it's spelled out in the code, is that this is, well, an interface (which if you know C# you understand being a similar concept than a contract in the common sense), that generates user IDs for/during setup. The name and type, in itself, should be clear enough for those with the necessary domain knowledge, and in this case, probably they are. But for those who it's not clear, "Contract that represents a setup user id generator." doesn't help. It just makes interface ISetupUserIdGenerator into an English sentence. Why didn't you also specify in the comment that it's public? Wouldn't then "Public contract that represents a setup user id generator." be better? Or is adding in a comment that's already spelled out in the code useless, and we can agree that spelling out the rest is useless too? Why don't we turn every declaration into an English sentence?

And again, what's not useless, is explaining something that's not obvious from the code, what takes an effort to figure out. This brings value, since it lets others not have to figure it out. If you think that's better in web docs or a tutorial, then I encourage you to work on that instead.

@hishamco hishamco requested a review from Piedone April 17, 2025 04:30
Copy link
Contributor

This pull request has merge conflicts. Please resolve those before requesting a review.

Copy link
Contributor

github-actions bot commented Aug 9, 2025

It seems that this pull request didn't really move for quite a while. Is this something you'd like to revisit any time soon or should we close? Please comment if you'd like to pick it up.

@github-actions github-actions bot added the stale label Aug 9, 2025
@hishamco
Copy link
Member Author

hishamco commented Aug 9, 2025

@Piedone can we merge this?

@github-actions github-actions bot removed the stale label Aug 10, 2025
@Piedone
Copy link
Member

Piedone commented Aug 10, 2025

Did you address my most recent comment?

@hishamco
Copy link
Member Author

AFAIK yes, that's why you will find two commits after your latest comment

@Piedone
Copy link
Member

Piedone commented Aug 10, 2025

I checked the code, and it doesn't seem so. Sorry, but I can't allocate any more time to argue for avoiding comments that just state the obvious, so I won't be able to review this PR any further. In its current state I don't approve of it.

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

Successfully merging this pull request may close these issues.

3 participants