HyperWiki

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
pt:manual:contrib:coding_style_guidelines [2025/03/04 23:41]
luck02 [Descrição] 		pt:manual:contrib:coding_style_guidelines [2025/03/04 23:59] (current)
luck02 [Descrição]
Line 3: Line 3:
  
 ===== Descrição ===== ===== Descrição =====
-Este artigo específica 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.+Este artigo específica 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 código 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> <code c>
Line 11: Line 11:
  
 /* /*
- * Comentários MUITO importantes de linha única representam-se assim.+ * Comentários MUITO importantes de linha única representa-se assim.
  */  */
  
-/* A maior parte dos comentários de linha única representam-se assim. */+/* A maior parte dos comentários de linha única representa-se assim. */
  
 /* /*
- * Comentarios de varias linhas representam-se assim. De forma a criar frases.+ * Comentarios de várias linhas representa-se assim. De forma a criar frases.
  * Preencha-os de forma a criar paragrafos.  * Preencha-os de forma a criar paragrafos.
  */  */
 </code> </code>
  
-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.+Os arquivos include do kernel (ex., <color #620BB9/#EEDDFF><sys/*.h></color>) , normalmente, apresenta-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> <code c>
Line 28: Line 28:
 </code> </code>
  
-Se for um programa de rede, ponha o arquivo include relacionados com rede em sequencia.+Se for um programa de rede, ponha o arquivo include relacionados com rede em sequência.
  
 <code c> <code c>
Line 39: Line 39:
 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. 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 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.+Pathnames globais estão definidos em <color #0B71B9/#DDF1FF>/usr/include/paths.h</color>. Pathnames locais para um programa, em específico, estão definidos em pathnames.h no diretório local.
  
 <code c> <code c>
Line 45: Line 45:
 </code> </code>
  
-Deixe uma linha em branco, seguida para os arquivos iclude relativos ao usuário.+Deixe uma linha em branco, seguida para os arquivos include relativos ao usuário.
  
 <code c> <code c>
Line 51: Line 51:
 </code> </code>
  
-Todas as funções necessitam de ser initializadas com um prototipo da mesma.+Todas as funções necessitam serem inicializadas com um protótipo da mesma.
  
-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.+Protótipos 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 específico 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.
  
-Funções usadas por outras partes do kernel deverãoo ser inicializadas com um protótipo no arquivo include relevante, a mesma.+Funções usadas por outras partes do kernel deverão ser inicializadas com um protótipo no arquivo include relevante, a mesma.
  
-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>).+Funções que são utilizadas localmente em mais de um módulo fonte, apresentam-se num arquivo header em separado, (ex., <color #0B71B9/#DDF1FF>extern.h</color>).
  
-Prototipos não deveram incluir nomes de variáveis com os tipos; ex.,+Protótipos não deveram incluir nomes de variáveis com os tipos; ex.,
  
 <code c> <code c>
Line 71: Line 71:
 </code> </code>
  
-Prototipos poderam ter um espaço extra depois do tab para ativar o alinhamento dos nomes das funções:+Protótipos poderam ter um espaço extra depois do tab para ativar o alinhamento dos nomes das funções:
  
 <code c> <code c>
Line 80: Line 80:
 Não deverá haver espaço entre o nome da função e a lista dos 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.,+Utilize <color #620BB9/#EEDDFF>%%__dead%%</color> de <color #620BB9/#EEDDFF><sys/cdefs.h></color> para funcões que não rodam, ex.,
  
 <code c> <code c>
Line 86: Line 86:
 </code> </code>
  
-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>.+Nos arquivos header, introduza os prottipos das funções conpreendidos por <color #620BB9/#EEDDFF>%%__BEGIN_DECLS%%</color> / <color #620BB9/#EEDDFF>%%__END_DECLS%%</color> como pares.  Isto torna os arquivos header utilizáveis para <color #0B71B9/#DDF1FF>C++</color>.
  
-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.+Macros são capitalizados e apresentados entre parenteses, e deverão 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 defenicão resultante é 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 deverá ser ?!obtida?! pela invocação da macro e n[ao pela mesma, para fazer com que este possa ser parsable, para ?!concatenação!? e editores de texto.
  
 <code c> <code c>
Line 103: Line 103:
 </code> </code>
  
-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 definição 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 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>’).+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 exceçõ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 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.+Estruturas mais relevantes deverão ser declaradas no topo do arquivo que serão usadas, ou nos arquivos header separados, se estas forem utilizadas em vários arquivos fonte. A utilização de estrutura deverão ser separada por declarações e estas deverão ser <color #620BB9/#EEDDFF>externas</color> se forem declaradas nos arquivos header.
  
 <code c> <code c>