summaryrefslogtreecommitdiffstats
path: root/docs/CODING_STYLE.md (follow)
Commit message (Collapse)AuthorAgeFilesLines
* docs: update coding style for `return (void) func(...)`Anita Zhang2020-10-271-0/+8
| | | | | Seems that people think it's useful for brevity so make it explicit in the CODING_STYLE.
* docs: some coding style updatesLennart Poettering2020-10-191-8/+33
| | | | | | | | | | Primarily: 1. Mention that we prefer if return parameters carry "ret_" as prefix in their name 2. Clarify that debug-level logging is always OK, and irrelevant to when deciding whether a function is logging or non-logging.
* coding style: document how to break a function declarationLuca Boccassi2020-08-201-0/+11
|
* docs: spelling fixesJoerg Behrmann2020-08-041-2/+2
|
* fix typoTomer Shechner2020-07-071-1/+1
| | | | | I was thoroughly reading your nice coding style page and found out that you guys missed an 's'. 😁
* tree-wide: use "hostname" spelling everywhereZbigniew Jędrzejewski-Szmek2020-04-211-1/+1
| | | | | | | | It's not that I think that "hostname" is vastly superior to "host name". Quite the opposite — the difference is small, and in some context the two-word version does fit better. But in the tree, there are ~200 occurrences of the first, and >1600 of the other, and consistent spelling is more important than any particular spelling choice.
* docs: make sure there's only one # markdown header in each fileLennart Poettering2019-12-131-1/+1
| | | | | | | @bertob wants us to be strict here, and only have one "#" header per markdown file, and use "##" (or "###", …) for all others. Interestingly, we mostly got this right already, but this fixes a few cases where this wasn't correct.
* docs: make it prettyTobias Bernard2019-12-111-0/+1
| | | | | | | Add custom Jekyll theme, logo, webfont and .gitignore FIXME: the markdown files have some H1 headers which need to be replaced with H2
* docs: place all our markdown docs in rough categoriesLennart Poettering2019-12-111-0/+1
|
* docs: fix typoSimon Schricker2019-07-301-1/+1
|
* docs: fix typos and duplicate wordsMichael Prokop2019-06-271-1/+1
| | | | | | | | | s/and and/and/ s/explicity/explicitly/ s/that that/that/ s/the the/the/ s/is is/it is/ s/overriden/overridden/
* some CODING_STYLE additionsLennart Poettering2019-06-251-0/+13
|
* CODING_STYLE: rename "Others" section to "Code Organization and Semantics"Lennart Poettering2019-04-121-37/+33
| | | | | This is a bit of a grabbag, but it's the best I could come up with without having lots of single-item sections.
* CODING_STYLE: split out section about runtime behaviourLennart Poettering2019-04-121-31/+33
|
* CODING_STYLE: add section about C constructs useLennart Poettering2019-04-121-74/+72
|
* CODING_STYLE: split out section about deadlocksLennart Poettering2019-04-121-8/+9
|
* CODING_STYLE: split out section about loggingLennart Poettering2019-04-121-28/+29
|
* CODING_STYLE: export section about exporting symbolsLennart Poettering2019-04-121-17/+19
|
* CODING_STYLE: split out section about destructorsLennart Poettering2019-04-121-23/+25
|
* CODING_STYLE: split out section about command line parsingLennart Poettering2019-04-121-12/+13
|
* CODING_STYLE: Split out section about error handlingLennart Poettering2019-04-121-52/+52
|
* CODING_STYLE: split out section about commiting to gitLennart Poettering2019-04-121-7/+8
|
* CODING_STYLE: split out section about file descriptorsLennart Poettering2019-04-121-23/+24
|
* CODING_STYLE: split out section about memory allocationsLennart Poettering2019-04-121-32/+32
|
* CODING_STYLE: move out section about TypesLennart Poettering2019-04-121-35/+35
|
* CODING_STYLE: add section about how to reference specific conceptsLennart Poettering2019-04-121-0/+2
|
* CODING_STYLE: split out bits about Formatting into its own sectionLennart Poettering2019-04-121-49/+52
| | | | (And, for now, add a section "Other" to separate the rest of the stuff)
* CODING_STYLE: add a section about functions not to useLennart Poettering2019-04-121-37/+38
| | | | | Let's add sections to the document. First off, let's add one about functions not to use.
* CODING_STYLE: adjust indentation rules, and add note about config loadingZbigniew Jędrzejewski-Szmek2019-04-121-3/+5
|
* CODING_STYLE: fix grammar mistakeChris Morin2019-01-171-2/+2
|
* docs: add a "front matter" snippet to our markdown pagesFilipe Brandenburger2019-01-021-0/+4
| | | | | | | | | | | | | | | | It turns out Jekyll (the engine behind GitHub Pages) requires that pages include a "Front Matter" snippet of YAML at the top for proper rendering. Omitting it will still render the pages, but including it opens up new possibilities, such as using a {% for %} loop to generate index.md instead of requiring a separate script. I'm hoping this will also fix the issue with some of the pages (notably CODE_OF_CONDUCT.html) not being available under systemd.io Tested locally by rendering the website with Jekyll. Before this change, the *.md files were kept unchanged (so not sure how that even works?!), after this commit, proper *.html files were generated from it.
* coding style: reduce text width to 109 charactersZbigniew Jędrzejewski-Szmek2018-12-081-1/+1
| | | | | | | | Patches are shown on github with a fixed width (no matter how wide the window is). When line numbers are high (we have some files with 5 digit line numbers), the diff does not fit, and horizontal scrolling must be used when viewing the patch. This is super annoying. Let's reduce the width a bit. I think 109 is still very wide, but at least the github issue should be alleviated.
* docs: uppercase the title of our Markdown docsLennart Poettering2018-11-291-1/+1
|
* Fix a few docs typos (#10907)nikolas2018-11-231-2/+2
| | | Found with [codespell](https://github.com/codespell-project/codespell)
* CODING_STYLE: describe log & return operationsZbigniew Jędrzejewski-Szmek2018-11-221-0/+18
|
* CODING_STYLE: fix rules for STRLEN and recommend strjoina more stronglyZbigniew Jędrzejewski-Szmek2018-11-201-6/+10
| | | | Again, this mostly matches what is happening in the codebase already.
* CODING_STYLE: clarify the rules for the src/basic & src/shared splitZbigniew Jędrzejewski-Szmek2018-11-201-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | The rule is changed from "put in basic unless there's a reason not to" to "put in shared unless there's a reason not to", to match the change done in previous commit. This minimizes libbasic. See previous commit for the reasons why this is useful. Previously, the guideline was based on whether the files in question use "publicly exported APIs". This distinction is not particularly relevant. Let's consider all other programs we compile: most of them use "publicly exported APIs", usually linking to libsystemd-shared.so for the actual code. But those programs are not forced to be in src/basic, and the distinction whether they happen to use 'sd-*.h' or not is of no importance. The same is true for files in src/shared/. If we didn't have publicly exported shared objects, we'd put everything in libsystemd-shared.so. So let's only move things out of it that we need to. Previous guideline was not "wrong", in the sense that it created *a* split that was functional (no code in src/shared was required in the publicly exported shared objects), but it put more files in basic/ then necessary. Not much changes in practice, because (as previous commit shows), moving files between libbasic.a and libsystemd-shared.so mostly just changes compilation order. The list of components which cannot use libsystemd-shared.so is adjusted.
* docs: Fix a typo in CODING_STYLE.md (#10630)Felix Yan2018-11-031-1/+1
|
* docs: Convert CODING_STYLE to MarkdownFaheel Ahmad2018-10-301-0/+495
Also fix minor grammatical errors
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-03 08:40:10 +0100