gdscript_styleguide.rst 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249
  1. .. _doc_gdscript_styleguide:
  2. GDScript style guide
  3. ====================
  4. Description
  5. -----------
  6. This styleguide lists conventions to write elegant GDScript. The goal is
  7. to encourage writing clean, readable code and promote consistency across
  8. projects, discussions, and tutorials. Hopefully, this will also
  9. encourage development of auto-formatting tools.
  10. Since GDScript is close to Python, this guide is inspired by Python's
  11. `PEP 8 <https://www.python.org/dev/peps/pep-0008/>`__ programming
  12. styleguide.
  13. .. note:: Godot's built-in script editor uses a lot of these conventions
  14. by default. Let it help you.
  15. Code structure
  16. --------------
  17. Indentation
  18. ~~~~~~~~~~~
  19. Indent type: Tabs *(editor default)*
  20. Indent size: 4 *(editor default)*
  21. Each indent level should be one greater than the block containing it.
  22. **Good**:
  23. ::
  24. for i in range(10):
  25. print("hello")
  26. **Bad**:
  27. ::
  28. for i in range(10):
  29. print("hello")
  30. for i in range(10):
  31. print("hello")
  32. Use 2 indent levels to distinguish continuation lines from
  33. regular code blocks.
  34. **Good**:
  35. ::
  36. effect.interpolate_property(sprite, 'transform/scale',
  37. sprite.get_scale(), Vector2(2.0, 2.0), 0.3,
  38. Tween.TRANS_QUAD, Tween.EASE_OUT)
  39. **Bad**:
  40. ::
  41. effect.interpolate_property(sprite, 'transform/scale',
  42. sprite.get_scale(), Vector2(2.0, 2.0), 0.3,
  43. Tween.TRANS_QUAD, Tween.EASE_OUT)
  44. Blank lines
  45. ~~~~~~~~~~~
  46. Surround functions and class definitions with two blank lines:
  47. ::
  48. func heal(amount):
  49. health += amount
  50. health = min(health, max_health)
  51. emit_signal("health_changed", health)
  52. func take_damage(amount, effect=null):
  53. health -= amount
  54. health = max(0, health)
  55. emit_signal("health_changed", health)
  56. Use one blank line inside functions to separate logical sections.
  57. One statement per line
  58. ~~~~~~~~~~~~~~~~~~~~~~
  59. Never combine multiple statements on a single line. No, C programmers,
  60. not with a single line conditional statement (except with the ternary
  61. operator)!
  62. **Good**:
  63. ::
  64. if position.x > width:
  65. position.x = 0
  66. if flag:
  67. print("flagged")
  68. **Bad**:
  69. ::
  70. if position.x > width: position.x = 0
  71. if flag: print("flagged")
  72. Avoid unnecessary parentheses
  73. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  74. Avoid parentheses in expressions and conditional statements. Unless
  75. necessary for order of operations, they only reduce readability.
  76. **Good**:
  77. ::
  78. if is_colliding():
  79. queue_free()
  80. **Bad**:
  81. ::
  82. if (is_colliding()):
  83. queue_free()
  84. Whitespace
  85. ~~~~~~~~~~
  86. Always use one space around operators and after commas. Avoid extra
  87. spaces in dictionary references and function calls, or to create "columns."
  88. **Good**:
  89. ::
  90. position.x = 5
  91. position.y = mpos.y + 10
  92. dict['key'] = 5
  93. myarray = [4, 5, 6]
  94. print('foo')
  95. **Bad**:
  96. ::
  97. position.x=5
  98. position.y = mpos.y+10
  99. dict ['key'] = 5
  100. myarray = [4,5,6]
  101. print ('foo')
  102. **NEVER**:
  103. ::
  104. x = 100
  105. y = 100
  106. velocity = 500
  107. Naming conventions
  108. ------------------
  109. These naming conventions follow the Godot Engine style. Breaking these
  110. will make your code clash with the built-in naming conventions, which is
  111. ugly.
  112. Classes and nodes
  113. ~~~~~~~~~~~~~~~~~
  114. Use PascalCase: ``extends KinematicBody``
  115. Also when loading a class into a constant or variable:
  116. ::
  117. const MyCoolNode = preload('res://my_cool_node.gd')
  118. Functions and variables
  119. ~~~~~~~~~~~~~~~~~~~~~~~
  120. Use snake\_case: ``get_node()``
  121. Prepend a single underscore (\_) to virtual methods (functions the user
  122. must override), private functions, and private variables:
  123. ``func _ready()``
  124. Signals
  125. ~~~~~~~
  126. Use past tense:
  127. ::
  128. signal door_opened
  129. signal score_changed
  130. Constants
  131. ~~~~~~~~~
  132. Use CONSTANT\_CASE, all caps, with an underscore (\_) to separate words:
  133. ``const MAX_SPEED = 200``
  134. Static typing
  135. -------------
  136. Since Godot 3.1, GDScript supports :ref:`optional static typing<doc_gdscript_static_typing>`.
  137. Type hints
  138. ~~~~~~~~~~
  139. Place the colon right after the variable's name, without a space, and let the GDScript compiler infer the variable's type when possible.
  140. **Good**:
  141. ::
  142. onready var health_bar: ProgressBar = get_node("UI/LifeBar")
  143. var health := 0 # The compiler will use the int type
  144. **Bad**:
  145. ::
  146. # The compiler can't infer the exact type and will use Node
  147. # instead of ProgressBar
  148. onready var health_bar := get_node("UI/LifeBar")
  149. When you let the compiler infer the type hint, write the colon and equal signs together: ``:=``.
  150. ::
  151. var health := 0 # The compiler will use the int type
  152. Add a space on either sides of the return type arrow when defining functions.
  153. ::
  154. func heal(amount: int) -> void: