Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
pt:manual:contrib:coding_style_guidelines [2020/04/26 19:25]
i3_relativism
pt:manual:contrib:coding_style_guidelines [2024/10/25 15:34] (current)
luck02 [Descrição]
Line 1: Line 1:
-... (WIP)+...(WIP) 
 +====== Diretrizes do Modelo de Desenvolvimento do Código HyperbolaBSD ======
  
-====== Guia Desenvolvimento de Codigo HyperbolaBSD ====== +===== Descrição ===== 
- +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 sistemaEste guia deverá ser seguido para todo o novo códigoEm geralcódigo pode ser considerado novo código” quando constitui a volta de 50% ou mais arquivos com alteraçõesIsto é o suficiente para romper precedentes no código existente, e poder utilizar o modelo referido neste guia.
- +
-... (WIP) +
- +
-===== Description ===== +
- +
-This article specifies the preferred style for kernel source files in the <color #0BB928/#DDFFE3>HyperbolaBSD</color> source tree It is also a guide for preferred userland code style. +
-These guidelines should be followed for all new code In generalcode can be considered new code” when it makes up about 50% or more of the file(s) involved This is enough to break precedents in the existing code and use the current style guidelines.+
  
 <code c> <code c>
 /* /*
- Style guide for the HyperbolaBSD KNF (Kernel Normal Form).+ Guia do modelo do HyperbolaBSD KNF (Kernel Normal Form).
  */  */
  
 /* /*
- VERY important single-line comments look like this.+ Comentários MUITO importantes de linha única representam-se assim.
  */  */
  
-/* Most single-line comments look like this. */+/* A maior parte dos comentários de linha única representam-se assim. */
  
 /* /*
- Multi-line comments look like this Make them real sentences+ Comentarios de varias linhas representam-se assimDe forma a criar frases
- Fill them so they look like real paragraphs.+ Preencha-os de forma a criar paragrafos.
  */  */
 </code> </code>
  
-Kernel include files (i.e., <color #620BB9/#EEDDFF><sys/*.h></color>come first; normallyyou'll need <color #620BB9/#EEDDFF><sys/types.h></color> OR <color #620BB9/#EEDDFF><sys/param.h></color>, but not both!  <color #620BB9/#EEDDFF><sys/types.h></color> includes <color #620BB9/#EEDDFF><sys/cdefs.h></color>, and it's okay to depend on that.+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> <code c>
-#include <sys/types.h>  /* Non-local includes in brackets. */+#include <sys/types.h>  /* arquivos include não-locais em **!?brackets?!**. */
 </code> </code>
  
-If it's a network programput the network include files next.+Se for um programa de redeponha o arquivo include relacionados com rede em sequencia.
  
 <code c> <code c>
Line 43: Line 37:
 </code> </code>
  
-Then there's a blank linefollowed by the <color #0B71B9/#DDF1FF>/usr/include</color> files The <color #0B71B9/#DDF1FF>/usr/include</color> filesfor the most partshould be sorted.+Deixe uma linha em brancoseguida por arquivos<color #0B71B9/#DDF1FF>/usr/include</color>  Os arquivos <color #0B71B9/#DDF1FF>/usr/include</color>na generalidadedeveram estar organizados.
  
-Global pathnames are defined in <color #0B71B9/#DDF1FF>/usr/include/paths.h</color> Pathnames local to the program go in pathnames.h in the local directory.+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> <code c>
Line 51: Line 45:
 </code> </code>
  
-Then there's a blank lineand the user include files.+Deixe uma linha em brancoseguida para os arquivos iclude relativos ao usuário.
  
 <code c> <code c>
-#include "pathnames.h"  /* Local includes in double quotes. */+#include "pathnames.h"  /* arquivos locais includes em cotações duplas. */
 </code> </code>
  
-All functions are prototyped somewhere.+Todas as funções necessitam de ser initializadas com um prototipo da mesma.
  
-Function prototypes for private functions (i.e., functions not used elsewherego at the top of the first source module In userlandfunctions local to one source module should be declared ‘<color #620BB9/#EEDDFF>static</color> This should not be done in kernel land since it makes it impossible to use the kernel debugger.+Prototipos de funções privadas (ex., funções que não são utilizadas externamenteapresentam-se no topo do primeiro módulo de fonteNo sistema do usuáriofunçõ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.
  
-Functions used from other parts of the kernel are prototyped in the relevant include file.+Funções usadas por outras partes do kernel deverãoo ser inicializadas com um protótipo no arquivo include relevante, a mesma.
  
-Functions that are used locally in more than one module go into a separate header filee.g., <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>).
  
-Prototypes should not have variable names associated with the typesi.e.,+Prototipos não deveram incluir nomes de variáveis com os tiposex.,
  
 <code c> <code c>
Line 77: Line 71:
 </code> </code>
  
-Prototypes may have an extra space after a tab to enable function names to line up:+Prototipos poderam ter um espaço extra depois do tab para ativar o alinhamento dos nomes das funções:
  
 <code c> <code c>
Line 84: Line 78:
 </code> </code>
  
-There should be no space between the function name and the argument list.+Não deverá haver espaço entre o nome da função e a lista dos argumentos.
  
-Use <color #620BB9/#EEDDFF>%%__dead%%</color> from <color #620BB9/#EEDDFF><sys/cdefs.h></color> for functions that don't returni.e.,+Utilize <color #620BB9/#EEDDFF>%%__dead%%</color> de <color #620BB9/#EEDDFF><sys/cdefs.h></color> para funcoes que nao corremex.,
  
 <code c> <code c>
Line 92: Line 86:
 </code> </code>
  
-In header filesput function prototypes within <color #620BB9/#EEDDFF>%%__BEGIN_DECLS%%</color> / <color #620BB9/#EEDDFF>%%__END_DECLS%%</color> matching pairs.  This makes the header file usable from <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 are capitalized and parenthesizedand should avoid side-effects If they are an inline expansion of function, the function is defined all in lowercase; the macro has the same name all in uppercase.  If the macro needs more than a single lineuse braces.  Right-justify the backslashes, as the resulting definition is easier to read If the macro encapsulates a compound statement, enclose it in a “<color #620BB9/#EEDDFF>do</color>” loopso that it can safely be used in “<color #620BB9/#EEDDFF>if</color>” statements.  Any final statement-terminating semicolon should be supplied by the macro invocation rather than the macro, to make parsing easier for pretty-printers and editors.+Macros são capitalizados e apresentados entre parentesese deveram evitar efeitos-secundáriosSe estes são acrescentados em série de uma função, função é num todo defenida em lowercase; macro tem o mesmo nome num todo mas em uppercase. Se a macro necessita mais de uma linhautilize **!?!braces!?!**. Right-justify the backslashes, visto que a defenicao resultante e mais fácil de lerSe 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 mesmapara fazer com que este possa ser parsable, para ?!concatenação!? e editores de texto.
  
 <code c> <code c>
Line 103: Line 97:
 </code> </code>
  
-Enumeration values are all uppercase.+Valores de enumeração são todos em **!?!uppercase!?!**.
  
 <code c> <code c>
Line 109: Line 103:
 </code> </code>
  
-When defining unsigned integers use “<color #620BB9/#EEDDFF>unsigned int</color>” rather than just “<color #620BB9/#EEDDFF>unsigned</color>”; the latter has been a source of confusion in the past.+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.
  
-When declaring variables in structures, declare them sorted by usethen by size (largest to smallest), then by alphabetical order The first category normally doesn't applybut there are exceptions Each one gets its own line Put a tab after the first wordi.e., use ‘<color #620BB9/#EEDDFF>int^Ix;</color>’ and ‘<color #620BB9/#EEDDFF>struct^Ifoo *x;</color>’.+Na declaração de variáveis nas estruturas, declare-as organizadas por usoem seguida tamanho (maior para mais pequeno), e finalmente por ordem alfabéticaNormalmente a primeira categorianão se aplica, mas existem exepçõesCada uma apresentase numa linha separadaIntroduza uma tab após a primeira palavra(ex., utilize ‘<color #620BB9/#EEDDFF>int^Ix;</color>’ ‘<color #620BB9/#EEDDFF>struct^Ifoo *x;</color>).
  
-Major structures should be declared at the top of the file in which they are usedor in separate header files if they are used in multiple source files Use of the structures should be by separate declarations and should be “<color #620BB9/#EEDDFF>extern</color>” if they are declared in a header file.+Estruturas mais relevantes deveram ser declaradas no topo do arquivo que estas estejam a ser usadasou nos arquivos header separados, se estas forem utilizadas em vários arquivos fonteA 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> <code c>
Line 124: Line 118:
 </code> </code>
  
-Use <color #620BB9/#EEDDFF>queue</color> macros rather than rolling your own listswhenever possible Thusthe previous example would be better written:+Utilize macros <color #620BB9/#EEDDFF>ordenadas</color> em vez de se basear na sua própria listaquando possívelPortantoo exemplo anterior poderia ser melhorado:
  
 <code c> <code c>
Line 136: Line 130:
 </code> </code>
  
-Avoid using typedefs for structure types This makes it impossible for applications to use pointers to such a structure opaquelywhich is both possible and beneficial when using an ordinary struct tag When convention requires a typedef, make its name match the struct tag.  Avoid typedefs ending in “<color #620BB9/#EEDDFF>_t</color>”, except as specified in <color #0BB928/#DDFFE3>Standard C</color> or by <color #0BB928/#DDFFE3>POSIX</color>.+Evite utilizar typedefs para estruturasPois isto impossiblita o uso de pointers de uma foma opaca por parte das aplicaçõesque e tanto possível como benefico utilizar **!?ordinary tags?!** de uma estruturaQuando 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> <code c>
 /* /*
- All major routines should have a comment briefly describing what + Todas as **!?routines?!** principais deveram ter um breve comentario descrevendo o que estas 
- they do The comment before the "main" routine should describe + fazemO comentarioda **!?routine?!** "main" devera descrever 
- what the program does.+ o que o programa faz.
  */  */
 int int
Line 151: Line 145:
 </code> </code>
  
-For consistency, <color #620BB9/#EEDDFF>getopt</color> should be used to parse options Options should be sorted in the getopt call and the switch statementunless parts of the switch cascade.  Elements in a switch statement that cascade should have a <color #620BB9/#EEDDFF>FALLTHROUGH</color> comment Numerical arguments should be checked for accuracy.+Para haver consistencia, <color #620BB9/#EEDDFF>getopt</color> deveria ser usado para parsear as opçõesEstas 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> <code c>
Line 177: Line 171:
 </code> </code>
  
-Use a space after keywords (<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>).  No braces are used for control statements with zero or only a single statement unless that statement is more than single linein which case they are permitted.+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?!**, exceção dessa **!?statement?!** for mais de uma linhaque nesse caso são permitidas.
  
 <code c> <code c>
Line 195: Line 189:
 </code> </code>
  
-Parts of a <color #620BB9/#EEDDFF>for</color> loop may be left empty.+Algumas partes de um <color #620BB9/#EEDDFF>for</color> loop poderão ser deixadas em branco.
  
 <code c> <code c>
Line 204: Line 198:
 </code> </code>
  
-Indentation is an 8 character tab.  Second level indents are four spaces All code should fit in 80 columns.+Identação é um **!?tab?!** de 8 caractresIdentaçãoo de segundo nível são quatro espaçosTodo o código deve caber em 80 colunas.
  
 <code c> <code c>
Line 213: Line 207:
 </code> </code>
  
-Do not add whitespace at the end of a lineand only use tabs followed by spaces to form the indentation Do not use more spaces than a tab will produce and do not use spaces in front of tabs.+Não adicione espaços em branco no final da linhae somente utilize **!?tabs?!** seguidos de espaços para criar a identaçãoNão utilize mais espaços que um **!?tab?!** ira produzir, e não utilize estes antes de espaços.
  
-Closing and opening braces go on the same line as the else Braces that aren't necessary may be left outunless they cause compiler warning.+Abertura e fechamento de parentises apresentam-se na mesma linha que os anterioresParentises desnecessarios poderam ser omitidos, a não ser que estes causem um erro de compilamento.
  
 <code c> <code c>
Line 227: Line 221:
 </code> </code>
  
-Do not use spaces after function names Commas have a space after them Do not use spaces after ‘<color #620BB9/#EEDDFF>(</color>’ or ‘<color #620BB9/#EEDDFF>[</color>’ or preceding ‘<color #620BB9/#EEDDFF>]</color>’ or ‘<color #620BB9/#EEDDFF>)</color>’ characters.+Não utilize espaços depois dos nomes das funçõesVirgulas apresentam um espaço após as mesmasNã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> <code c>
Line 234: Line 228:
 </code> </code>
  
-Unary operators don't require spacesbinary operators do Don't use parentheses unless they're required for precedencethe statement is confusing without themor the compiler generates warning without them Remember that other people may be confused more easily than you.+Operadores unitarios não requerem espaçosao contrário dos operadores bináriosNão utilize parentises a não ser que estes sejam requeridos para precedenciae que o **!?statement?!** se torne confuso sem a existencia destes, a não ser que estes causem um erro de compilamentoLembre-se que esta prática podera confudir outros.
  
 <code c> <code c>
Line 241: Line 235:
 </code> </code>
  
-Exits should be <color #620BB9/#EEDDFF>0</color> on successor non-zero for errors.+Exits deverão utilizar <color #620BB9/#EEDDFF>0</color> para representar sucessoou diferente de zero para erros.
  
 <code c> <code c>
 /* /*
- Avoid obvious comments such as + Tente evitar comentários obvios, como: 
- * "Exit 0 on success."+ * "Exit 0 com successo."
  */  */
 exit(0); exit(0);
 </code> </code>
  
-The function type should be on line by itself preceding the function.+Este tipo de função deverá se apresentar numa linha separada, precedendo própria função.
  
 <code c> <code c>
Line 259: Line 253:
 </code> </code>
  
-When declaring variables in functions, declare them sorted by size (largest to smallest), then in alphabetical ordermultiple ones per line are okay Old style function declarations should be avoided ANSI style function declarations should go in an include file such as “<color #0B71B9/#DDF1FF>extern.h</color>”.  If a line overflowsreuse the type keyword.+Ao declarar variáveis das funções, declare-as organizadas por uso, por seguida tamanho (maior para mais pequeno), e finalmente por ordem alfabéticamultipas por linha são aceitesDeclaracoes de funções de acordo com o estilo antigo deverao ser evitadasDeclaracoes 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 linhasreutilize o tipo da palavra-chave.
  
-Be careful not to obfuscate the code by initializing variables in the declarations Use this feature only thoughtfully DO NOT use function calls in initializers!+Tenha cuidado para não ofuscar o código, através da utilização de variaveis em declaraçõesUtilize esta técnica apenas da maneira correctaNãO UTILIZE chamadas de funções em **!?initializers"!?**.
  
 <code c> <code c>
Line 272: Line 266:
 </code> </code>
  
-Do not declare functions inside other functions.+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. Casts and <color #620BB9/#EEDDFF>sizeof()</color> calls are not followed by a space.  Note that indent does not understand this rule.
  
-Use of the “<color #620BB9/#EEDDFF>register</color>” specifier is discouraged in new code Optimizing compilers such as <color #0BB928/#DDFFE3>gcc</color> can generally do better job of choosing which variables to place in registers to improve code performance.  The exception to this is in functions containing assembly code where the “<color #620BB9/#EEDDFF>register</color>” specifier is required for proper code generation in the absence of compiler optimization.+A utilização do **specificador?!** "<color #620BB9/#EEDDFF>register</color>" em novo código, não é a melhor práticaA otimização dos compiladores como o <color #0BB928/#DDFFE3>gcc</color>, é normalmente melhor via para a excolha de variaveis a colocar nos "registers" para melhor a performance do códigoA 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.
  
-When using <color #620BB9/#EEDDFF>longjmp()</color> or <color #620BB9/#EEDDFF>vfork()</color> in a programthe <color #620BB9/#EEDDFF>-W</color> or <color #620BB9/#EEDDFF>-Wall</color> flag should be used to verify that the compiler does not generate warnings such as+Na utilização de <color #620BB9/#EEDDFF>longjmp()</color> ou <color #620BB9/#EEDDFF>vfork()</color> num programaa **!?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> <code c>
Line 284: Line 278:
 </code> </code>
  
-If any warnings of this type occuryou must apply the “<color #620BB9/#EEDDFF>volatile</color>” type-qualifier to the variable in question Failure to do so may result in improper code generation when optimization is enabled Note that for pointers, the location of “<color #620BB9/#EEDDFF>volatile</color>” specifies if the type-qualifier applies to the pointer, or the thing being pointed to A volatile pointer is declared with “<color #620BB9/#EEDDFF>volatile</color>” to the right of the “<color #620BB9/#EEDDFF>*</color> Example:+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 ativaVerifique 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 apontadoUm apontador volatil e declarado com “<color #620BB9/#EEDDFF>volatile</color>” a direita do "<color #620BB9/#EEDDFF>*</color>"Exemplo:
  
 <code c> <code c>
Line 290: Line 284:
 </code> </code>
  
-says that “<color #620BB9/#EEDDFF>foo</color>” is volatile, but “<color #620BB9/#EEDDFF>*foo</color>” is not.  To make “<color #620BB9/#EEDDFF>*foo</color>” volatile use the syntax+Assumindo que “<color #620BB9/#EEDDFF>foo</color>” volatile, mas “<color #620BB9/#EEDDFF>*foo</color>” nao.  Para “<color #620BB9/#EEDDFF>*foo</color>” o ser utilize a seguinte sintax:
  
 <code c> <code c>
Line 296: Line 290:
 </code> </code>
  
-If both the pointer and the thing pointed to are volatile use+Se ambos o apontador e o que este esta apontando form volateis, utilize:
  
 <code c> <code c>
Line 302: Line 296:
 </code> </code>
  
-“<color #620BB9/#EEDDFF>const</color>” is also a type-qualifier and the same rules apply The description of a read-only hardware register might look something like:+“<color #620BB9/#EEDDFF>const</color>” e também um qualificado de tipo e as mesmas regras se aplicamA descrição de "register" **!?read-only?!** do hardware, podera se apresentar como :
  
 <code c> <code c>
Line 308: Line 302:
 </code> </code>
  
-Global flags set inside signal handlers should be of type “<color #620BB9/#EEDDFF>volatile sig_atomic_t</color>” if possible This guarantees that the variable may be accessed as an atomic entity, even when signal has been delivered Global variables of other types (such as structuresare not guaranteed to have consistent values when accessed via a signal handler.+Bandeiras globais defenidas dentro de **!?handlers?!** de sinais deverao ser do tipo “<color #620BB9/#EEDDFF>volatile sig_atomic_t</color>” se possivelIsto garante que variavel podera ser acedida como identidade atomica, mesmo quando o sinal tenha sido recebidoNao e garantido que variaveis globais de outros tipos (como estruturasquando acedidas por **!?handlers?!** de sinais.
  
-NULL is the preferred null pointer constant Use <color #620BB9/#EEDDFF>NULL</color> instead of <color #620BB9/#EEDDFF>(type *)0</color> or <color #620BB9/#EEDDFF>(type *)NULL</color> in all cases except for arguments to variadic functions where the compiler does not know the type.+NULL e a contaste preferida para apontadores nulosUtilize <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.
  
-Don't use ‘<color #620BB9/#EEDDFF>!</color>’ for tests unless it'a boolean, i.e., use+Não utilize ‘<color #620BB9/#EEDDFF>!</color>’ para testes não ser que seja uma expressão boolean, ex., utilize
  
 <code c> <code c>
Line 318: Line 312:
 </code> </code>
  
-not+não
  
 <code c> <code c>
Line 324: Line 318:
 </code> </code>
  
-Routines returning <color #620BB9/#EEDDFF>void *</color> should not have their return values cast 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.
  
-Use the <color #620BB9/#EEDDFF>err</color> and <color #620BB9/#EEDDFF>warn</color> family of functions Don't roll your own!+Utilize as familias de funções <color #620BB9/#EEDDFF>err</color> <color #620BB9/#EEDDFF>warn</color>Nao utilize as suas proprias **!?!?!"roll/rolling"**
  
 <code c> <code c>
Line 336: Line 330:
 </code> </code>
  
-Old-style function declarations look like this:+Funções desse modelo do antigo apresentam-se desta maneira:
  
 <code c> <code c>
Line 349: Line 343:
 </code> </code>
  
-Use <color #0BB928/#DDFFE3>ANSI</color> function declarations unless you explicitly need K&compatibility Long parameter lists are wrapped with a normal four space indent.+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 identação normal de quatro espaços.
  
-Variable numbers of arguments should look like this:+Numeros variaveis de argumentos devem-se apresentar desta maneira:
  
 <code c> <code c>
Line 374: Line 368:
 </code> </code>
  
-Usage statements should take the same form as the synopsis in manual pages Options without operands come firstin alphabetical order inside a single set of braces, followed by options with operandsin alphabetical ordereach in bracesfollowed by required arguments in the order they are specifiedfollowed by optional arguments in the order they are specified.+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 lugarpor ordem alfabétca dentro de um único conjunto de parentisesseguido das opções com **operandos ou operadores verificar**por ordem alfabetca dentro de parentises em paresseguido de argumentos requeridos na ordem em que estes estão especificadosseguidos de argumentos opcionais também na ordem em que estes estão especificados.
  
-A bar (‘<color #620BB9/#EEDDFF>|</color>’) separates either-or options/argumentsand multiple options/arguments which are specified together are placed in a single set of braces.+Utilize uma barra (‘<color #620BB9/#EEDDFF>|</color>’) para separar quer argumentos e opçõesou quer argumentos e opções multiplas que sejam especificadas juntas e que sejam postas num único conjunto de parentises.
  
-If numbers are used as optionsthey should be placed firstas shown in the example below Uppercase letters take precedence over lowercase.+Se numeros sao utilizados como opcoesestes deveram se apresentar primeirocomo mostra o exemplo a baixoletras em **Uppercase** tem precedencia de letras em **lowercase**.
  
 <code c> <code c>
Line 385: Line 379:
 </code> </code>
  
-The <color #620BB9/#EEDDFF>getprogname</color> function may be used instead of hard-coding the program name.+A funcao <color #620BB9/#EEDDFF>getprogname</color> podera ser usada em vez de codificar **!?hardcode?!** o nome do programa.
  
 <code c> <code c>
Line 391: Line 385:
 </code> </code>
  
-New core kernel code should be reasonably compliant with the style guides The guidelines for third-party maintained modules and device drivers are more relaxed but at minimum should be internally consistent with their style.+Novo código base de kernel deverá ser rasoavelmente respeitado destes parametros de modeloOs parametros para modulos mantidos por terceiros, e drivers de **!?devices?!** poderam não ter de seguir estes risca, mas no minimo deverão ter alguma coerencia nesse mesmo modelo.
  
-Whenever possiblecode should be run through a code checker (e.g., “<color #620BB9/#EEDDFF>gcc -Wall -W -Wpointer-arith -Wbad-function-cast ...</color>” or splint from the ports tree) and produce minimal warnings Since lint has been removedthe only lint-style comment that should be used is <color #620BB9/#EEDDFF>FALLTHROUGH</color>, as it's useful to humans Other lint-style comments such as <color #620BB9/#EEDDFF>ARGSUSED</color>, <color #620BB9/#EEDDFF>LINTED</color>, and <color #620BB9/#EEDDFF>NOTREACHED</color> may be deleted.+Sempre que possívelcó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 possivelVisto que **!?lint?!** foi removidoo único comentário no modelo **lint** que deverá ser usado e somente <color #620BB9/#EEDDFF>FALLTHROUGH</color>, visto que este é útil para humanosOutro tipo de comentarios no modelo **lint** como <color #620BB9/#EEDDFF>ARGSUSED</color>, <color #620BB9/#EEDDFF>LINTED</color>, <color #620BB9/#EEDDFF>NOTREACHED</color> deverao ser apagados.
  
-Note that documentation follows its own style guideas documented in <color #620BB9/#EEDDFF>mdoc</color>.+Verifique que certa documentação segue os seus proprios parametros de estilocomo documentado em <color #620BB9/#EEDDFF>mdoc</color>.
  
-===== History =====+===== História =====
  
-This article is largely based on the <color #0B71B9/#DDF1FF>src/admin/style/style</color> file from the <color #B90B0B/#FFDDDD>4.4BSD-Lite2</color> releasewith updates to reflect the current practice and desire of the <color #0BB928/#DDFFE3>HyperbolaBSD</color> development.+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>.
  
-===== Licensing =====+===== Licenciamento =====
  
-This wiki article is released under the [[https://www.freebsd.org/copyright/freebsd-license.html|FreeBSD License]].+Este artigo da wiki estar publicado sobre a [[https://www.freebsd.org/copyright/freebsd-license.html|Licença FreeBSD]].
  
-===== Acknowledgement =====+===== Créditos =====
  
-This wiki article is based on **[[https://man.openbsd.org/|OpenBSD Manual Page]]**.+Este artigo wiki estar baseado no **[[https://man.openbsd.org/|OpenBSD Manual Page]]**.