Skip to content
Example: 🟩 Sm_SuperCoolBushMesh_01Example: 🟥 sm_Supercoolbushmesh_01Example: 🟩 Sm_SmallBush_01Example: 🟥 sm @Artist Cool!!Bush 0?
The Prefix = Always presentType Indicator = Based on project needsName = Always presentNumber = Always presentVariant = Based on asset type & Project needsSuffix = Based on asset type
XxxManager, for manager scripts that controls a specific workflow (usely only one instance of)XxxController, for scripts controlling a game objectXxxItem, for in-game item instanceXxxSettings, for setting scriptsXeeEditor, for editor-only scripts
This document is meant for students work on some of the IGP assignment. To test and challenge them to work in a predefined working environment.
Robin:
Unity Project setup
#1 Folder Structure
#2 File Naming
General Rules
File naming is important and straightforward. Here follow some general rules
#1 Always use PascalCase.
#2 Make sure that the name makes sense and are descriptive of what they are. Prioritize clear names over higher numbers.
We do this because when we work in a team we don’t want people to have to sample all bushes every single time to find the one they need.
#3 Never use spaces, unicode characters or other symbols. Use “_” to space.
Generic Asset Naming Convention
Before listing the different prefixes, suffixes and some best practices we will first explain the universal basics:
In total there are 6 stages of naming, not all are always relevant based on the asset type or based on the project needs. But when applicable use them, it will make scripting, optimizing and changing things easier down the line. The stages are:
Here you find a table visualizing it:
Generic Naming of Assets
Type of asset
Prefix
Type Indicator (Optional for small projects)
Name
Number
Variant
Suffix
Example: 3D Model
Sm_
Example: F_ (F for foliage)
SmallBush_
XX
N/A
N/A
Example: Texture
T_
N/A
GenericBush_
XX
N/A
_BC
Example: Prefab
Pf_
Example: BG_ (Background use only)
SmallBush_
XX
vX or N/A
_”Varient Extension Text” or N/A
There are no rows in this table
Here is an example of it in action:
Example StaticModel > Textures > Materials > Prefabs
Model
Texture
Material
Prefab
Prefab Alt
Sm_F_SmallBush_01
T_BushLeaf_01v01_BC
M_AutumBush_01
Pf_F_SmallBush_01v02Spring
Pf_SmallBush_01
Sm_BG_SmallBush_02
T_BushLeaf_01v02_BC
M_AutumBush_02
Pf_F_SmallBush_01v02Dead
Pf_SmallBush_02
Sm_F_MediumBush_01
T_BushLeaf_01_M
M_SummerBush_01
Pf_F_SmallBush_01v03Autum
Pf_SmallBush_03
T_BushLeaf_01_N
M_SpringBush_01
Pf_F_SmallBush_01v04Autum
Pf_SmallBush_04
T_BushLeaf_02_BC
M_DeadBush_01
Pf_BG_SmallBush_02v01Spring
Pf_SmallBush_05
T_BushLeaf_02_M
Pf_BG_SmallBush_02v02Dead
Pf_SmallBush_06
T_BushLeaf_02_N
Pf_F_MediumBush_01v01Spring
Pf_MediumBush_01
Pf_F_MediumBush_01v02Dead
Pf_MediumBush_02
Pf_F_MediumBush_01v03Spring
Pf_MediumBush_03
Pf_F_MediumBush_01v04Autum
Pf_MediumBush_04
Pf_F_MediumBush_01v05Autum
Pf_MediumBush_05
There are no rows in this table
By employing the naming convention you can see that we can now clearly link our “Sm’s” to our “Pf’s”. This makes organization and scripting easy and ensures the project is saleable. By adding “F_” and “BG” to our models and prefabs we can clarify how these assets should be used, and we can assume the “BG” version is lowpoly and uses a simplified shader.
#3 Naming per Type
C# Style Guide by @Stijn VAN COILLIE
@Stijn VAN COILLIE
This C# style guide is to keep the code consistent and to improve the readability.
Inspiration: This style guide is based on C# and Unity conventions.
Nomenclature
On the whole, naming should follow C# standards.
Namespaces
Namespaces are all PascalCase, multiple words concatenated together, without hyphens ( - ) or underscores ( _ ). The exception to this rule are acronyms like GUI or HUD, which can be uppercase:
AVOID:
PREFER:
Classes & Interfaces
Classes and interfaces are written in PascalCase. For example RadialSlider.
For certain purposes we use the following naming conventions:
Methods
Methods are written in PascalCase. For example DoSomething().
Fields
All non-static public fields are written PascalCase, all non-static private/protected fields are written _camelCase. For example:
AVOID:
PREFER:
Static fields should be written in PascalCase:
Properties
All properties are written in PascalCase. For example:
Parameters
Parameters are written in camelCase.
AVOID:
PREFER:
Single character values are to be avoided except for temporary looping variables.
Actions
Actions are written in PascalCase. For example:
Arrays
Arrays should be named as a plural noun.
AVOID:
PREFER:
Misc
In code, acronyms should be treated as words. For example:
AVOID:
PREFER:
Declarations
Access Level Modifiers
Access level modifiers should be explicitly defined for classes, methods and member variables.
Fields & Variables
Prefer single declaration per line.
AVOID:
PREFER:
Classes
Exactly one class per source file, although inner classes are encouraged where scoping appropriate.
Interfaces
All interfaces should be prefaced with the letter I.
AVOID:
PREFER:
Functions
The functionality of the function should give a good assumption. All functions and events perform some form of action, whether its getting info, calculating data, or causing something to explode. Therefore, all functions should start with verbs.
AVOID:
PREFER:
Boolean Functions
A boolean functions should ask a question.
AVOID:
PREFER:
Spacing
Spacing is especially important, as code needs to be easily readable.
Indentation
Indentation should be done using tabs — never spaces.
Blocks
Indentation for blocks uses 1 tab for optimal readability:
AVOID:
PREFER:
Line Length
Lines should be no longer than 100 characters long.
Vertical Spacing
There should be exactly one blank line between methods to aid in visual clarity and organization. Whitespace within methods should separate functionality, but having too many sections in a method often means you should refactor into several methods.
Brace Style
All braces get their own line as it is a C# convention:
AVOID:
PREFER:
Conditional statements are always required to be enclosed with braces, irrespective of the number of lines required.
AVOID:
PREFER:
A return is the exception and can be written on a single line:
Switch Statements
Switch-statements come with default case by default (heh). If the default case is never reached, be sure to remove it.
AVOID:
PREFER:
Language
Use US English spelling.
AVOID:
PREFER:
The exception here is MonoBehaviour as that's what the class is actually called.Single line comments should include a space after the slashes.
Comments
Only use comments when necessary.
TODO comments should also include a space after the slashes, followed by a colon.
This embedded link can't be shown.
This embedded link can't be shown.
This embedded link can't be shown.
This embedded link can't be shown.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.