summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-12-15 14:58:51 +0100
committerwm4 <wm4@nowhere>2019-12-15 14:58:51 +0100
commit0de881fa72bc68f7ec4bc406967b5a6d77cd773a (patch)
treed3846cfedb76cb16282ba96577c536e6cc8c9ae0
parenta6cb92c74a802ed2205487f59a324d306b8123da (diff)
downloadmpv-0de881fa72bc68f7ec4bc406967b5a6d77cd773a.tar.bz2
mpv-0de881fa72bc68f7ec4bc406967b5a6d77cd773a.tar.xz
DOCS/contribute.md: should -> must
People somehow think "should" makes things optional, even though the wording was merely trying to account for the exception of the rule. I guess this means programming documents should sound like we're running a police state (which is also the ultimate outcome of all technological development, if you weren't aware). See: #7248
-rw-r--r--DOCS/contribute.md16
1 files changed, 8 insertions, 8 deletions
diff --git a/DOCS/contribute.md b/DOCS/contribute.md
index 319968bd83..d3e3025a6e 100644
--- a/DOCS/contribute.md
+++ b/DOCS/contribute.md
@@ -55,10 +55,10 @@ Write good commit messages
- Write informative commit messages. Use present tense to describe the
situation with the patch applied, and past tense for the situation before
the change.
-- The subject line (the first line in a commit message) should contain a
+- The subject line (the first line in a commit message) must contain a
prefix identifying the sub system, followed by a short description what
impact this commit has. This subject line and the commit message body
- shouldn't be longer than 72 characters per line, because it messes up the
+ must not be longer than 72 characters per line, because it messes up the
output of many git tools otherwise.
For example, you fixed a crash in af_volume.c:
@@ -72,7 +72,7 @@ Write good commit messages
- Don't end the subject line with a ``.``.
- Put an empty line between the subject line and the commit message.
If this is missing, it will break display in common git tools.
-- The body of the commit message (everything else after the subject line) should
+- The body of the commit message (everything else after the subject line) must
be as informative as possible and contain everything that isn't obvious. Don't
hesitate to dump as much information as you can - it doesn't cost you
anything. Put some effort into it. If someone finds a bug months or years
@@ -81,7 +81,7 @@ Write good commit messages
information to test the original bug. The old bug might be reintroduced while
fixing the new bug.
- The commit message should be wrapped on 72 characters per line, because git
+ The commit message must be wrapped on 72 characters per line, because git
tools usually do not break text automatically. On the other hand, you do not
need to break text that would be unnatural to break (like data for test cases,
or long URLs).
@@ -124,7 +124,7 @@ mpv uses C99 with K&R formatting, with some exceptions.
- Use the K&R indent style.
- Use 4 spaces of indentation, never use tabs (except in Makefiles).
- Add a single space between keywords and binary operators. There are some other
- cases where spaces should be added. Example:
+ cases where spaces must be added. Example:
```C
if ((a * b) > c) {
@@ -157,7 +157,7 @@ mpv uses C99 with K&R formatting, with some exceptions.
do_something();
}
```
-- If the if has an else branch, both branches should use braces, even if they're
+- If the if has an else branch, both branches must use braces, even if they're
technically redundant.
Example:
@@ -193,7 +193,7 @@ Header #include statement order
-------------------------------
The order of ``#include`` statements in the source code is not very consistent.
-New code should follow the following conventions:
+New code must follow the following conventions:
- Put standard includes (``#include <stdlib.h>`` etc.) on the top,
- then after a blank line, add library includes (``#include <zlib.h`` etc.)
@@ -208,7 +208,7 @@ General coding
- Don't use non-standard language (such as GNU C-only features). In some cases
they may be warranted, if they are optional (such as attributes enabling
printf-like format string checks). "#pragma once" is allowed as an exception.
- But in general, standard C99 should be used.
+ But in general, standard C99 must be used.
- The same applies to libc functions. We have to be Windows-compatible too. Use
functions guaranteed by C99 or POSIX only, unless your use is guarded by a
configure check. There is some restricted use of C11 (ask on IRC for details).