Differences

This shows you the differences between two versions of the page.

--- pt:manual:contrib:coding_style_guidelines [2020/11/19 02:34]
i3_relativism [Descricao]
+++ pt:manual:contrib:coding_style_guidelines [2024/10/25 15:34] (current)
luck02 [Descrição]
@@ Line 1: / Line 1: @@
-====== Diretrizes de Estilo de Desenvolvimento do Codigo HyperbolaBSD ======
+...(WIP)
+====== Diretrizes do Modelo de Desenvolvimento do Código HyperbolaBSD ======
-===== Descricao =====
+===== Descrição =====
-Este artigo especifica o estilo preferido para o desenvolvimento do codigo fonte do kernel <color #0BB928/#DDFFE3>HyperbolaBSD</color>.E tambem um guia para o estilo preferido de desenvolvimento do codigo fonte no resto do sistema. Este guia devera ser seguido para todo o novo codigo. Em geral, codigo pode ser considerado “novo codigo” quando constitui a volta de 50% ou mais ficheiros com alteracoes. Isto e suficiente para romper precedentes no codigo existente, e poder utilizar o estilo referido neste guia.
+Este artigo especifica o modelo preferido para o desenvolvimento do código fonte do kernel <color #0BB928/#DDFFE3>HyperbolaBSD</color>. É também um guia para o modelo preferido de desenvolvimento do codigo fonte no resto do sistema. Este guia deverá ser seguido para todo o novo código. Em geral, código pode ser considerado “novo código” quando constitui a volta de 50% ou mais arquivos com alterações. Isto é o suficiente para romper precedentes no código existente, e poder utilizar o modelo referido neste guia.
 <code c>
 /*
- * Guia de Estilo de o HyperbolaBSD KNF (Kernel Normal Form).
+ * Guia do modelo do HyperbolaBSD KNF (Kernel Normal Form).
  */
 /*
- * Comentarios MUITO importantes de linha unica representam-se assim.
+ * Comentários MUITO importantes de linha única representam-se assim.
  */
-/* A maior parte de os comentarios de linha unica representam-se assim. */
+/* A maior parte dos comentários de linha única representam-se assim. */
 /*
@@ Line 21: / Line 22: @@
 </code>
-Os ficheiros include do kernel (ex., <color #620BB9/#EEDDFF><sys/*.h></color>) , normalmente, apresentam-se primeiro, ira percisar de <color #620BB9/#EEDDFF><sys/types.h></color> ou <color #620BB9/#EEDDFF><sys/param.h></color>, mas nunca ambos!  <color #620BB9/#EEDDFF><sys/types.h></color> inclui <color #620BB9/#EEDDFF><sys/cdefs.h></color>, e nao ha problema de dependder disso.
+Os arquivos include do kernel (ex., <color #620BB9/#EEDDFF><sys/*.h></color>) , normalmente, apresentam-se primeiro, irá percisar de <color #620BB9/#EEDDFF><sys/types.h></color> ou <color #620BB9/#EEDDFF><sys/param.h></color>, mas nunca ambos!  <color #620BB9/#EEDDFF><sys/types.h></color> inclui <color #620BB9/#EEDDFF><sys/cdefs.h></color>, e não há problema de depender disso.
 <code c>
-#include <sys/types.h>  /* ficheiros include nao-locais em **!?brackets?!**. */
+#include <sys/types.h>  /* arquivos include não-locais em **!?brackets?!**. */
 </code>
-Se for um programa de rede, ponha od ficheiros include relacionados com rede em sequencia.
+Se for um programa de rede, ponha o arquivo include relacionados com rede em sequencia.
 <code c>
@@ Line 36: / Line 37: @@
 </code>
-Deixe uma linha em branco, seguida por ficheiros<color #0B71B9/#DDF1FF>/usr/include</color>.   Os ficheiros <color #0B71B9/#DDF1FF>/usr/include</color> , na generalidade, deveram estar organizados.
+Deixe uma linha em branco, seguida por arquivos<color #0B71B9/#DDF1FF>/usr/include</color>.   Os arquivos <color #0B71B9/#DDF1FF>/usr/include</color> , na generalidade, deveram estar organizados.
-Pathnames globais estao definidos em <color #0B71B9/#DDF1FF>/usr/include/paths.h</color>. Pathnames locais para um program, em especifico, estao definidos em pathnames.h no drectorio local.
+Pathnames globais estão definidos em <color #0B71B9/#DDF1FF>/usr/include/paths.h</color>. Pathnames locais para um programa, em especifico, estão definidos em pathnames.h no diretório local.
 <code c>
@@ Line 44: / Line 45: @@
 </code>
-Deixe uma linha em branco, seguida pelos ficheiros iclude relativos ao usuario.
+Deixe uma linha em branco, seguida para os arquivos iclude relativos ao usuário.
 <code c>
-#include "pathnames.h"  /* ficheiros locais includes em cotacoes duplas. */
+#include "pathnames.h"  /* arquivos locais includes em cotações duplas. */
 </code>
-Todas as funcoes necessitam de ser initializadas com um prototipo da mesma.
+Todas as funções necessitam de ser initializadas com um prototipo da mesma.
-Prototipos de funcoes privadas (ex., funcoes que nao sao utilizadas externamente) apresentam-se no topo do primeiro modulo de fonte. No sistema de usuario, funcoes locais de um modulo em especifico devrao ser declaradas como '<color #620BB9/#EEDDFF>static</color>'. Isto nao devera ser feito no kernel, pois impossiblita o uso de um debugger para o kernel.
+Prototipos de funções privadas (ex., funções que não são utilizadas externamente) apresentam-se no topo do primeiro módulo de fonte. No sistema do usuário, funções locais de um módulo em especifico deverão ser declaradas como '<color #620BB9/#EEDDFF>static</color>'. Isto não deverá ser feito no kernel, pois impossiblita o uso de um debugger para o kernel.
-Funcoes usadas por outras partes do kernel deverao ser initializadas com um prototipo no ficheiro include relevante, a mesma.
+Funções usadas por outras partes do kernel deverãoo ser inicializadas com um protótipo no arquivo include relevante, a mesma.
-Funcoes que sao utilizadas localmente em mais de um modulo fonte, apresenta-se num ficheiro header em separado, (ex., <color #0B71B9/#DDF1FF>extern.h</color>).
+Funções que são utilizadas localmente em mais de um módulo fonte, apresenta-se num arquivo header em separado, (ex., <color #0B71B9/#DDF1FF>extern.h</color>).
-Prototipos nao deveram incluir nomes de variaveis com os tipos; ex.,
+Prototipos não deveram incluir nomes de variáveis com os tipos; ex.,
 <code c>
@@ Line 70: / Line 71: @@
 </code>
-Prototipos poderam ter um espaco extra depois do tab para activar alinhamento dos nomes de funcoes:
+Prototipos poderam ter um espaço extra depois do tab para ativar o alinhamento dos nomes das funções:
 <code c>
@@ Line 77: / Line 78: @@
 </code>
-Nao devera haver espaco entre o nome de funcao e a lista de argumentos.
+Não deverá haver espaço entre o nome da função e a lista dos argumentos.
 Utilize <color #620BB9/#EEDDFF>%%__dead%%</color> de <color #620BB9/#EEDDFF><sys/cdefs.h></color> para funcoes que nao correm, ex.,
@@ Line 85: / Line 86: @@
 </code>
-Nos ficheiros header, introduza prototipos de funcoes conpreendidos por <color #620BB9/#EEDDFF>%%__BEGIN_DECLS%%</color> / <color #620BB9/#EEDDFF>%%__END_DECLS%%</color> como pares.  Isto torna os ficheiros header utilizaveis para <color #0B71B9/#DDF1FF>C++</color>.
+Nos arquivos header, introduza os prototipos das funções conpreendidos por <color #620BB9/#EEDDFF>%%__BEGIN_DECLS%%</color> / <color #620BB9/#EEDDFF>%%__END_DECLS%%</color> como pares.  Isto torna os ficheiros header utilizaveis para <color #0B71B9/#DDF1FF>C++</color>.
-Macros sao capitalizados e apresentados entre parentises, e deveram evitar efeitos-secundarios. Se estes sao um acrescento em serie de uma funcao, a funcao e num todo defenida em lowercase; a macro tem o mesmo nome num todo mas em uppercase. Se a macro necessita mais de uma linha, utilize **!?!braces!?!**. Right-justify the backslashes, visto que a defenicao resultante e mais facil de ler. Se a macro emcapusula um **!?!compound statement!?!**, incorpore esta num loop "<color #620BB9/#EEDDFF>do</color>", para que esta possa ser utilizada em seguranca num “<color #620BB9/#EEDDFF>if</color>” **!?!statements!?!**. Qualquer ponto-virgula, utilizado como terminacao devera ser ?!obtida?! pela invocacao da macro e nao pela mesma, para fazer com que este possa ser parsable, para ?!concatenacao!? e editores de texto.
+Macros são capitalizados e apresentados entre parenteses, e deveram evitar efeitos-secundários. Se estes são acrescentados em série de uma função, a função é num todo defenida em lowercase; a macro tem o mesmo nome num todo mas em uppercase. Se a macro necessita mais de uma linha, utilize **!?!braces!?!**. Right-justify the backslashes, visto que a defenicao resultante e mais fácil de ler. Se a macro emcapusula um **!?!compound statement!?!**, incorpore esta num loop "<color #620BB9/#EEDDFF>do</color>", para que esta possa ser utilizada com segurança num “<color #620BB9/#EEDDFF>if</color>” **!?!statements!?!**. Qualquer ponto-virgula, utilizado como terminação devera ser ?!obtida?! pela invocacao da macro e nao pela mesma, para fazer com que este possa ser parsable, para ?!concatenação!? e editores de texto.
 <code c>
@@ Line 96: / Line 97: @@
 </code>
-Valores de enumeracao sao todos em **!?!uppercase!?!**.
+Valores de enumeração são todos em **!?!uppercase!?!**.
 <code c>
@@ Line 102: / Line 103: @@
 </code>
-Na definicao de integers nao atribuidos utilize “<color #620BB9/#EEDDFF>unsigned int</color>” em vez de somente “<color #620BB9/#EEDDFF>unsigned</color>”; o anterior tem sido uma fonte de confusao no passado.
+Na definicao de integers não atribuidos utilize “<color #620BB9/#EEDDFF>unsigned int</color>” em vez de somente “<color #620BB9/#EEDDFF>unsigned</color>”; o anterior tem sido uma fonte de confusão no passado.
-Na declaracao de variaveis em estruturas, declare-as organizadas por uso, por seguida tamanho (maior para mais pequeno), e finalmente por ordem alfabetica. Normalmente a primeira categoria, nao se aplica, mas existem exepcoes. Cada uma apresentase numa linha separada. Introduza uma tab apos a primeira palavra, (ex., utilize ‘<color #620BB9/#EEDDFF>int^Ix;</color>’ e ‘<color #620BB9/#EEDDFF>struct^Ifoo *x;</color>’).
+Na declaração de variáveis nas estruturas, declare-as organizadas por uso, em seguida tamanho (maior para mais pequeno), e finalmente por ordem alfabética. Normalmente a primeira categoria, não se aplica, mas existem exepções. Cada uma apresentase numa linha separada. Introduza uma tab após a primeira palavra, (ex., utilize ‘<color #620BB9/#EEDDFF>int^Ix;</color>’ e ‘<color #620BB9/#EEDDFF>struct^Ifoo *x;</color>’).
-Estruturas mais relevantes deveram ser declaradas no topo do ficheiro que estas estejam a ser usadas, ou em ficheiros header separados, se estas forem utilizadas em varios ficheiros fonte. A utilizacao de estrutura devera ser separada por declaracoes e estas deveram ser <color #620BB9/#EEDDFF>externas</color> se forem declaradas nos ficheiros header.
+Estruturas mais relevantes deveram ser declaradas no topo do arquivo que estas estejam a ser usadas, ou nos arquivos header separados, se estas forem utilizadas em vários arquivos fonte. A utilização de estrutura devera ser separada por declaracoes e estas deveram ser <color #620BB9/#EEDDFF>externas</color> se forem declaradas nos arquivos header.
 <code c>
@@ Line 117: / Line 118: @@
 </code>
-Utilize macros <color #620BB9/#EEDDFF>ordenadas</color> em vez de se basear na sua propria lista, quando posivel. Portantos o exemplo anterior poderia ser melhorado:
+Utilize macros <color #620BB9/#EEDDFF>ordenadas</color> em vez de se basear na sua própria lista, quando possível. Portanto, o exemplo anterior poderia ser melhorado:
 <code c>
@@ Line 129: / Line 130: @@
 </code>
-Evite utilizar typedefs para estruturas. Pois isto impossiblita o uso de pointers de uma foma opaca por parte das aplicacoes, que e tanto possivel como benefico utilizar **!?ordinary tags?!** de uma estrutura. Quando a convencao requere typedef, utilize um nome que corresponde ao **!?struct tag?!**. Evite typedefs que terminao em “<color #620BB9/#EEDDFF>_t</color>”, excepto quando especificado no<color #0BB928/#DDFFE3>Standard C</color>  ou pelo <color #0BB928/#DDFFE3>POSIX</color>.
+Evite utilizar typedefs para estruturas. Pois isto impossiblita o uso de pointers de uma foma opaca por parte das aplicações, que e tanto possível como benefico utilizar **!?ordinary tags?!** de uma estrutura. Quando a convenção requer typedef, utilize um nome que corresponde ao **!?struct tag?!**. Evite typedefs que terminão em “<color #620BB9/#EEDDFF>_t</color>”, exceto quando especificado no<color #0BB928/#DDFFE3>Standard C</color>  ou pelo <color #0BB928/#DDFFE3>POSIX</color>.
 <code c>
@@ Line 144: / Line 145: @@
 </code>
-Para haver consistencia, <color #620BB9/#EEDDFF>getopt</color> deveria ser usado para parsear as opcoes. Estas deverao ser ordenadas no call getopt e no **!?switch?!**, a excepcao do **!?switch cascade?!**. Elementos do **!?switch statement?!** que o cascade deveria ter um comentario **!?<color #620BB9/#EEDDFF>FALLTHROUGH</color>?!**. Argumentos Numericos deverao ser verificados para precisao.
+Para haver consistencia, <color #620BB9/#EEDDFF>getopt</color> deveria ser usado para parsear as opções. Estas deverão ser ordenadas no call getopt e no **!?switch?!**, a excepção do **!?switch cascade?!**. Elementos do **!?switch statement?!** que o cascade deveria ter um comentário **!?<color #620BB9/#EEDDFF>FALLTHROUGH</color>?!**. Argumentos Numericos deverão ser verificados para precisão.
 <code c>
@@ Line 170: / Line 171: @@
 </code>
-Utilize um espaco depois de palavras chave (<color #620BB9/#EEDDFF>if</color>, <color #620BB9/#EEDDFF>while</color>, <color #620BB9/#EEDDFF>for</color>, <color #620BB9/#EEDDFF>return</color>, <color #620BB9/#EEDDFF>switch</color>). Os parentices nao sao utilizados para **!?statements!?** de controlo com nehuma ou apenas uma simples **!?statement?!**, a excepcao de essa **!?statement?!** for mais de uma linha, que nesse caso sao permitidas.
+Utilize um espaço depois das palavras chave (<color #620BB9/#EEDDFF>if</color>, <color #620BB9/#EEDDFF>while</color>, <color #620BB9/#EEDDFF>for</color>, <color #620BB9/#EEDDFF>return</color>, <color #620BB9/#EEDDFF>switch</color>). Os parentises não são utilizados para **!?statements!?** de controle com nehuma ou apenas uma simples **!?statement?!**, a exceção dessa **!?statement?!** for mais de uma linha, que nesse caso são permitidas.
 <code c>
@@ Line 188: / Line 189: @@
 </code>
-Algumas partes de um <color #620BB9/#EEDDFF>for</color> loop poderao ser deixadas em branco.
+Algumas partes de um <color #620BB9/#EEDDFF>for</color> loop poderão ser deixadas em branco.
 <code c>
@@ Line 197: / Line 198: @@
 </code>
-Identacao e um **!?tab?!** de 8 caractres. Identacao de segundo nivel sao quatro espacos. Todo o codigo deve caber em 80 colunas.
+Identação é um **!?tab?!** de 8 caractres. Identaçãoo de segundo nível são quatro espaços. Todo o código deve caber em 80 colunas.
 <code c>
@@ Line 206: / Line 207: @@
 </code>
-Nao adicione espacos em branco no final da linha, e somente utilize **!?tabs?!** seguidos de espacos para criar a identacao. Nao utilize mais espacos que um **!?tab?!** ira produzir, e nao utilize estes antes de espacos.
+Não adicione espaços em branco no final da linha, e somente utilize **!?tabs?!** seguidos de espaços para criar a identação. Não utilize mais espaços que um **!?tab?!** ira produzir, e não utilize estes antes de espaços.
-Abertura e fecho de parentises apresentam-se na mesma linha que os anteriores. Parentises desnecessarios poderam poderam ser omitidos, a nao ser que estes causem um erro de compilamento.
+Abertura e fechamento de parentises apresentam-se na mesma linha que os anteriores. Parentises desnecessarios poderam ser omitidos, a não ser que estes causem um erro de compilamento.
 <code c>
@@ Line 220: / Line 221: @@
 </code>
-Nao utilize espacos depois de nomes de funcoes. Virgulas apresentam um espaco apos as mesmas. Nao utilize espacos depois dos seguintes caracteres: ‘<color #620BB9/#EEDDFF>(</color>’ ou ‘<color #620BB9/#EEDDFF>[</color>’ ou precedendo ‘<color #620BB9/#EEDDFF>]</color>’ or ‘<color #620BB9/#EEDDFF>)</color>’.
+Não utilize espaços depois dos nomes das funções. Virgulas apresentam um espaço após as mesmas. Não utilize espaços depois dos seguintes caracteres: ‘<color #620BB9/#EEDDFF>(</color>’ ou ‘<color #620BB9/#EEDDFF>[</color>’ ou precedendo ‘<color #620BB9/#EEDDFF>]</color>’ or ‘<color #620BB9/#EEDDFF>)</color>’.
 <code c>
@@ Line 227: / Line 228: @@
 </code>
-Operadores unitarios nao requerem espacos; ao contrario dos operadores binarios. Nao utilize parentises a nao ser que estes sejam requeridos para precedencia, e que o **!?statement?!** se torne confuso sem a existencia destes, a nao ser que estes causem um erro de compilamento. Lembre-se que esta pratica podera confudir outros.
+Operadores unitarios não requerem espaços; ao contrário dos operadores binários. Não utilize parentises a não ser que estes sejam requeridos para precedencia, e que o **!?statement?!** se torne confuso sem a existencia destes, a não ser que estes causem um erro de compilamento. Lembre-se que esta prática podera confudir outros.
 <code c>
@@ Line 234: / Line 235: @@
 </code>
-Exits deverao utilizar <color #620BB9/#EEDDFF>0</color> para representar sucesso, ou diferente de zero para erros.
+Exits deverão utilizar <color #620BB9/#EEDDFF>0</color> para representar sucesso, ou diferente de zero para erros.
 <code c>
 /*
- * Tente evitar comentarios obvios, como:
+ * Tente evitar comentários obvios, como:
  * "Exit 0 com successo."
  */
@@ Line 244: / Line 245: @@
 </code>
-Esta tipo de funcao devera se apresentar numa linha separada, precedendo a propria funcao.
+Este tipo de função deverá se apresentar numa linha separada, precedendo a própria função.
 <code c>
@@ Line 252: / Line 253: @@
 </code>
-Ao declarar variaveis de funcoes, declare-as organizadas por uso, por seguida tamanho (maior para mais pequeno), e finalmente por ordem alfabetica; multipas por linha sao aceites. Declaracoes de funcoes de acordo com o estilo antigo deverao ser evitadas. Declaracoes de funcoes que utilizao o estilo ANSI deverao ser emvez postas num ficheiro include, como por exemplo “<color #0B71B9/#DDF1FF>extern.h</color>”. Se acontecer um "overflow" numa das linhas, reutilize o tipo da palavra-chave.
+Ao declarar variáveis das funções, declare-as organizadas por uso, por seguida tamanho (maior para mais pequeno), e finalmente por ordem alfabética; multipas por linha são aceites. Declaracoes de funções de acordo com o estilo antigo deverao ser evitadas. Declaracoes de funcoes que utilizao o estilo ANSI deverão ser em vez postas num arquivo include, como por exemplo “<color #0B71B9/#DDF1FF>extern.h</color>”. Se acontecer um "overflow" numa das linhas, reutilize o tipo da palavra-chave.
-enha cuidade para nao ofuscar codigo, atraves da intializacao de variaveis em declaracoes. Utilize esta tecnica apenas da maneira correcta. NAO UTILIZE chamadas de funcoes em **!?initializers"!?**.
+Tenha cuidado para não ofuscar o código, através da utilização de variaveis em declarações. Utilize esta técnica apenas da maneira correcta. NãO UTILIZE chamadas de funções em **!?initializers"!?**.
 <code c>
@@ Line 265: / Line 266: @@
 </code>
-Nao declare funcoes dentro de outras funcoes.
+Não declare funções dentro de outras funções.
 Casts and <color #620BB9/#EEDDFF>sizeof()</color> calls are not followed by a space.  Note that indent does not understand this rule.
-A utilizacao do **specificador?!** "<color #620BB9/#EEDDFF>register</color>" em novo codigom, nao e a melhor pratica. A optimizacao de compiladores como o <color #0BB928/#DDFFE3>gcc</color>, e normalmente a melhor via para a excolha de variaveis a colocar nos "registers" para melhor a performance do codigo. A execpcao disto e em funcoes com contem codigo assembly onde o especificador "<color #620BB9/#EEDDFF>register</color>" e requerido para uma generacao de codigo apropriada, nao ausencia de optimizacao de compilador.
+A utilização do **specificador?!** "<color #620BB9/#EEDDFF>register</color>" em novo código, não é a melhor prática. A otimização dos compiladores como o <color #0BB928/#DDFFE3>gcc</color>, é normalmente a melhor via para a excolha de variaveis a colocar nos "registers" para melhor a performance do código. A exeção disto é em funções que contém código assembly onde o especificador "<color #620BB9/#EEDDFF>register</color>" e requerido para uma generacao de codigo apropriada, não ausencia de optimizacao de compilador.
-Na utilizacao de <color #620BB9/#EEDDFF>longjmp()</color> ou <color #620BB9/#EEDDFF>vfork()</color> num programa, a **!?bandeira?!** <color #620BB9/#EEDDFF>-W</color> ou <color #620BB9/#EEDDFF>-Wall</color>, devera ser usada para verificar que o compilador nao cria erros como:
+Na utilização de <color #620BB9/#EEDDFF>longjmp()</color> ou <color #620BB9/#EEDDFF>vfork()</color> num programa, a **!?bandeira?!** <color #620BB9/#EEDDFF>-W</color> ou <color #620BB9/#EEDDFF>-Wall</color>, deverá ser usada para verificar que o compilador não cria erros como:
 <code c>
@@ Line 277: / Line 278: @@
 </code>
-Se qualquer erro de este tipo ocurrer, devera aplicar o "type-qualifier"(=qualificador de tipo), na variavel em questao como "<color #620BB9/#EEDDFF>volatile</color>". A Enexistencia do mesmo podera resultar em generacao de codigo impropria, quando optimizacai esta ativa. Verifique que para pointers, a localizacao de “<color #620BB9/#EEDDFF>volatile</color>” especifica se o qualificador de tipo se aplica para esse pointer, ou mesmo para onde este estara a ser apontado. Um apontador volatil e declarado com “<color #620BB9/#EEDDFF>volatile</color>” a direita do "<color #620BB9/#EEDDFF>*</color>". Exemplo:
+Se qualquer erro deeste tipo ocorrer, deverá aplicar o "type-qualifier"(=qualificador de tipo), na variavel em questão como "<color #620BB9/#EEDDFF>volatile</color>". A Enexistencia do mesmo podera resultar em generação de código impropria, quando otimização estar ativa. Verifique que para pointers, a localização de “<color #620BB9/#EEDDFF>volatile</color>” especifica se o qualificador de tipo se aplica para esse pointer, ou mesmo para onde este estara a ser apontado. Um apontador volatil e declarado com “<color #620BB9/#EEDDFF>volatile</color>” a direita do "<color #620BB9/#EEDDFF>*</color>". Exemplo:
 <code c>
@@ Line 295: / Line 296: @@
 </code>
-“<color #620BB9/#EEDDFF>const</color>” e tambem um qualificado de tipo e as mesmas regras se aplicam. A descricao de "register" **!?read-only?!** do hardware, podera se apresentar como :
+“<color #620BB9/#EEDDFF>const</color>” e também um qualificado de tipo e as mesmas regras se aplicam. A descrição de "register" **!?read-only?!** do hardware, podera se apresentar como :
 <code c>
@@ Line 303: / Line 304: @@
 Bandeiras globais defenidas dentro de **!?handlers?!** de sinais deverao ser do tipo “<color #620BB9/#EEDDFF>volatile sig_atomic_t</color>” se possivel. Isto garante que a variavel podera ser acedida como identidade atomica, mesmo quando o sinal tenha sido recebido. Nao e garantido que variaveis globais de outros tipos (como estruturas) quando acedidas por **!?handlers?!** de sinais.
-NULL e a contaste preferida para apontadores nulos. Utilize <color #620BB9/#EEDDFF>NULL</color> em vez de <color #620BB9/#EEDDFF>(type *)0</color> ou <color #620BB9/#EEDDFF>(type *)NULL</color> em todos os casos execpto para argumentos para funcoes **!?variadic?!**, onde o compilador nao tem conhecimento dos tipos do mesmo.
+NULL e a contaste preferida para apontadores nulos. Utilize <color #620BB9/#EEDDFF>NULL</color> em vez de <color #620BB9/#EEDDFF>(type *)0</color> ou <color #620BB9/#EEDDFF>(type *)NULL</color> em todos os casos execeto para argumentos para funções **!?variadic?!**, onde o compilador não tem conhecimento dos tipos do mesmo.
-Nao utilize ‘<color #620BB9/#EEDDFF>!</color>’ para testes a nao ser que seja uma expressao boolean, ex., utilize
+Não utilize ‘<color #620BB9/#EEDDFF>!</color>’ para testes a não ser que seja uma expressão boolean, ex., utilize
 <code c>
@@ Line 311: / Line 312: @@
 </code>
-nao
+não
 <code c>
@@ Line 317: / Line 318: @@
 </code>
-**!?Routines?!** que retornam <color #620BB9/#EEDDFF>void *</color> nao deveriam ter os seus avlores de **!?return?!** **cast** para qualquer tipo de apontador  to any pointer type.
+**!?Routines?!** que retornam <color #620BB9/#EEDDFF>void *</color> não deveriam ter os seus valores de **!?return?!** **cast** para qualquer tipo de apontador  to any pointer type.
-Utilize as familias de funcoes <color #620BB9/#EEDDFF>err</color> e <color #620BB9/#EEDDFF>warn</color>. Nao utilize as suas proprias **!?!?!"roll/rolling"**
+Utilize as familias de funções <color #620BB9/#EEDDFF>err</color> e <color #620BB9/#EEDDFF>warn</color>. Nao utilize as suas proprias **!?!?!"roll/rolling"**
 <code c>
@@ Line 329: / Line 330: @@
 </code>
-Funcoes de estilo antigo apresentam-se desta maneira:
+Funções desse modelo do antigo apresentam-se desta maneira:
 <code c>
@@ Line 342: / Line 343: @@
 </code>
-Utilize declaracoes de funcoes <color #0BB928/#DDFFE3>ANSI</color>, a exepcao da necessidade de compatibilade K&R. Listas longas de parametros apresentam-se com a identacao normal de quatro espacos.
+Utilize declarações de funções <color #0BB928/#DDFFE3>ANSI</color>, a exeção da necessidade de compatibilade K&R. Listas longas de parametros apresentam-se com a identação normal de quatro espaços.
 Numeros variaveis de argumentos devem-se apresentar desta maneira:
@@ Line 367: / Line 368: @@
 </code>
-Expressoes de uso deverao-se apresentar da mesma forma que a synopsis das pagina do manual. Opcoes sem **!?operands=operandos?!**apresentam-se em primeiro lugar, por ordem alfabetca dentro de um unico conjunto de parentises, seguido de opcoes com **operandos ou operadores verificar**, por ordem alfabetca dentro de parentises em pares, seguido de argumentos requeridos na ordem em que estes estao especificados, seguidos de argumentos opcionais tambem na ordem em que estes estao especificados.
+Expressões de uso deverão se apresentar da mesma forma que a synopsis da página do manual. Opções sem **!?operands=operandos?!**apresentam-se em primeiro lugar, por ordem alfabétca dentro de um único conjunto de parentises, seguido das opções com **operandos ou operadores verificar**, por ordem alfabetca dentro de parentises em pares, seguido de argumentos requeridos na ordem em que estes estão especificados, seguidos de argumentos opcionais também na ordem em que estes estão especificados.
-Utilize uma barra (‘<color #620BB9/#EEDDFF>|</color>’) para separar quer argumentos e opcoes, ou quer argumentos e opcoes multiplas que sejam especificadas juntas e que sejam postas num unico conjunto de parentises.
+Utilize uma barra (‘<color #620BB9/#EEDDFF>|</color>’) para separar quer argumentos e opções, ou quer argumentos e opções multiplas que sejam especificadas juntas e que sejam postas num único conjunto de parentises.
 Se numeros sao utilizados como opcoes, estes deveram se apresentar primeiro, como mostra o exemplo a baixo. letras em **Uppercase** tem precedencia de letras em **lowercase**.
@@ Line 384: / Line 385: @@
 </code>
-Novo codigo base de kernel devera ser rasoavelmente repeitador destes parametros de estilo. Os parametros para modulos mantidos por terceiros, e drivers de **!?devices?!** poderam nao ter de seguir estes a risca, mas no minimo deverao ter alguma coerencia nesse mesmo estilo.
+Novo código base de kernel deverá ser rasoavelmente respeitado destes parametros de modelo. Os parametros para modulos mantidos por terceiros, e drivers de **!?devices?!** poderam não ter de seguir estes a risca, mas no minimo deverão ter alguma coerencia nesse mesmo modelo.
-Sempre que possivel, codigo devera correr atraves de um verificador de codigo (ex., “<color #620BB9/#EEDDFF>gcc -Wall -W -Wpointer-arith -Wbad-function-cast ...</color>” or splint from the ports tree) e produzir o minimo de erros possivel. Visto que **!?lint?!** foi removido, o unico comentario no estilo **lint** que devera ser usado e somente <color #620BB9/#EEDDFF>FALLTHROUGH</color>, visto que este e util para humanos. Outro tipo de comentarios no estilo **lint** como <color #620BB9/#EEDDFF>ARGSUSED</color>, <color #620BB9/#EEDDFF>LINTED</color>, e <color #620BB9/#EEDDFF>NOTREACHED</color> deverao ser apagados.
+Sempre que possível, código deverá rodar através de um verificador de código (ex., “<color #620BB9/#EEDDFF>gcc -Wall -W -Wpointer-arith -Wbad-function-cast ...</color>” or splint from the ports tree) e produzir o minimo de erros possivel. Visto que **!?lint?!** foi removido, o único comentário no modelo **lint** que deverá ser usado e somente <color #620BB9/#EEDDFF>FALLTHROUGH</color>, visto que este é útil para humanos. Outro tipo de comentarios no modelo **lint** como <color #620BB9/#EEDDFF>ARGSUSED</color>, <color #620BB9/#EEDDFF>LINTED</color>, e <color #620BB9/#EEDDFF>NOTREACHED</color> deverao ser apagados.
-Verifique que certa documentacao segue os seus proprios parametros de estilo, como documentado em <color #620BB9/#EEDDFF>mdoc</color>.
+Verifique que certa documentação segue os seus proprios parametros de estilo, como documentado em <color #620BB9/#EEDDFF>mdoc</color>.
-===== Historia =====
+===== História =====
-Este artigo  e em grande parte baseado no ficheiro <color #0B71B9/#DDF1FF>src/admin/style/style</color> da publicacao <color #B90B0B/#FFDDDD>4.4BSD-Lite2</color>, com as Actualizacoes necessarias para refletir a pratica actual de desenvolvimento assim como  desejado para o projecto <color #0BB928/#DDFFE3>HyperbolaBSD</color>.
+Este artigo  é em grande parte baseado no arquivo <color #0B71B9/#DDF1FF>src/admin/style/style</color> da publicaão <color #B90B0B/#FFDDDD>4.4BSD-Lite2</color>, com as atualizações necessárias para refletir a prática atual de desenvolvimento assim como  desejado para o projecto <color #0BB928/#DDFFE3>HyperbolaBSD</color>.
-===== Licensiamento =====
+===== Licenciamento =====
-Este artigo wiki esta publica sobre a [[https://www.freebsd.org/copyright/freebsd-license.html|Licenca FreeBSD]].
+Este artigo da wiki estar publicado sobre a [[https://www.freebsd.org/copyright/freebsd-license.html|Licença FreeBSD]].
 ===== Créditos =====
-Este artigo wiki está baseado em **[[https://man.openbsd.org/|OpenBSD Manual Page]]**.
+Este artigo wiki estar baseado no **[[https://man.openbsd.org/|OpenBSD Manual Page]]**.

Hyperbola GNU/Linux-Libre

HyperWiki

Differences