loft-sh
Docs: Update config.go comments
Add content to comments that belongs with the field rather than separate content on the docs page.
/kind documentation
Part of ENG-3147
Deploy Preview for vcluster-docs canceled.
| Name | Link |
|---|---|
| Latest commit | d57bd3fdfe5f80016466d1fd492f65cc2270912f |
| Latest deploy log | https://app.netlify.com/sites/vcluster-docs/deploys/660efbc7b7a4130008c9583c |
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
Thanks for your comments @johannesfrey For the docs, starting the comment with the name of the exported field/type/func is redundant.
For example:
I can work within Go comment style guidelines if if I have to. For user-facing text, this is a case of deciding whether to strictly follow Go comments style or present content that's more user-friendly but doesn't strictly follow Go comment style rules. We aren't generating a Go API guide or Go library docs, if you see my point.
Probably better to let this PR sit until engineering is done updating the YAML structure. Then we can decide how to structure the comments, and I can update in a single attempt (I don't like merging/rebasing lol).
Thanks for your comments @johannesfrey For the docs, starting the comment with the name of the exported field/type/func is redundant.
For example:
I can work within Go comment style guidelines if if I have to. For user-facing text, this is a case of deciding whether to strictly follow Go comments style or present content that's more user-friendly but doesn't strictly follow Go comment style rules. We aren't generating a Go API guide or Go library docs, if you see my point.
Probably better to let this PR sit until engineering is done updating the YAML structure. Then we can decide how to structure the comments, and I can update in a single attempt (I don't like merging/rebasing lol).
Your welcome 🙂 .
Yes I totally get your point. Indeed we should rather strive for user-friendliness instead of strictly following the go style guidelines. Especially as we are using them verbatim as user-facing docs, which I forgot while doing the review.
