Contents
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
What is clean code, anyway? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Developing as a team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Keep it simple, stupid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
The KISS principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
The YAGNI principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Don’t code around the problem . . . . . . . . . . . . . . . . . . . . . . . . 7
Improve incrementally, every day . . . . . . . . . . . . . . . . . . . . . . . 7
Plan, but adapt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Be consistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
It takes a village . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
A style guide for you and your team . . . . . . . . . . . . . . . . . . . . 8
Create a style guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Identifier names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Casing terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Camel case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Pascal case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Snake case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Kebab case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Hungarian notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Fields and variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Enums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Classes and interfaces…………………………. 16
Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Events and event handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
What is EditorConfig?………………………….. 28
Horizontal spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Vertical spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Code formatting in Visual Studio . . . . . . . . . . . . . . . . . . . . . . 31
Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
The newspaper metaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Class organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Single-responsibility principle . . . . . . . . . . . . . . . . . . . . . . . . 36
Refactoring example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Extension methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
The DRY principle: Don’t repeat yourself . . . . . . . . . . . . . 41
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Common pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Appendix: Script templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Appendix: Testing and debugging . . . . . . . . . . . . . . . . . . . . . . . . 55
Unity Test Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
© 2022 Unity Technologies 3 of 58 | unity.com
Creativity can be messy.
A flash of inspiration becomes a flurry of code, which then spawns a working
prototype. Success! Congratulations on passing the first hurdle. However,
simply getting your code to work won’t be enough. There’s much more to game
development.
Once your logic is functional, then the process of refactoring and cleaning up
begins.
This guide compiles advice from industry experts on how to create a code
style guide. Establishing ssuch a guide for each member of your team to follow
will help ensure your codebase can grow your project to a commercial-scale
production.
These tips and tricks will help your development process in the long term, even
if they cost you extra effort up front. A cleaner, more scalable codebase also
facilitates the efficient onboarding of new developers as you expand your team.
Keep your code clean to make life easier for yourself and everyone involved in
the project.
Contributors
This guide was written by Wilmer Lin, a 3D and visual effects artist with over
15 years of industry experience in film and television, who now works as an
independent game developer and educator. Significant contributions were also
made by senior technical content marketing manager Thomas Krogh-Jacobsen
and senior Unity engineers Peter Andreasen, Scott Bilas, and Robert LaCruise.
C L E A N CO D E A LWAYS LO O KS
评论留言