1 Introduction

This document serves as the complete definition of Google’s code forsource standards in the Java™ Programming Language. Um arquivo Java source é descrito como sendo um estilo de inGoogle se e somente se ele adere às regras aqui.como outros guias de estilo de programação, as questões abordadas abrangem não só questões estéticas de formatação, mas também outros tipos de convenções ou padrões de codificação. No entanto, este documento centra-se principalmente nas regras duras e rápidas que seguimos universalmente, eavoids dando conselhos que não são claramente executáveis (seja por humano ou ferramenta).

1.1 notas terminológicas

neste documento, salvo especificação em contrário:

1. A classe de termo é usada inclusivamente para significar uma classe “Ordinária”, classe de enum, interface ou tipo de anotação (@interface).
2. o termo membro (de uma classe) é usado inclusivamente para significar uma classe, campo, método ou construtor aninhado; isto é, todo o conteúdo de topo de uma classe exceto inicializadores e comentários. o termo comentário refere-se sempre a Comentários de implementação. Nós não usamos a frase “comentários de documentação”, em vez de usar o termo comum “Javadoc.”

Outras” notas terminológicas ” aparecerão ocasionalmente em todo o documento.

1.2 notas de orientação

exemplo o código neste documento não é normativo. Isto é, enquanto os exemplos estão no estilo Google, eles podem não ilustrar a única maneira elegante de representar o código. Opções opcionais de formatação feitas em exemplos não devem ser aplicadas como regras.

2 o básico dos ficheiros de código

2.1 o nome do ficheiro de código

o nome do ficheiro de código consiste no nome sensível ao caso da classe de Topo que contém(da qual existe exactamente um), mais a extensão.java.

2.2 codificação de Ficheiros: UTF-8

os ficheiros de código são codificados em UTF-8.

2.3 caracteres especiais

2.3.1 caracteres em branco

para além da sequência de terminação de linhas, o espaçacaracter horizontal ASCII (0x20) é o único carácter em branco que aparece em qualquer lugar de um ficheiro de código. Isto implica que:

1. All other whitespace characters in string and character literals are escaped.
2. Tab characters are not used for indentation.

2.3.2 Special escape sequences

For any character that has a special escape sequence(\b\t\n\f\r\"\' and\\), that sequenceis used rather than the corresponding octal(e.g. \012) or Unicode(e.g. \u000a) escape.

2.3.3 caracteres Não-ASCII

Para os restantes caracteres não-ASCII, o real de caracteres Unicode(por exemplo, ∞), ou o equivalente de escape Unicode(por exemplo, \u221e) é usado. A escolha depende apenas do que torna o código mais fácil de ler e entender, embora o Unicode escape para fora dos literais strings e comentários são fortemente desencorajados.

dica: no caso de escape Unicode, e ocasionalmente mesmo quando os caracteres actualUnicode são usados, um comentário explicativo pode ser muito útil.exemplos:

Tip: nunca torne o seu código menos legível simplesmente por medo de que alguns programas possam não lidar com caracteres não ASCII corretamente. Se isso acontecer, esses programas estão quebrados e devem ser consertados.

3 estrutura do ficheiro de código

exatamente uma linha em branco separa cada secção que está presente.

3.1 licença ou informação de copyright, se presente

Se licença ou informação de copyright pertence a um arquivo, ele pertence aqui.

3.2 Declaração Do pacote

a declaração do pacote não está embalada em linha. O limite da coluna (Ponto 4.4,limite da coluna: 100) não se aplica às declarações dos pacotes.declarações de importação1 não são utilizadas importações de caracteres especiais

importações de caracteres especiais, estáticas ou não.

3.3.2 nenhuma linha de enrolamento

as declarações de importação não estão envoltas em linha. O limite da coluna (Ponto 4.4,limite da coluna: 100) não se aplica aos certificados de importação.

3.3.3 ordenação e espaçamento

as importações são ordenadas do seguinte modo:

1. todas as importações estáticas num único bloco.todas as importações não estáticas num único bloco.se houver importações estáticas e não estáticas, uma única linha em branco separa os dois eixos. Não existem outras linhas em branco entre as declarações de importação.

   dentro de cada bloco os nomes importados aparecem na ordem de ordenação ASCII. (Nota: isto não é o mesmo que as declarações de importação sendo em ordem de ordenação ASCII, desde ‘.”orders before”;”.)

   3.3.4 nenhuma importação estática para as classes

   a importação estática não é utilizada para as classes aninhadas estáticas. São importados com importações normais.

   3.4 declaração da classe

   3.4.1 exatamente uma declaração da classe de topo

   cada classe de topo reside num ficheiro de origem próprio.

   3, 4.2 ordenação do conteúdo da classe

   a ordem que você escolher para os membros e inicializadores da sua classe pode ter um grande efeito sobre a aprendizagem. No entanto, não há uma única receita correta para como fazê-lo; diferentes classes podem ordenar seus conteúdos de maneiras diferentes.

   O que é importante é que cada classe usa alguma ordem lógica, que o itsmaintainer poderia explicar se perguntado. Por exemplo, novos métodos não são normalmente adicionados ao final da classe, pois isso produziria “cronologia por data adicionada” ordenação, que não é uma ordenação logicalordering.

   3.4.2.1 sobrecargas: nunca dividir

   quando uma classe tem vários construtores, ou métodos múltiplos com o mesmo nome, estes aparecem de forma sequencial, sem outro código entre eles (nem mesmo membros privados).

   4 formatação

   terminologia Nota: construção em bloco refere-se ao corpo de uma classe, método ou construtor. Note que, pela seção 4.8.3.1 onarray inicializers, qualquer array inicializermay opcionalmente pode ser tratado como se fosse uma construção em bloco.

   4.1 Chavetas

   4.1.1 Chaves são usadas onde opcional

   Chaves são usadas comifelsefordo ewhile instruções, mesmo quando thebody está vazia ou contém apenas uma única instrução.

   4.1.2 Nonempty blocos: K & R de estilo

   Chaves siga as Kernighan e Ritchie estilo(“Egípcio parênteses”)para nonempty blocos e blocos construções:

   • Sem quebra de linha antes de a chave de abertura.quebra de linha após o chaveiro de abertura.quebra de linha antes do suporte de Fecho.
   • quebra de linha após o Suporte de Fecho, apenas se esse suporte terminar uma declaração ou terminar o corpo de um método, construtor, ou classe nomeada. Por exemplo, não há quebra de linha após o suporte se for seguido por else ou uma vírgula.

   exemplos:

   return () -> { while (condition()) { method(); }};return new MyClass() { @Override public void method() { if (condition()) { try { something(); } catch (ProblemException e) { recover(); } } else if (otherCondition()) { somethingElse(); } else { lastThing(); } }};

   algumas exceções para classes enum são dadas na Secção 4.8.1,classes Enum.blocos vazios: pode ser concisa

   um bloco vazio ou uma construção semelhante a um bloco pode estar em K & R estilo (como descrito na insecção 4.1.2). Alternativamente, pode ser fechado immediatelyafter ele é aberto, sem caracteres ou quebra de linha entre({}), a menos que seja parte de amulti-bloco de instrução (que diretamente contém vários blocos:if/else outry/catch/finally).

   Exemplos:

    // This is acceptable void doNothing() {} // This is equally acceptable void doNothingElse() { }

    // This is not acceptable: No concise empty blocks in a multi-block statement try { doSomething(); } catch (Exception e) {}

   4.2 Bloco de recuo: +2 espaços

   cada vez que um novo bloco ou construção semelhante a um bloco é aberto, o indent aumenta em dois espaços. Quando o bloco termina, o indent retorna ao nível de indentação anterior. O nível de indentação é aplicável tanto ao código como aos comentários em todo o bloco. (See the example in Section 4.1.2,Nonempty blocks: K & R Style.)

   4.3 uma declaração por linha

   cada declaração é seguida por uma quebra de linha.

   4.4 coluna limite: 100

   Java code has a column limit of 100 characters. Um “carácter” significa qualquer ponto de código Unicode.Exceto como indicado abaixo, qualquer linha que exceda este limite deve ser envolto em linha, como explicado na inseção 4.5, envolto em linha.

   cada ponto de código Unicode conta como um carácter, mesmo que a sua largura de visualização seja maior ou menor. Por exemplo,se usingfullwidth characters, você pode optar por quebrar a linha mais cedo do que onde esta regra estritamente requer.

   exceções:

   1. linhas onde obedecer o limite da coluna não é possível (por exemplo, um URL longo em Javadoc, ou uma referência longa do método JSNI).
   2. package eimport declarações (ver secções 3.2 “Declaração Do pacote” e 3.3 “declarações de importação”).linhas de comando
   3. num comentário que pode ser cortado e colado numa linha de comandos.

   4.5 quebra-linhas

   Nota terminológica: quando o código que de outra forma poderia ocupar uma única linha é dividido em várias linhas, esta actividade é chamada quebra-linhas.

   não existe uma fórmula determinística abrangente que mostre exatamente como se enroscar em todas as situações. Muitas vezes, existem várias formas válidas de alinhar a mesma peça de código.

   Nota: Embora a razão típica para o empacotamento de linhas seja evitar transbordar o limite da coluna, mesmo o código que de facto caberia dentro do limite da coluna, talvez envolto em linha à discrição do autor.

   dica: extrair um método ou variável local pode resolver o problema sem a necessidade de envolver linhas.

   4.5.1 onde quebrar

   a primeira directiva de quebra de linha é: prefere quebrar a um nível sintático mais elevado. Além disso:

   1. Quando uma linha é quebrada em um operador não-atribuição a quebra vem antes do símbolo. (Note que esta não é a mesma prática usada no estilo Google para outras linguagens, como C++ e JavaScript.)
      • Isto também se aplica para o seguinte “o operador-como” símbolos:
        • o ponto de separação (.
        • os dois dois-pontos de um método de referência (::
        • um ” e ” comercial em um tipo dependente (<T extends Foo & Bar>)
        • um tubo em um bloco catch (catch (FooException | BarException e)).
   2. Quando uma linha é quebrada em um operador de atribuição, a quebra geralmente vem após o símbolo, mas de qualquer forma é aceitável.
      • This also applies to the” assignment-operator-like “colon in an enhanced for (“foreach”) statement.
   3. A method or constructor name stains attached to the open parentesis (() that follows it.
   4. uma vírgula (,) permanece ligada ao símbolo que o precede.
   5. uma linha nunca é quebrada adjacente à seta em um lambda, exceto que uma pausa pode vir imediatamente após a seta se o corpo do lambda consiste de uma única expressão não espaçada. Exemplos:

      MyLambda<String, Long, Object> lambda = (String label, Long value, Object obj) -> { ... };Predicate<String> predicate = str -> longExpressionInvolving(str);

   Nota: O objetivo principal para a quebra de linha é ter código claro, não necessariamente código que se encaixa no menor número de linhas.

   4.5.2 indentar linhas de continuação pelo menos +4 espaços

   quando o enrolamento da linha, cada linha após a primeira (cada linha de continuação) é indentrada pelo menos + 4 da linha original.

   Quando existem múltiplas linhas de continuação, a indentação pode variar para além de +4 conforme necessário. Em geral, duas linhas de continuação usam o mesmo nível de indentação se e somente se theybegin com elementos sintaticamente paralelos.

   secção 4.6.3 sobre o alinhamento Horizontal aborda a prática desencorajada de utilizar um número variável de espaços para alinhar certos símbolos com linhas anteriores.

   4.6 Whitespace

   4.6.1 Whitespace Vertical

   uma única linha em branco aparece sempre:

   1. entre Membros consecutivos ou inicializadores de uma classe: campos, Construtores, métodos, classes aninhadas, inicializadores estáticos e inicializadores de instância.
      • excepção: uma linha em branco entre dois campos consecutivos (sem outro código entre eles) é opcional. Tais linhas em branco são usadas como necessário para criar agrupamentos lógicos de campos.excepção: as linhas em branco entre as constantes de enum são abrangidas pelo ponto 4.8.1.
   2. conforme exigido por outras secções deste documento (como a Secção 3, Estrutura do ficheiro de código e a secção 3.3, declarações de importação).

   uma única linha em branco também pode aparecer em qualquer lugar que melhore a legibilidade, por exemplo entre estações para organizar o código em subsecções lógicas. Uma linha em branco antes do primeiro membro ou inicializador, ou depois do último membro ou Inicializador da classe, não é encorajado nordiscouraged.são permitidas várias linhas em branco consecutivas, mas nunca necessárias (ou incentivadas).

   4, 6.2 espaço Horizontal em branco

   para além do exigido pela linguagem ou outras regras de estilo, e além de literais, comentários e javadoc, um único espaço ASCII também aparece apenas nos seguintes lugares.

   1. que Separa qualquer palavra reservada, como iffor ou catch, a partir de um parêntese de abertura (() que segue na linha
   2. que Separa qualquer palavra reservada, como else ou catch, a partir de uma chave de fechamento (}) que o precede na linha
   3. Antes de qualquer chaveta ({), com duas exceções:
      • @SomeAnnotation({a, b}) (sem espaço)
      • String x = {{"foo"}}; (não é necessário espaço entre {{, pelo item 8 abaixo)
   4. Em ambos os lados de qualquer binário ou ternário operador. Isto também se aplica aos seguintes símbolos “tipo operador”:
      • o amperador e num limite de tipo conjuntivo: <T extends Foo & Bar>
      • o tubo para um bloco de captura que lida com múltiplas excepções: catch (FooException | BarException e)
      • The colon (:) in an enhanced for (“foreach”) statement
      • : (String str) -> str.length()

      mas não

      • os dois dois-pontos (::) de um método de referência, o qual é escrito como Object::toString
      • o ponto de separação (.), qual é escrito como object.toString()
   5. Depois ,:; ou o parêntese de fechamento ()) de um elenco
   6. Em ambos os lados da barra dupla (//) que começa um fim-de-linha de comentário. Aqui, vários espaços são permitidos, mas não são necessários.
   7. Entre o tipo de variável e de uma declaração: List<String> list
   8. Opcional apenas dentro de ambas as chaves de um array inicializador
      • new int {5, 6} e new int { 5, 6 } são válidos
   9. Entre um tipo de anotação e ou ....

   esta regra nunca é interpretada como exigindo ou proibindo espaço adicional no início ou no início de uma linha; ela se dirige apenas ao espaço interior.alinhamento Horizontal: nunca exigido Nota terminológica: Alinhamento Horizontal é a prática de adicionar um número variável de espaços adicionais em seu código com o objetivo de fazer com que certos tokens apareçam diretamente abaixo de certos outros tokens em linhas anteriores.

   esta prática é permitida, mas nunca é exigida pelo estilo Google. Nem sequer é necessário manter o alinhamento horizontal nos locais onde já foi utilizado.

   Aqui está um exemplo sem alinhamento, então usando alinhamento:

   private int x; // this is fineprivate Color color; // this tooprivate int x; // permitted, but future editsprivate Color color; // may leave it unaligned

   Tip: O alinhamento pode ajudar na legibilidade, mas cria problemas para a manutenção futura. Considere uma mudança futura que precisa tocar apenas uma linha. Esta mudança pode deixar a formatação anteriormente agradável mutilada, e isso é permitido. Muitas vezes, incita o programador (talvez você) a ajustar o espaço em branco nas linhas próximas, possibilitando uma série de reformatórios em cascata. Essa mudança de linha tem agora um “raio de explosão”.”Isso pode, na pior das hipóteses, resultar em trabalho inútil, mas, na melhor das hipóteses, ainda corrompe a informação histórica da versão, atrasa os revisores e agrava conflitos de fusão.

   4, 7 Agrupamento parêntesis: recomendado

   agrupamento opcional parêntesis são omitidos apenas quando o autor e revisor concordam que não há chance razoável de o Código ser mal interpretado sem eles, nem eles teriam feito o codeeasier para ler. Não é razoável assumir que cada leitor tem a tabela de precedência Javaoperator inteira memorizado.

   4.8 construções específicas

   4.8.1 classes de Enum

   após cada vírgula Que segue uma constante de enum, uma quebra de linha é opcional. Também são permitidas linhas em branco adicionais (normalmente apenas uma). Esta é uma possibilidade:

   private enum Answer { YES { @Override public String toString() { return "yes"; } }, NO, MAYBE}

   uma classe de enum sem métodos e sem documentação sobre as suas constantes pode opcionalmente ser formatada se for um inicializador de array (ver secção 4.8.3.1 inicializadores onarray).

   private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }

   Uma vez que as classes enum são classes, todas as outras regras para as classes de formatação se aplicam.

   4.8.2 declarações de Variáveis

   4.8.2.1 Uma variável por declaração

   Cada declaração de variável (de campo ou local) declara apenas uma variável: as declarações comoint a, b; não são usados.excepção: Múltiplas declarações variáveis são aceitáveis no cabeçalho de afor loop.

   4.8.2.2 declarado quando necessário

   as variáveis locais não são habitualmente declaradas no início da sua construção em bloco ou bloco. Em vez disso, as variáveis locais são declaradas próximas do ponto em que são utilizadas pela primeira vez (dentro da razão), para minimizar o seu âmbito. As declarações variáveis locais normalmente têm inicializadores, ou são inicializadas imediatamente após a declaração.

   4.8.3 matrizes

   4.8.3.1 inicializadores de matriz: pode ser “block-like”

   qualquer inicializador de array pode opcionalmente ser formatado como se fosse um “block-likeconstrutt.”Por exemplo, os seguintes são válidos (não um exhaustivelist):

   new int { new int { 0, 1, 2, 3 0,} 1, 2,new int { 3, 0, 1, } 2, 3} new int {0, 1, 2, 3}

   4.8.3.2 Nº C-estilo declarações de matriz

   Os colchetes fazem parte do tipo, e não a variável:String args, nãoString args.

   4.8.4 Switch statements

   Terminology Note: Inside the braces of aswitch block are one or more statement groups. Cada grupo de declaração é constituído por um ou mais comutadores (ou case FOO: oudefault:), seguidos de uma ou mais declarações (ou, para o último grupo de declaração, zero ou mais declarações).

   4.8.4.1 indentação

   como em qualquer outro bloco, o conteúdo de um bloco de comutação é indentado +2.

   Depois de uma etiqueta de switch, há uma quebra de linha, e o nível de indentação é aumentado +2, exatamente se um bloco estava sendo aberto. A seguinte etiqueta switch retorna ao indentationlevel anterior, como se um bloco tivesse sido fechado.

   4.8.4.2: comentou

   Dentro de um bloco de opção, cada instrução de grupo termina abruptamente (com umbreakcontinuereturn ou lançada uma exceção), ou estiver marcado com um commentto indicar que a execução vai ou pode continuar para a próxima instrução em grupo. Anycomment that communicates the idea of fall-through is sufficient (typically// fall through). Este comentário especial não é exigido no último grupo de declarações do bloco switch. Exemplo:

   switch (input) { case 1: case 2: prepareOneOrTwo(); // fall through case 3: handleOneTwoOrThree(); break; default: handleLargeNumber(input);}

   Observe que qualquer comentário seja necessário depois de case 1:, onlyat o final da declaração de grupo.

   4.8.4.3 default caso está presente

   Cada instrução switch inclui um default statementgroup, mesmo se ele não contém nenhum código.

   Exceção: Uma instrução switch para uma enum tipo de omitthe default declaração de grupo, se includesexplicit casos, abrangendo todos os valores possíveis desse tipo. Isto permite que o IDEs ou outras ferramentas de análise estática para emitir um aviso se algum caso foi perdido.

   4.8.5 anotações

   anotações aplicáveis a uma classe, método ou construtor aparecem imediatamente após o bloco de documentação, e cada anotação é listada numa linha própria (ou seja, uma linha de anotaçãoper). Estas quebras de linha não constituem um enrolamento de linha (Section4.5, enrolamento de linha), pelo que o nível de indentação não é aumentado. Exemplo:

   @Override@Nullablepublic String getNameIfPresent() { ... }

   excepção: Um único sem parâmetros annotationmay em vez de aparecer junto com a primeira linha de assinatura, por exemplo:

   @Override public int hashCode() { ... }

   Anotações aplicar-se a um campo de também aparecer imediatamente após o bloco de documentação, mas inthis caso, várias anotações (possivelmente com parâmetros) podem ser listados na mesma linha;por exemplo:

   @Partial @Mock DataLoader loader;

   não Existem regras específicas para a formatação de anotações sobre os parâmetros, variáveis locais, ou tipos.

   esta secção aborda os comentários de implementação. Javadoc é abordado separadamente inSection 7, Javadoc.

   qualquer quebra de linha pode ser precedida por um espaço em branco arbitrário seguido de um comentário de implementação.Tal comentário torna a linha não-em branco.

   4.8.6.1 estilo de comentário em bloco

   comentários em bloco são indentados no mesmo nível que o código circundante. Eles podem estar em /* ... */ estilo ou// ... estilo. Para multi-linha/* ... */ comentários, linhas subseqüentes devem iniciar com* alinhado com o * na linha anterior.

   /* * This is // And so /* Or you can * okay. // is this. * even do this. */ */

   as observações não constam das casas desenhadas com asteriscos ou outros caracteres.

   dica: ao escrever comentários multi-linhas, use o /* ... */ estilo se quiser formatadores automáticos de código rasgam as linhas quando necessário (estilo parágrafo). A maioria dos formatadores não re-wrap linhas em // ... blocos de comentários de estilo.

   4.8.7 Modificadores

   Classe e membro modificadores, quando presentes, aparecem na orderrecommended pela Especificação da Linguagem Java:

   public protected private abstract default static final transient volatile synchronized native strictfp

   4.8.8 Literais Numéricos

   longinteiro de valor literais usar uma letra maiúscula L sufixo, neverlowercase (para evitar confusão com o algarismo 1). Por exemplo, 3000000000Lem vez de 3000000000l.

   5 nomeando

   5.1 regras comuns a todos os identificadores

   identificadores usam apenas letras e dígitos ASCII, e, em um pequeno número de casos anotados abaixo,underscores. Assim, cada nome identificador válido é correspondido pela expressão regular\w+ .

   In Google Style, special prefixes or suffixes are not used. For example, thesenames are not Google Style: name_mNames_name and kName.

   5.2 Rules by identifier type

   5.2.1 Package names

   Package names are all lowercase, with consecutive words simply concatenated together (nounderscores). For example, com.example.deepspace, notcom.example.deepSpace orcom.example.deep_space.

   5.2.2 Class names

   Class names are written in UpperCamelCase.

   os nomes das classes são tipicamente substantivos ou frases substantivas. Por exemplo,Character ouImmutableList. Os nomes de Interface também podem ser substantivos ou frases adjetivas (por exemplo, List), mas podem algumas vezes ser adjetivos ou frases adjetivas em vez disso (por exemplo,Readable).

   não existem regras específicas ou mesmo convenções bem estabelecidas para nomear tipos de anotação.

   classes de teste são nomeadas começando com o nome da classe que estão testando, e endingwith Test. Por exemplo,HashTest ouHashIntegrationTest.

   5.2.3 os nomes dos métodos

   os nomes dos métodos são escritos em minúsculas.

   os nomes dos métodos são tipicamente verbos ou frases verbais. Por exemplo,sendMessage oustop.

   Underscores podem aparecer nos nomes do método de ensaio JUnit para separar os componentes lógicos do nome, com cada componente escrito em minúsculas.Um padrão típico é <methodUnderTest>_<state>,por exemplo pop_emptyStack. Não há uma maneira correcta de nomear os métodos de ensaio.

   5.2.4 nomes constantes

   nomes constantes usam CONSTANT_CASE: todos os uppercaseletters, com cada palavra separada do próximo por um único sublinhado. Mas o que é o aconstant, exactamente?

   constantes são campos finais estáticos cujo conteúdo é profundamente imutável e cujos métodos têm efeitos colaterais nodetectáveis. Isto inclui primitivas, Cadeias de caracteres, tipos imutáveis, e coleções imutáveis de tipos imutáveis. Se qualquer estado observável da instância pode mudar, não é aconstante. Apenas a intenção de nunca mutar o objeto não é suficiente. Exemplo:

   // Constantsstatic final int NUMBER = 5;static final ImmutableList<String> NAMES = ImmutableList.of("Ed", "Ann");static final ImmutableMap<String, Integer> AGES = ImmutableMap.of("Ed", 35, "Ann", 32);static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is immutablestatic final SomeMutableType EMPTY_ARRAY = {};enum SomeEnum { ENUM_CONSTANT }// Not constantsstatic String nonFinal = "non-final";final String nonStatic = "non-static";static final Set<String> mutableCollection = new HashSet<String>();static final ImmutableSet<SomeMutableType> mutableElements = ImmutableSet.of(mutable);static final ImmutableMap<String, SomeMutableType> mutableValues = ImmutableMap.of("Ed", mutableInstance, "Ann", mutableInstance2);static final Logger logger = Logger.getLogger(MyClass.getName());static final String nonEmptyArray = {"these", "can", "change"};

   estes nomes são tipicamente substantivos ou frases substantivas.

   5.2.5 os nomes dos campos não constantes

   os nomes dos campos não constantes (estáticos ou não) estão escritos em minúsculas.

   estes nomes são tipicamente substantivos ou frases substantivas. Por exemplo,computedValues ouindex.

   5.2.6 os nomes dos parâmetros

   os nomes dos parâmetros estão escritos em minúsculas.os nomes dos parâmetros de um carácter nos métodos públicos devem ser evitados.

   5.2.7 os nomes das variáveis locais

   os nomes das variáveis locais estão escritos em minúsculas.

   mesmo quando finais e imutáveis, variáveis locais não são consideradas constantes, e não devem ser estilizadas como constantes.

   5.2.8 Tipo de nomes de variáveis

   Cada variável do tipo é chamado em um dos dois estilos:

   • Uma única letra maiúscula, seguido opcionalmente de um único numeral (como ETXT2
   • Um nome no formulário utilizado para as aulas (ver Secção 5.2.2, nomes de Classe), seguido pela letra maiúscula T (exemplos: RequestTFooBarT).

   5.3 caso Camelo: definido

   às vezes há mais de uma maneira razoável de converter uma frase em caso camelo,como quando acrônimos ou construções incomuns como “IPv6” ou “iOS” estão presentes. Para melhorar a previsibilidade, o estilo Google especifica o seguinte esquema determinístico (quase).

   começando com a forma em prosa do nome:

   1. converta a frase para ASCII simples e remova quaisquer apóstrofos. Por exemplo,” algoritmo de Müller “pode se tornar”algoritmo de Muellers”.
   2. divida este resultado em palavras, dividindo em espaços e qualquer pontuação restante (tipicamente hifens).
      • recomendado: se alguma palavra já tem uma aparência convencional de caso de camelo no uso comum, dividi – la em suas partes constituintes (por exemplo, “AdWords” torna-se “Ad words”). Note – se que uma palavra como “iOS” não é realmente em caso de camelo em si; desafia qualquer convenção, por isso esta recomendação não se aplica.
   3. Agora tudo minúsculo( incluindo acrónimos), em seguida, maiúscula apenas o primeiro carácter de:
      • … cada palavra, para dar a caixa de camelo superior, ou
      • … cada palavra, exceto a primeira, para produzir minúsculo caso camelo
   4. finalmente, juntar todas as palavras em um único identificador.Note-se que o invólucro das palavras originais não é praticamente tomado em consideração. Exemplo:
      

      Prose form	Correct	Incorrect
      “XML HTTP request”	XmlHttpRequest	XMLHTTPRequest
      “new customer ID”	newCustomerId	newCustomerID
      “inner stopwatch”	innerStopwatch	innerStopWatch
      “supports IPv6 on iOS?”	supportsIpv6OnIos	supportsIPv6OnIOS
      “YouTube importer”	YouTubeImporter YoutubeImporter*

      *Acceptable, but not recommended.

      Note: Some words are ambiguously hyphenated in the Englishlanguage: for example “nonempty” and “non-empty” are both correct, so the method namescheckNonempty andcheckNonEmpty are likewise both correct.

      6 Programming Practices

      6.1 @Override: sempre usado

      um método é marcado com o@Override anotação sempre que é legal. Isto inclui um método de classe que sobrepõe um método de superclasse, um método de classe que implementa um método de interface, e um método de interface que refere um método de superinterface.

      excepção:@Override pode ser omitido quando o método-mãe for@Deprecated.

      6. 2 exceções capturadas: não ignoradas

      exceto como indicado abaixo, é muito raramente correto não fazer nada em resposta a uma cautionexception. (Respostas típicas são para logá-lo, ou se for considerado “impossível”, rethrow it as anAssertionError.)

      Quando realmente é apropriado não tomar qualquer medida em um bloco de captura, a razão pela qual isso é justificado é explicada em um comentário.

      try { int i = Integer.parseInt(response); return handleNumericResponse(i);} catch (NumberFormatException ok) { // it's not numeric; that's fine, just continue}return handleTextResponse(response);

      excepção: nos ensaios, uma excepção capturada pode ser Sem comentários se o seu nome For ou começar com expected. O seguinte é um idioma muito comum para garantir que o código sob teste não lança uma excepção do tipo esperado, por isso um comentário é desnecessário aqui.

      6.3 membros estáticos: qualificados usando a classe

      quando uma referência a um membro da classe estática deve ser qualificada, é qualificada com o nome dessa classe, não com uma referência ou expressão do tipo dessa classe.

      Foo aFoo = ...;Foo.aStaticMethod(); // goodaFoo.aStaticMethod(); // badsomethingThatYieldsAFoo().aStaticMethod(); // very bad

      6.4 Finalizadores: não usados

      é extremamente raro sobreporObject.finalize.dica: não o faças. Se você absolutamente deve, primeiro ler e entender eficaz Item Java 7, “evitar Finalizadores”, com muito cuidado, e então não fazê-lo.

      7 Javadoc

      7.1 formatação

      7.1.1 forma geral

      a formatação básica de blocos Javadoc é vista neste exemplo:

      /** * Multiple lines of Javadoc text are written here, * wrapped normally... */public int method(String p1) { ... }

      … ou neste exemplo de linha única:

      /** An especially short bit of Javadoc. */

      a forma básica é sempre aceitável. A forma de linha única pode ser substituída quando a entirety of the Javadoc block (including comment markers) pode caber em uma única linha. Note que isso só acontece quando não existem tags em bloco como @return.

      7, 1.2 parágrafos

      uma linha em branco—ou seja, uma linha que contém apenas o asterisco principal alinhado(*) – aparece entre parágrafos, e antes do grupo de etiquetas de bloco ifpresent. Cada parágrafo,mas o primeiro tem imediatamente antes da primeira palavra, sem espaço depois.

      7.1.3 Bloco de tags

      Qualquer forma padrão do bloco “tags” que são utilizados aparecem na ordem @param@return@throws@deprecated, e estes quatro tipos de neverappear com uma descrição vazia. Quando uma etiqueta de bloco não cabe em uma única linha, as linhas de continuação são indentificadas quatro (ou mais) espaços a partir da posição do @.

      7.2 o fragmento de resumo

      cada bloco Javadoc começa com um breve fragmento de resumo. Esta mudança é muito importante: é a única parte do texto que aparece em certos contextos, como índices de classe e método.

      Este é um fragmento-uma frase substantiva ou frase verbal, não uma frase completa. Ele não começam com A {@code Foo} is a..., ouThis method returns..., nem formam um imperativo sentencelike Save the record.. No entanto, o fragmento é capitalizado e punctuado como se fosse uma sentença completa.

      Tip: um erro comum é escrever Javadoc simples na forma/** @return the customer ID */. Isto é incorreto, e deve ser alterado para /** Returns the customer ID. */.

      7.3, Onde o Javadoc é usado

      No mínimo, Javadoc está presente para cadapublic classe, e cadapublic ouprotected membro de uma classe, com algumas exceptionsnoted abaixo.

      conteúdo Javadoc adicional também pode estar presente,como explicado na secção 7.3.4, Javadoc não requerido.

      7.3.1 excepção: métodos auto-explicativos

      Javadoc é opcional para métodos” simples e óbvios”comogetFoo, nos casos em que realmente e verdadeiramente nada vale a pena dizer mas”Devolve o foo”.importante: não é apropriado citar esta excepção para justificar a obtenção de informações relevantes que um leitor típico possa necessitar de conhecer. Por exemplo, para um methodnamed getCanonicalName, não se omita a sua documentação(com a justificativa de que ele diria apenas/** Returns the canonical name. */) se um típico leitor pode não ter ideawhat o termo “nome canônico” significa!

      7.3.2 excepção: sobrepõe

      Javadoc nem sempre está presente num método que se sobrepõe a um método de supertipo.

      7.3.4 Javadoc não exigido

      outras classes e membros têm Javadoc conforme necessário ou desejado.