Padrão de Código

Todo projeto de programação que envolva mais de uma pessoa (e de preferência projetos individuais também) deve seguir um padrão de código. Isso evita que cada programador perca tempo "corrigindo" o padrão dos outros, e também estabelece protocolos que facilitam a navegação pelo código. Aqui explicamos o padrão de código usado em em cada linguagem de programaçao usada no USPGameDev.

C++

É a primeira linguagem usada pelo grupo. Como começamos com muita gente, era impraticável chegarmos a um consenso de padrão. Então resolvermos adotar um externo, porque seria mais imparcial. Escolhemos o padrão de código da Google para C++. Mas, desde então, estabelecemos algumas alterações por motivos diversos.

Ordem da inclusão de cabeçalhos

• Padrão da Google: "Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your project's .h."

Uma coisa que aprendemos na UGDK, é que usar essa ordem pode trazer problemas em refatorações mais profundas. Como uma inclusão de cabeçalho basicamente insere o código do arquivo naquela posição do arquivo, há vários efeitos colaterais difíceis de perceber porém potencialmente catastróficos. O principal problema nessa ordem sugerida pela Google é que os cabeçalhos do projeto em si ficam ao final, pois isso significa que eles são compilados usando tudo o que foi incluído antes deles também. Assim, em uma unidade de tradução o cabeçalho "foo.h" pode compilar, mas em outra não, porque ela não inclui antes algum cabeçalho de sistema ou de biblioteca que "foo.h" usa mas por algum deslize não inclui por conta própria.

Portanto, a ordem usada em nossos projetos, com relação à da Google, posiciona os cabeçalhos do projeto antes de tudo. Assim, garantimos que eles incluem aquilo que eles precisam. Além disso, o primeiro cabeçalho de todos deve sempre ser aquele que declara as coisas que a unidade de tradução implementará ou testará (o que já era contemplado pelo padrão da Google, mas vale a pena ressaltar).

Sobrecarga de operadores

• Padrão da Google: "Do not overload operators except in rare, special circumstances. Do not create user-defined literals."

Temos uma grande exceção para esse princípio, que são as classes ugdk::math::Vector2D e ugdk::math::Integer2D. No caso delas, acreditamos que a facilidade de uso e simplicidade dos operadores justifica a sobrecarga deles.

Fora isso, o projeto ouroboros faz umas sobrecargas meio sinistras, mas esse projeto não faz parte do USPGameDev =P.

Exceções de C++

• Padrão da Google: "We do not use C++ exceptions."

Lendo a justificativa da Google, eles explicam que eles não usam exceções de C++ por questões de compatibilidade com código legado dela mesma. Eles deixam claro que isso é uma situação interna deles, logo essa regra não precisa ser usada em outros grupos de desenvolvimento.

E, de fato, nós não a usamos. Pelo contrário, preferimos o uso de exceções.

Uso de streams

• Padrão da Google: "Use streams only for logging."

O argumento principal deles é que deve haver apenas um jeito de fazer I/O, embora tanto operações tradicionais como "printf" quando streams de C++ tenham suas vantagens e desvantagens. No caso da UGDK, o ideal é que ela forneça sua própria interface para operações de I/O (usando a implementação mais conveniente) e todos os projetos que usarem ele devem aderir a essa interface.

Expressões lambda

• Padrão da Google: "Do not use lambda expressions, or the related std::function or std::bind utilities."

FUCK THAT.

Nomes de constantes

• Padrão da Google: "Use a k followed by mixed case: kDaysInAWeek."

Nós usamos simplesmente nomes com todas as letras maiúculas, com cada palavra separada por um underscore. No caso do exemplo da Google, ficaria DAYS_IN_A_WEEK.

Comprimento máximo das linhas de código

• Padrão da Google: "Each line of text in your code should be at most 80 characters long."

Nós estendemos esse comprimento para 100 caracteres, porque nossos monitores são grandes o suficiente.

Identação

• Padrão da Google (identação no geral): "Use only spaces, and indent 2 spaces at a time."
• Padrão da Google (formatação de classes): "Sections in public, protected and private order, each indented one space."

Nós usamos 4 espaços para identação, exceto para os especificadores de acesso (public, protected e private) em classes. Eles são identados apenas 2 espaços, e o que vai dentro deles também fica identado apenas 2 espaços.

E NADA DE TABS (\t).

Lua

TODO