Difference between revisions of "Coding Standards/pt-br"

Latest revision as of 14:24, July 9, 2015

Padrões de Codificação Básica Em Um Nutshell

empacotamento de palavra (word wrap) de até 160 caracteres
utilize tabs, não espaços, para endentação
utilize um tamanho de tab de 4 caracteres (o tamanho de tab pode ser ajustado, mas isso afeta quando você alcançar o limite de empacotamento mágico de 160 caracteres)
comentários em linhas separadas, no mesmo nível de recuo como código (seções podem ser marcadas por comentários 'outdented')

Empacotamento de Palavra (Word Wrap)

Editores modernos fazem um bom trabalho exibindo linhas de texto muito longas, e exibições modernas tem resolução o suficiente para exibições muito superior do que 80 caracteres por linha, mesmo em resolução 1024x768. Você não deve definitivamente dividir pedaço de código elegante de linha única somente pelo argumento de manter a coisa toda sob 80 caracteres. Isso é especialmente ruim se você pegar, digamos, uma linha de 100 caracteres e dividi-la em mais do que duas linhas somente pelo argumento de mantê-lo sob 80 caracteres de largura. Mas você precisa ou quer usar múltiplas linhas para manter seu código legível, mais poder para você. Somente não faça isso para manter "com compatibilidade com cartão de 80 colunas Apple IIe" por qualquer rasão. Isso é simplesmente bobagem.

Tabulações vs. Espaços

Tabulações e espaços tinham uma luta. Tabulações venciam. Eles são mais fáceis de lidar e permite endentação configurável para aqueles que necessitam disso. Eu não me importo com o que alguns outro grupo ou organização diga que convenção seja. Se você não quiser utilizar tabs por que você quer que todos os seus comentários de final de linha apareçam bonitos belamente, então eu tenho uma solução: não utilize comentários de final de linha (veja a próxima seção) e você ficará bem.

Commentários

Adicione comentários que proporcionam alguma ideia sobre seu código, e que ajude a proporcionar contexto. Também, por que nós utilizamos tabs, posicionam comentários em suas próprias linhas, separam do código fonte, idealmente separados por uma linha em branco acima e abaixo ao menos que você esteja comentando em verboso cada linha de código. Isso também encoraja a comentários mais longos, mais descritivos que possam abranger múltiplas linhas. Se você abranger múltiplas linhas, utilize uma margem direita consistente de 160 caracteres. Comentários lhe ajudam a entender seu código quando você voltar a ele um ano depois, então está adicionando comentários descritivos para si mesmo o tanto o quanto para outros. Inclua informação que você acharia prestativa se você tivesse um caso repentino de amnésia. Eles são especialmente importantes para o software livre e de código aberto que precisam ser mantidos por várias pessoas ao longo dos anos.

Profanação

Não insira qualquer profanação nos comentários do código fonte ou nos nomes de variáveis. Isso somente te faz parecer não profissional, bobo e incompetente.

@@ Line 1: / Line 1: @@
-== Padrão de Codificação Básica Em Um Nutshell ==
+== Padrões de Codificação Básica Em Um Nutshell ==
 * empacotamento de palavra (word wrap) de até 160 caracteres
@@ Line 10: / Line 10: @@
 Editores modernos fazem um bom trabalho exibindo linhas de texto muito longas, e exibições modernas tem resolução o suficiente para exibições muito superior do que 80 caracteres por linha, mesmo em resolução 1024x768. Você não deve definitivamente dividir pedaço de código elegante de linha única somente pelo argumento de manter a coisa toda sob 80 caracteres. Isso é especialmente ruim se você pegar, digamos, uma linha de 100 caracteres e dividi-la em ''mais'' do que duas linhas somente pelo argumento de mantê-lo sob 80 caracteres de largura. Mas você precisa ou quer usar múltiplas linhas para manter seu código legível, mais poder para você. Somente não faça isso para manter "com compatibilidade com cartão de 80 colunas Apple IIe" por qualquer rasão. Isso é simplesmente bobagem.
-== Tabs vs. Spaces ==
+== Tabulações vs. Espaços ==
-Tabs and spaces had a fight. Tabs won. They're easier to deal with and allow configurable indentation for those who require it. I don't care what some other group or organization says the convention is. If you don't want to use tabs because you want all your end-of-line comments to line up beautifully, then I have a solution: don't use end-of-line comments (see the next section) and you'll be fine.
+Tabulações e espaços tinham uma luta. Tabulações venciam. Eles são mais fáceis de lidar e permite endentação configurável para aqueles que necessitam disso. Eu não me importo com o que alguns outro grupo ou organização diga que convenção seja. Se você não quiser utilizar tabs por que você quer que todos os seus comentários de final de linha apareçam bonitos belamente, então eu tenho uma solução: não utilize comentários de final de linha (veja a próxima seção) e você ficará bem.
+== Commentários ==
+Adicione comentários que proporcionam alguma ideia sobre seu código, e que ajude a proporcionar contexto. Também, por que nós utilizamos tabs, posicionam comentários em suas próprias linhas, separam do código fonte, idealmente separados por uma linha em branco acima e abaixo ao menos que você esteja comentando em verboso cada linha de código. Isso também encoraja a comentários mais longos, mais descritivos que possam abranger múltiplas linhas. Se você abranger múltiplas linhas, utilize uma margem direita consistente de 160 caracteres. Comentários lhe ajudam a entender seu código quando você voltar a ele um ano depois, então está adicionando comentários descritivos para si mesmo o tanto o quanto para outros. Inclua informação que você acharia prestativa se você tivesse um caso repentino de amnésia. Eles são especialmente importantes para o software livre e de código aberto que precisam ser mantidos por várias pessoas ao longo dos anos.
+== Profanação ==
+Não insira qualquer profanação nos comentários do código fonte ou nos nomes de variáveis. Isso somente te faz parecer não profissional, bobo e incompetente.
+[[Category:QA]]
+[[Category:pt_BR]]