Establishing stylistic conventions #13
Labels
No Label
bug
documentation
duplicate
enhancement
help wanted
invalid
maintenance
peach-lib
peach-network
peach-oled
peach-stats
peach-web
question
refactor
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: PeachCloud/peach-workspace#13
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@notplants
I'm currently reviewing the web routes refactor PR and think it might be useful to agree on some comment conventions. My goal is to have consistency without too much rigidity.
Here are some suggestions to start the conversation:
///
or!//
) : the first word should be capitalised and each sentence should end with a full-stop. Example:/// This function is publicly exposed for users who have forgotten their password.
//
or/* ... */
) : all lowercase and without an ending full-stop. Example:// check to see if there is a flash message to display
#
(like you use in the refactor PR) to make the text bold; I use vim for coding and so it doesn't have an effect for me.I think the first point is the one I care most about, since the doc comments are rendered into the 'official' Rust API documentation for our crates and are therefore more likely to be read by a wider audience. Code comments, on the other hand, will mostly only be read by us and future contributors. From the perspective of a contributor to established project: it has helped he in the past when I see an established convention in the code; then I simply replicate that style in my contributions.
Anywho, not a major thing but I figured it was good to chat about.
Two other ones which come to mind:
Using
TODO
andFIX
in code comments when appropriate (these are highlighted in yellow in my text editor, making them easy to spot).All points sounds good to me.
The third style, hmmm..
interestingly in my IDE, it only shows up bold when a # is used inside of /// (not a //).
Ideally would also like to avoid a pattern that is difficult to copy/paste, or where you need to manually edit the characters to make the pattern the correct "size". I don't love that as you type more characters, the stuff on the right side goes out of alignment and needs to be manually adjusted.
Maybe
or other ideas?
I would also probably lean towards more smaller files, with the prefixes like delta, than doing lots of code sections, since its pretty easy to navigate around between files.
Huh, that is interesting. Was just thinking about it and I believe it does that because markdown can be included in doc comments so that it's formatted when the docs are generated. That would explain why it doesn't do the bolding with
//
.With this in mind, perhaps we could drop the dashes completely? Like this:
Yeahh this would make the section headings redundant. My vote would be to stick with section headers for now and then we can evaluate the splitting at a later stage. Would definitely make a lot of sense for the big files. I'm happy we're having these kinds of higher-level discussions.
The classic problem of lumping versus splitting 😆
Even simpler (I just noticed that I had already been using this pattern):
Just use all-caps for section headings: