docs: document formatting for slice definitions #9806
Conversation
guggero
added
documentation
|
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
| ### Inline slice definitions | ||
| In Go a list of slices can be initialized with values directly, using curly | ||
| braces. Whenever possible, the more verbose/indented style should be used for |
There was a problem hiding this comment.
tho one is parentheses and the other is curly braces, it feels like this somewhat contradicts with the reasoning here,
As long as the visual symmetry of the opening and closing parentheses is
preserved, arguments that would otherwise introduce a new level of indentation
are allowed to be written in a more compact form.
There was a problem hiding this comment.
Just to make sure I understand you correctly: You're saying that, to match the quoted part in the other section of the document, the more compact string initialization ({{ ... }}) should be the preferred one instead?
There was a problem hiding this comment.
yeah it's more about the preference here - like do we prefer compactness over verboseness, or is it case-specific?
There was a problem hiding this comment.
I actually prefer the more compact version, but Laolu prefers the more verbose one (probably because it is easier to insert another element with copy/paste and also makes git conflicts a bit easier to handle). So that's the reason I wrote it this way.
There was a problem hiding this comment.
yeah I also slightly prefer the compact version, but no strong opinion. But it would be a bit difficult to follow if I need to remember when to be compact and when to be verbose😅
There was a problem hiding this comment.
Okay, I looked at this again. And I think we don't necessarily contradict ourselves here. The part about the visual symmetry for wrapping long function calls is about what line you place the opening vs. the closing curly braces of a slice.
This section (about inline slice definitions) is about how many indentation levels you create when you directly initialize a slice with values (vs. just initializing simple structs in function/method calls).
So to align with Laolu's preferences, I think we should prefer the more-indented version but allow the compact version when things get too long.
Does that work for you or would you invert that (prefer compact but allow more verbose, but then with what rationale)?
|
!lightninglabs-deploy mute |
Adds more clarity around when to use what style for using inline slice definitions.
guggero
force-pushed
the
formatting-list-initializations
branch
from
2b34cf9 to
e10cb01
Compare
|
@ziggie1984 also added an explanation for what is meant by "visual symmetry". |
| As long as the visual symmetry of the opening and closing parentheses is | ||
| preserved, arguments that would otherwise introduce a new level of indentation | ||
| are allowed to be written in a more compact form. | ||
| As long as the visual symmetry of the opening and closing parentheses (or curly |
4 participants
Adds more clarity around when to use what style for using inline slice definitions.