Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-05-02 14:56:13 -04:00
Code Issues Projects Releases Packages Wiki Activity

more minor typo/grammar fixes

Browse source
This commit is contained in:
Miguel Jacq 2017-05-12 15:58:22 +10:00
parent 2f369c1309
commit c5f4957ee2
No known key found for this signature in database
GPG key ID: EEA4341C6D97A0B6
13 changed files with 37 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

8
basics_dev/coding-style.md
View file

@ -97,7 +97,7 @@ General programming style guidelines
}
~~~
- Do **not** use comments to disable code fragments. In a production code there should really be no commented or disabled code fragments. If you really, really have a good reason to retain some fragment of unused code, use \#if or \#ifdef to disable it, e.g.:
- Do **not** use comments to disable code fragments. In production code there should really be no commented or disabled code fragments. If you really, really have a good reason to retain some fragment of unused code, use \#if or \#ifdef to disable it, e.g.:
~~~
#if 0
@ -130,7 +130,7 @@ Source Code management (Git) guidelines
- This creates natural boundaries between different code blocks, enforcing proper interfaces, and easing independent development to be conducted on various code parts at the same time, without the fear of running into conflicts.
- By maintaining relatively small git repositories, it is easy for new developers to understand the code and contribute new patches, without the need to understand all the other code.
- Code repositories represent also licensing boundaries. So, e.g. because `core-agent-linux` and `core-agent-windows` are maintained in two different repositories, it is possible to have the latter under a proprietary, non-GPL license, while keeping the former fully open source.
- We have drastically changes the layout and naming of the code repositories shortly after Qubes OS R2 Beta 2 release. For details on the current code layout, please read [this article](https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html).
- We have drastically changed the layout and naming of the code repositories shortly after Qubes OS R2 Beta 2 release. For details on the current code layout, please read [this article](https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html).
Commit message guidelines
-------------------------
@ -165,7 +165,7 @@ Security coding guidelines
height = untrusted_conf.height;
~~~
- Use another variables, without the `untrusted_` prefix to hold the sanitized values, as shown above.
- Use equivalent variables, without the `untrusted_` prefix to hold the sanitized values, as shown above.
Python-specific guidelines
--------------------------
@ -178,7 +178,7 @@ C and C++ specific guidelines
- Do not place code in `*.h` files.
- Use `const` whenever possible, e.g. in function arguments passed via pointers.
- Do not mix procedural and objective code together -- if you write in C++, use classes and objects.
- Think about classes hierarchy, before start implementing specific methods.
- Think about classes hierarchy, before starting to implement specific methods.
Bash-specific guidelines
------------------------

2
basics_dev/style-guide.md
View file

@ -68,7 +68,7 @@ Currently, all the icons on the Qubes-OS.org website are generated using [FontAw
## Logos
The following is a collection of various sizes & versions of the Qubes logo used both in the OS itself and on our website. All of these files are licensed GPLv2 and the source can be [downloaded here](https://github.com/QubesOS/qubes-artwork).
The following is a collection of various sizes and versions of the Qubes logo used both in the OS itself and on our website. All of these files are licensed GPLv2 and the source can be [downloaded here](https://github.com/QubesOS/qubes-artwork).
<div class="styleguide">
{% for logo in site.data.styleguide.logos %}

6
basics_dev/usability-ux.md
View file

@ -44,7 +44,7 @@ In making software easy to use, it is crucial to be mindful of [cognitive load](
## Easy to Understand
There will always be the need to communicate things to users. In these cases, an interface should aim to make this information easy to understand. The following are simple guides to help achieve this - none these are absolute maxims!
There will always be the need to communicate things to users. In these cases, an interface should aim to make this information easy to understand. The following are simple guides to help achieve this - none of these are absolute maxims!
<div class="focus">
<i class="fa fa-times"></i> <strong>Avoid Acronyms</strong>
@ -82,7 +82,7 @@ Technical words are usually more accurate, but they often *only* make sense to t
- `savefile`
- `qrexec-daemon`
These are all terms that have at some point showed up in users' notification messages. Each term is very specific, but requires the user to understand virtualization to interpet.
These are all terms that have at some point showed up in users' notification messages. Each term is very specific, but requires the user to understand virtualization to interpret.
<div class="focus">
<i class="fa fa-check"></i> <strong> Use Common Concepts</strong>
@ -195,7 +195,7 @@ There are many cases where a user wants to perform an action on more than one fi
3. Select proper file
4. Complete task on file
That subtle act of clicking through a file system can prove to be significant if a user needs to open more than a couples files in the same directory. We can alleviate some of the work by changing the process:
That subtle act of clicking through a file system can prove to be significant if a user needs to open more than a couple files in the same directory. We can alleviate some of the work by changing the process:
1. Click on `Open File` from a menu or button
2. Remember last open folder/file system