gdscript_styleguide.rst 3.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197
  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 by a blank line.
  47. Use one blank line inside functions to separate logical sections.
  48. One Statement per Line
  49. ~~~~~~~~~~~~~~~~~~~~~~
  50. Never combine multiple statements on a single line. No, C programmers,
  51. not with a single line conditional statement (except with the ternary
  52. operator)!
  53. **Good**:
  54. ::
  55. if position.x > width:
  56. position.x = 0
  57. if flag:
  58. print("flagged")
  59. **Bad**:
  60. ::
  61. if position.x > width: position.x = 0
  62. if flag: print("flagged")
  63. Avoid Unnecessary Parentheses
  64. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  65. Avoid parentheses in expressions and conditional statements. Unless
  66. necessary for order of operations, they only reduce readability.
  67. **Good**:
  68. ::
  69. if is_colliding():
  70. queue_free()
  71. **Bad**:
  72. ::
  73. if (is_colliding()):
  74. queue_free()
  75. Whitespace
  76. ~~~~~~~~~~
  77. Always use one space around operators and after commas. Avoid extra
  78. spaces in dictionary references and function calls, or to create "columns."
  79. **Good**:
  80. ::
  81. position.x = 5
  82. position.y = mpos.y + 10
  83. dict['key'] = 5
  84. myarray = [4, 5, 6]
  85. print('foo')
  86. **Bad**:
  87. ::
  88. position.x=5
  89. position.y = mpos.y+10
  90. dict ['key'] = 5
  91. myarray = [4,5,6]
  92. print ('foo')
  93. **NEVER**:
  94. ::
  95. x = 100
  96. y = 100
  97. velocity = 500
  98. Naming Conventions
  99. ------------------
  100. These naming conventions follow the Godot Engine style. Breaking these
  101. will make your code clash with the built-in naming conventions, which is
  102. ugly.
  103. Classes and Nodes
  104. ~~~~~~~~~~~~~~~~~
  105. Use PascalCase: ``extends KinematicBody``
  106. Also when loading a class into a constant or variable:
  107. ::
  108. const MyCoolNode = preload('res://my_cool_node.gd')
  109. Functions and Variables
  110. ~~~~~~~~~~~~~~~~~~~~~~~
  111. Use snake\_case: ``get_node()``
  112. Prepend a single underscore (\_) to virtual methods (functions the user
  113. must override), private functions, and private variables:
  114. ``func _ready()``
  115. Signals
  116. ~~~~~~~
  117. Use past tense:
  118. ::
  119. signal door_opened
  120. signal score_changed
  121. Constants
  122. ~~~~~~~~~
  123. Use CONSTANT\_CASE, all caps, with an underscore (\_) to separate words:
  124. ``const MAX_SPEED = 200``