Style guide ad01: Difference between revisions
From Andreida
No edit summary |
No edit summary |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
( there is another [[Style guide ad02]]) |
|||
| ⚫ | |||
= operators and the like = |
|||
| ⚫ | |||
* every curly bracket gets its own line. You may append comments if it makes sense, normally above or below is better |
* every curly bracket gets its own line. You may append comments if it makes sense, normally above or below is better |
||
* the closing curly bracket is in the same column as the opening curly bracket |
* the closing curly bracket is in the same column as the opening curly bracket |
||
= comments = |
== comments == |
||
* If you want the comment to stay - like documentation - use "///". |
* If you want the comment to stay - like documentation - use "///". |
||
| Line 15: | Line 18: | ||
Account accCustomerRemote = accountManager.getCustomerSpecial(CURRENTLY_LOGGED_IN); |
Account accCustomerRemote = accountManager.getCustomerSpecial(CURRENTLY_LOGGED_IN); |
||
== variables == |
== variables == |
||
| Line 44: | Line 49: | ||
|string |
|string |
||
|s |
|s |
||
|- |
|||
| c-string (null terminated) |
|||
| sz |
|||
|- |
|- |
||
|pointer (int*, char*, ...) |
|pointer (int*, char*, ...) |
||
| Line 89: | Line 91: | ||
#endif |
#endif |
||
</pre> |
|||
= Access Specifiers = |
|||
== Starter == |
|||
* Keep in mind that no access specifiers mean |
|||
** public for structs |
|||
** private for classes |
|||
* Separate definitions which use multiple lines by empty lines from the others |
|||
* Group methods and variables with empty lines by logic, context or whatever makes sense to you |
|||
== Sequence == |
|||
You should have your access specifiers in this sequence: |
|||
# public |
|||
# protected |
|||
# private |
|||
This is the normal usage. If you use certain environments (like the Unreal Engine) you might NEED or want to start with a private part, as you'll see in the example below. |
|||
== separate methods and member variables == |
|||
Use the access specifiers multiple times to have areas for member methods and other areas for member variables. |
|||
== Example == |
|||
<pre> |
|||
class Base |
|||
{ |
|||
GENERATED_BODY() |
|||
public: |
|||
Base(); |
|||
protected: |
|||
void normalMethod1(void); |
|||
void normalMethod2(void); |
|||
FMulticastDelegateSignature& getDelegateLightsOff(); |
|||
protected: |
|||
int m_nCountErrors; |
|||
std::string m_sCurrentInsult; |
|||
std::vector<std::string> m_vecListOfInsults; |
|||
UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = Input, meta = (AllowPrivateAccess = "true")) |
|||
UInputAction* m_pLookAction; |
|||
FMulticastDelegateSignature m_mcdLightsOff; |
|||
}; |
|||
</pre> |
</pre> |
||
Latest revision as of 13:07, 28 May 2024
( there is another Style guide ad02)
operators and the like
curly brackets {}
- every curly bracket gets its own line. You may append comments if it makes sense, normally above or below is better
- the closing curly bracket is in the same column as the opening curly bracket
comments
- If you want the comment to stay - like documentation - use "///".
In Microsoft's Visual Studio you can set the display of "///" with "Tools/Options/Environment/Fonts and Colors/XML Doc Comment". You could change the "item background" to be able to read quickly through your documentation of your code.
naming
- Use camel case
- variables start with a lowercase letter
- methods/functions start with a lowercase letter
- classes start with an uppercase letter
Account accCustomerRemote = accountManager.getCustomerSpecial(CURRENTLY_LOGGED_IN);
variables
- prefix member variables with m_
- prefix static variables with s_
- prefix global variables with g_ (or don't use them)
- prefix variables with an indicator of the type (put it behind any m_, s_, g_)
- int* m_pnUserCount = ...
| member | m_ |
| static | s_ |
| global | g_ |
| natural numbers (int, long, ...) | n |
| floating-point numbers (float, double, ...) | f |
| string | s |
| pointer (int*, char*, ...) | p |
| enum | e |
| combo box | cbo |
| ... |
constants
- in most cases do not use camel case here
- all upper case
- underscore "_" between "words"
header guard define
Consider using <NameSpace_ClassName> with camel case:
- the namespace lessens the chance of duplicate defines (you have no idea how many string.h or helper.h are out there)
- the camel case
- makes it easy to copy/paste from the file content to the define or use a macro to do it for you
- makes it easy to spot spelling errors
Example:
#ifndef FunnyCorp_Thing
#define FunnyCorp_Thing
namespace FunnyCorp
{
class Thing
{
public:
protected:
};
} /// namespace
#endif
