C# style guide

Ter convenções de codificação bem definidas e consistentes é importante para todos os projetos, e o Godot não é uma exceção a essa regra.

This page contains a coding style guide, which is followed by developers of and contributors to Godot itself. As such, it is mainly intended for those who want to contribute to the project, but since the conventions and guidelines mentioned in this article are those most widely adopted by the users of the language, we encourage you to do the same, especially if you do not have such a guide yet.


Este artigo não é de forma alguma um guia completo sobre como seguir as convenções de codificação padrão ou as práticas recomendadas. Se você não tiver certeza de um aspecto que não é abordado aqui, consulte a documentação mais abrangente, como C# Coding Conventions ou Framework Design Guidelines.

Language specification

Godot currently uses C# version 7.0 in its engine and example source code. So, before we move to a newer version, care must be taken to avoid mixing language features only available in C# 7.1 or later.

For detailed information on C# features in different versions, please see What's New in C#.


General guidelines

  • Use line feed (LF) characters to break lines, not CRLF or CR.
  • Use um caractere de alimentação de linha no final de cada arquivo, exceto para arquivos csproj.
  • Use UTF-8 encoding without a byte order mark.
  • Use 4 spaces instead of tabs for indentation (which is referred to as "soft tabs").
  • Considere quebrar uma linha em várias se for mais de 100 caracteres.

Line breaks and blank lines

For a general indentation rule, follow the "Allman Style" which recommends placing the brace associated with a control statement on the next line, indented to the same level:

// Use this style:
if (x > 0)

// NOT this:
if (x > 0) {

No entanto, você pode optar por omitir quebras de linha dentro de chaves:

  • Para simples propriedades acessoras.
  • Para inicializadores de simples objeto, array ou coleção.
  • Para auto propriedade abstrata, indexador ou declarações de evento.
// You may put the brackets in a single line in following cases:
public interface MyInterface
    int MyProperty { get; set; }

public class MyClass : ParentClass
    public int Value
        get { return 0; }
            ArrayValue = new [] {value};

Insira uma linha em branco:

  • After a list of using statements.
  • Entre o método, propriedades e declarações de tipo interno.
  • At the end of each file.

Declarações de campos e constantes podem ser agrupadas de acordo com a relevância. Nesse caso, considere inserir uma linha em branco entre os grupos para facilitar a leitura.

Evite inserir uma linha em branco:

  • After {, the opening brace.
  • Before }, the closing brace.
  • After a comment block or a single-line comment.
  • Adjacente a outra linha em branco.
using System;
using Godot;
                                          // Blank line after `using` list.
public class MyClass
{                                         // No blank line after `{`.
    public enum MyEnum
        AnotherValue                      // No blank line before `}`.
                                          // Blank line around inner types.
    public const int SomeConstant = 1;
    public const int AnotherConstant = 2;

    private Vector3 _x;                  // Related constants or fields can be
    private Vector3 _y;                  // grouped together.

    private float _width;
    private float _height;

    public int MyProperty { get; set; }
                                          // Blank line around properties.
    public void MyMethod()
        // Some comment.
        AnotherMethod();                  // No blank line after a comment.
                                          // Blank line around methods.
    public void AnotherMethod()

Using spaces

Insira um espaço:

  • Em torno de um operador binário e ternário.
  • Between an opening parenthesis and if, for, foreach, catch, while, lock or using keywords.
  • Antes e dentro de um bloco de acessador de linha única.
  • Entre os acessadores em um bloco de acessador de linha única.
  • After a comma which is not at the end of a line.
  • After a semicolon in a for statement.
  • After a colon in a single line case statement.
  • Em torno de dois pontos em uma declaração de tipo.
  • Em torno de uma seta lambda.
  • After a single-line comment symbol (//), and before it if used at the end of a line.

Não use um espaço:

  • After type cast parentheses.
  • Dentro de chaves de inicialização de linha única.

The following example shows a proper use of spaces, according to some of the above mentioned conventions:

public class MyClass<A, B> : Parent<A, B>
    public float MyProperty { get; set; }

    public float AnotherProperty
        get { return MyProperty; }

    public void MyMethod()
        int[] values = {1, 2, 3, 4}; // No space within initializer brackets.
        int sum = 0;

        // Single line comment.
        for (int i = 0; i < values.Length; i++)
            switch (i)
                case 3: return;
                    sum += i > 2 ? 0 : 1;

        i += (int)MyProperty; // No space after a type cast.

Convenções de nomes

Use PascalCase for all namespaces, type names and member level identifiers (i.e. methods, properties, constants, events), except for private fields:

namespace ExampleProject
    public class PlayerCharacter
        public const float DefaultSpeed = 10f;

        public float CurrentSpeed { get; set; }

        protected int HitPoints;

        private void CalculateWeaponDamage()

Use camelCase for all other identifiers (i.e. local variables, method arguments), and use an underscore (_) as a prefix for private fields (but not for methods or properties, as explained above):

private Vector3 _aimingAt; // Use a `_` prefix for private fields.

private void Attack(float attackStrength)
    Enemy targetFound = FindTarget(_aimingAt);


There's an exception with acronyms which consist of two letters, like UI, which should be written in uppercase letters where PascalCase would be expected, and in lowercase letters otherwise.

Note that id is not an acronym, so it should be treated as a normal identifier:

public string Id { get; }

public UIManager UI
    get { return uiManager; }

It is generally discouraged to use a type name as a prefix of an identifier, like string strText or float fPower, for example. An exception is made, however, for interfaces, which should, in fact, have an uppercase letter I prefixed to their names, like IInventoryHolder or IDamageable.

Por último, considere a escolha de nomes descritivos e não tente encurtá-los demais se isso afetar a legibilidade.

Por exemplo, se você quiser escrever um código para encontrar um inimigo próximo e acertar com uma arma, prefira:


Ao invés de:


Member variables

Don't declare member variables if they are only used locally in a method, as it makes the code more difficult to follow. Instead, declare them as local variables in the method's body.

Local variables

Declare local variables as close as possible to their first use. This makes it easier to follow the code, without having to scroll too much to find where the variable was declared.

Implicitly typed local variables

Consider using implicitly typing (var) for declaration of a local variable, but do so only when the type is evident from the right side of the assignment:

// You can use `var` for these cases:

var direction = new Vector2(1, 0);

var value = (int)speed;

var text = "Some value";

for (var i = 0; i < 10; i++)

// But not for these:

var value = GetValue();

var velocity = direction * 1.5;

// It's generally a better idea to use explicit typing for numeric values, especially with
// the existence of the `real_t` alias in Godot, which can either be double or float
// depending on the build configuration.

var value = 1.5;

Other considerations

  • Use modificadores de acesso explícito.
  • Use propriedades em vez de campos não privados.
  • Use modifiers in this order: public/protected/private/internal/virtual/override/abstract/new/static/readonly.
  • Avoid using fully-qualified names or this. prefix for members when it's not necessary.
  • Remove unused using statements and unnecessary parentheses.
  • Consider omitting the default initial value for a type.
  • Considere usar operadores condicionais nulos ou digite inicializadores para tornar o código mais compacto.
  • Use uma conversão segura quando houver a possibilidade de o valor ser um tipo diferente e use a conversão direta caso contrário.