mirror of
				https://github.com/subsurface/subsurface.git
				synced 2025-02-19 22:16:15 +00:00 
			
		
		
		
	Update CodingStyle.md: placement of *, & and && declarators
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This commit is contained in:
		
							parent
							
								
									c7f0e65b12
								
							
						
					
					
						commit
						d3dc698bba
					
				
					 1 changed files with 58 additions and 58 deletions
				
			
		
							
								
								
									
										116
									
								
								CodingStyle.md
									
										
									
									
									
								
							
							
						
						
									
										116
									
								
								CodingStyle.md
									
										
									
									
									
								
							| 
						 | 
				
			
			@ -20,18 +20,16 @@ other editors that implement this coding style, please add them here.
 | 
			
		|||
  continuation lines that are aligned with tabs and then spaces
 | 
			
		||||
 | 
			
		||||
* all keywords followed by a '(' have a space in between
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	if (condition)
 | 
			
		||||
 | 
			
		||||
	for (i = 0; i < 5; i++)
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
* function calls do NOT have a space between their name and argument
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	i = some_function(argument);
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
* usually there is no space on the inside of parenthesis (see examples
 | 
			
		||||
  above)
 | 
			
		||||
| 
						 | 
				
			
			@ -41,17 +39,15 @@ other editors that implement this coding style, please add them here.
 | 
			
		|||
 | 
			
		||||
* all other opening curly braces follow at the end of the line, with a
 | 
			
		||||
  space separating them:
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	if (condition) {
 | 
			
		||||
		dosomething();
 | 
			
		||||
		dosomethingelse();
 | 
			
		||||
	}
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
* both sides of an if / else clause either use or do not use curly braces:
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	if (condition)
 | 
			
		||||
		i = 4;
 | 
			
		||||
	else
 | 
			
		||||
| 
						 | 
				
			
			@ -63,55 +59,48 @@ other editors that implement this coding style, please add them here.
 | 
			
		|||
		i = 4;
 | 
			
		||||
		j = 6;
 | 
			
		||||
	}
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
* use space to make visual separation easier
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	a = b + 3 + e / 4;
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
* continuation lines have the operator / comma at the end
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	if (very_long_condition_1 ||
 | 
			
		||||
	    condition_2)
 | 
			
		||||
 | 
			
		||||
	b = a + (c + d +
 | 
			
		||||
		 f + z);
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
* in a C++ constructor initialization list, the colon is on the same line and
 | 
			
		||||
  continuation lines are aligned as the rule above:
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	ClassName::ClassName() : x(1),
 | 
			
		||||
		y(2),
 | 
			
		||||
		z(3)
 | 
			
		||||
	{
 | 
			
		||||
	}
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
* unfortunate inconsistency
 | 
			
		||||
 * C code usually uses underscores to structure names
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  - C code usually uses underscores to structure names
 | 
			
		||||
  ```
 | 
			
		||||
	variable_in_C
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
 * C++ code usually uses camelCase
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
  - In contrast, C++ code usually uses camelCase
 | 
			
		||||
  ```
 | 
			
		||||
	variableInCPlusPlus
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
  where the two meet, use your best judgment and go for best consistency
 | 
			
		||||
  (i.e., where does the variable "originate")
 | 
			
		||||
 | 
			
		||||
* switch statements with blocks are a little bit special (to avoid indenting
 | 
			
		||||
  too far)
 | 
			
		||||
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	switch (foo) {
 | 
			
		||||
	case FIRST:
 | 
			
		||||
		whatever();
 | 
			
		||||
| 
						 | 
				
			
			@ -122,7 +111,7 @@ other editors that implement this coding style, please add them here.
 | 
			
		|||
			do_something(i);
 | 
			
		||||
	}
 | 
			
		||||
	}
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
## Coding conventions
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -130,7 +119,22 @@ other editors that implement this coding style, please add them here.
 | 
			
		|||
  In C code we really like them to be at the beginning of a code block,
 | 
			
		||||
  not interspersed in the middle.
 | 
			
		||||
  in C++ we are a bit less strict about this - but still, try not to go
 | 
			
		||||
  crazy.
 | 
			
		||||
  crazy. Notably, in C++ the lifetime of a variable often coincides with the
 | 
			
		||||
  lifetime of a resource (e.g. file) and therefore the variable is defined
 | 
			
		||||
  at the place where the resource is needed.
 | 
			
		||||
 | 
			
		||||
* The `*`, `&` and `&&` declarators are grouped with the name, not the type
 | 
			
		||||
 (classical C-style) as in `char *string` instead of `char* string`. This
 | 
			
		||||
  reflects the precedence rules of the language: `int &i` means that the name
 | 
			
		||||
  `i` stands for a reference [to an object with type `int`], not that
 | 
			
		||||
  `i` stands for an object of the type [reference to `int`].
 | 
			
		||||
  Although this may seem like hairsplitting (both interpretations
 | 
			
		||||
  have the same effect) it is crucial in the
 | 
			
		||||
  definition of multiple variables, such
 | 
			
		||||
  as
 | 
			
		||||
	```
 | 
			
		||||
	struct dive *next, **pprev;
 | 
			
		||||
	```
 | 
			
		||||
 | 
			
		||||
* In C++ code, we generally use explicit types in variable declarations for clarity.
 | 
			
		||||
  Use `auto` sparingly and only in cases where code readability improves.
 | 
			
		||||
| 
						 | 
				
			
			@ -150,71 +154,70 @@ other editors that implement this coding style, please add them here.
 | 
			
		|||
	```
 | 
			
		||||
  	is easier to read than and conveys the same information as
 | 
			
		||||
	```
 | 
			
		||||
	QLowEnergyService* service = qobject_cast<QLowEnergyService*>(sender());
 | 
			
		||||
	QLowEnergyService *service = qobject_cast<QLowEnergyService*>(sender());
 | 
			
		||||
	```
 | 
			
		||||
* text strings
 | 
			
		||||
  The default language of subsurface is US English so please use US English
 | 
			
		||||
  spelling and terminology.
 | 
			
		||||
  User-visible strings should be passed to the tr() function to enable
 | 
			
		||||
  translation into other languages.
 | 
			
		||||
 | 
			
		||||
 * like this
 | 
			
		||||
```
 | 
			
		||||
  - like this
 | 
			
		||||
    ```
 | 
			
		||||
	QString msgTitle = tr("Submit user survey.");
 | 
			
		||||
```
 | 
			
		||||
 * rather than
 | 
			
		||||
```
 | 
			
		||||
    ```
 | 
			
		||||
  - rather than
 | 
			
		||||
    ```
 | 
			
		||||
	QString msgTitle = "Submit user survey.";
 | 
			
		||||
```
 | 
			
		||||
    ```
 | 
			
		||||
 | 
			
		||||
  This works by default in classes (indirectly) derived from QObject. Each
 | 
			
		||||
  string to be translated is associated with a context, which corresponds
 | 
			
		||||
  to the class name. Classes that are not derived from QObject can generate
 | 
			
		||||
  the tr() functions by using the Q_DECLARE_FUNCTIONS macro:
 | 
			
		||||
```
 | 
			
		||||
  the tr() functions by using the `Q_DECLARE_FUNCTIONS` macro:
 | 
			
		||||
  ```
 | 
			
		||||
	#include <QCoreApplication>
 | 
			
		||||
 | 
			
		||||
	class myClass {
 | 
			
		||||
		Q_DECLARE_TR_FUNCTIONS(gettextfromC)
 | 
			
		||||
		...
 | 
			
		||||
	};
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
  As an alternative, which also works outside of class context, the tr()
 | 
			
		||||
  function of a different class can be called. This avoids creating multiple
 | 
			
		||||
  translations for the same string:
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	gettextFromC::tr("%1km")
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
 | 
			
		||||
  The gettextFromC class in the above example was created as a catch-all
 | 
			
		||||
  context for translations accessed in C code. But it can also be used
 | 
			
		||||
  from C++ helper functions. To use it from C, include the "core/gettext.h"
 | 
			
		||||
  header and invoke the translate() macro:
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
	#include "core/gettext.h"
 | 
			
		||||
 | 
			
		||||
	report_error(translate("gettextFromC", "Remote storage and local data diverged"));
 | 
			
		||||
```
 | 
			
		||||
  ```
 | 
			
		||||
  It is crucial to pass "gettextFromC" as a first macro argument so that Qt
 | 
			
		||||
  is able to associate the string with the correct context.
 | 
			
		||||
  The translate macro returns a cached C-style string, which is generated at runtime
 | 
			
		||||
  when the particular translation string is encountered for the first time.
 | 
			
		||||
  It remains valid during the whole application's life time.
 | 
			
		||||
 | 
			
		||||
  Outside of function context, the QT_TRANSLATE_NOOP macro can be used as in
 | 
			
		||||
```
 | 
			
		||||
struct ws_info_t ws_info[100] = {
 | 
			
		||||
  Outside of function context, the `QT_TRANSLATE_NOOP` macro can be used as in
 | 
			
		||||
  ```
 | 
			
		||||
  struct ws_info_t ws_info[100] = {
 | 
			
		||||
	{ QT_TRANSLATE_NOOP("gettextFromC", "integrated"), 0 },
 | 
			
		||||
	{ QT_TRANSLATE_NOOP("gettextFromC", "belt"), 0 },
 | 
			
		||||
	{ QT_TRANSLATE_NOOP("gettextFromC", "ankle"), 0 },
 | 
			
		||||
	{ QT_TRANSLATE_NOOP("gettextFromC", "backplate"), 0 },
 | 
			
		||||
	{ QT_TRANSLATE_NOOP("gettextFromC", "clip-on"), 0 },
 | 
			
		||||
};
 | 
			
		||||
```
 | 
			
		||||
  };
 | 
			
		||||
  ```
 | 
			
		||||
  Note that here, the texts will be scheduled for translation with the "gettextFromC"
 | 
			
		||||
  context, but the array is only initialized with the original text. The actual
 | 
			
		||||
  translation has to be performed later in code. For C-code, the QT_TRANSLATE_NOOP
 | 
			
		||||
  translation has to be performed later in code. For C-code, the `QT_TRANSLATE_NOOP`
 | 
			
		||||
  macro is defined in the "core/gettext.h" header.
 | 
			
		||||
 | 
			
		||||
* UI text style
 | 
			
		||||
| 
						 | 
				
			
			@ -236,11 +239,9 @@ struct ws_info_t ws_info[100] = {
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
* string manipulation
 | 
			
		||||
 | 
			
		||||
 * user interface
 | 
			
		||||
    In UI part of the code use of QString methods is preferred, see this pretty
 | 
			
		||||
    good guide in [QString documentation][1]
 | 
			
		||||
 | 
			
		||||
 * core components
 | 
			
		||||
    In the core part of the code, C-string should be used.
 | 
			
		||||
    C-string manipulation is not always straightforward specifically when
 | 
			
		||||
| 
						 | 
				
			
			@ -248,7 +249,6 @@ struct ws_info_t ws_info[100] = {
 | 
			
		|||
    to help with this. Documentation and usage examples can be found in
 | 
			
		||||
    [core/membuffer.h][2]
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
## Sample Settings
 | 
			
		||||
 | 
			
		||||
### Emacs
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue