Style guide ad01: Difference between revisions
From Andreida
No edit summary |
|||
| (4 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 = |
|||
<blockquote style="background-color: lightgrey; border: solid thin grey;text-align: center;"> |
|||
Everything goes into protected.<br> |
|||
Then you move the ones you need in public to public. <br> |
|||
Normally developers don't need private. |
|||
</blockquote> |
|||
That does not mean to not use "private:". It just means, put everything in protected first and only if you realize that derived classes should not be able to use that member variable or method, THEN you move it to private. |
|||
== 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
