fork/Graphite
1
0
Fork 0
mirror of https://github.com/GraphiteEditor/Graphite.git synced 2026-10-02 12:48:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

Add Stipe donations to the website and polish other pages

Browse Source
This commit is contained in:
Keavon Chambers
2025-01-17 15:21:57 -08:00
parent 5aedda0ce8
commit b7907bc96f
12 changed files with 288 additions and 104 deletions
Download Patch File Download Diff File Expand all files Collapse all files
website/content/volunteer/guide/starting-a-task/code-quality-guidelines.md
+3 -3
View File
@@ -27,15 +27,15 @@ Always use the style `42.` instead of `42.0` for whole-number floats to maintain
## Comments
For consistency, please try to write comments in *Sentence case* (starting with a capital letter). End with a period only if multiple sentences are used in the same comment. For doc comments (`///`), always write in full sentences ending with a period. There should always be one space after the `//` or `///` comment markers, and `/* */` style comments shouldn't be used.
For consistency, please try to write comments (`//`) in *Sentence case* (with a capital first letter) and don't end with a period unless multiple sentences are used in the same comment. For doc comments (`///`), always end your sentences with a period. There should always be one space after the `//` or `///` comment markers, and `/* */` style comments should be avoided.
Avoid including commented-out code, unless you have a compelling reason to keep it around for future adaption, in your PRs that are open for code review.
Comments should usually be placed on a separate line above the code they are referring to, not at the end of the code line.
Comments should usually be placed on a separate line above the code they are referring to, not at the end of the same code line.
## Blank lines
Please make a habit of grouping together related lines of codes in blocks separated by blank lines. If you have dozens of lines comprising a single unbroken block of logic, you are likely not splitting it apart enough to aid readability. Find sensible places to partition the logic and insert blank lines between each. Roughly 10% of the code you write should ideally be blank lines, otherwise you are likely underutilizing them at the expense of readability.
Please make a habit of grouping together related lines of code in blocks separated by blank lines. If you have dozens of lines comprising a single unbroken block of logic, you are likely not splitting it apart enough to aid readability. Find sensible places to partition the logic and insert blank lines between each. Roughly 10% of the code you write should ideally be blank lines, otherwise you are likely underutilizing them at the expense of readability.
## Imports