1 Introduksjon

dette dokumentet fungerer som den fullstendige definisjonen Av Googles kodingsstandarder for kildekoden i Programmeringsspråket Java™. En Java kildefil er beskrevet som inGoogle Stil hvis og bare hvis det overholder reglene her.

som andre programmerings stil guider, problemene dekket span ikke bare estetiske problemer av formatting, men andre typer konvensjoner eller koding standarder også. Dette dokumentet fokuserer imidlertid primært på de harde og raske reglene som vi følger universelt, og gir råd som ikke er klart håndhevbare (enten av menneske eller verktøy).

1.1 Terminologi notater

i dette dokumentet, med mindre annet er avklart:

1. begrepet klasse brukes inklusivt til å bety en «vanlig» klasse, enum klasse, grensesnitt eller annotasjonstype (@interface).
2. begrepet medlem (av en klasse) brukes inklusivt til å bety en nestet klasse, felt, metode eller konstruktør; det vil si alt innhold på toppnivå i en klasse unntatt initialisatorer og kommentarer.
3. begrepet kommentar refererer alltid til implementeringskommentarer. Vi bruker ikke uttrykket «dokumentasjonskommentarer», i stedet bruker det vanlige begrepet » Javadoc.»

Andre «terminologinotater» vises av og til i hele dokumentet.

1.2 Guide merknader

Eksempelkoden i dette dokumentet er ikke-normativ. Det er, mens eksempleneer I Google Stil, kan de ikke illustrere den eneste stilige måten å representerekode. Valgfrie formateringsvalg i eksempler skal ikke håndheves som regler.

2 Grunnleggende Kildefil

2.1 Filnavn

kildefilnavnet består av det store og små bokstaver navnet på toppklasse den inneholder(hvorav det er nøyaktig en), pluss.java forlengelse.

2.2 filkoding: Utf-8

Kildefiler er kodet i UTF-8.

2.3 Spesialtegn

2.3.1 Mellomrom

BORTSETT fra linjeterminatorsekvensen, ER ASCII horisontal spacecharacter (0x20) det eneste mellomrom som vises hvor som helst i en kildefil. Dette innebærer at:

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) flukt.

2.3.3 ikke-ASCII-tegn

for de gjenværende ikke-ASCII-tegnene brukes Enten Det faktiske Unicode-tegnet(f.eks. ∞) eller tilsvarende Unicode escape(f. eks. \u221e). Valget avhenger bare avsom gjør koden enklere å lese og forstå, selv Om Unicode unnslipperutenfor strenglitteraler og kommentarer er sterkt motløs.

Tips: I Unicode escape-saken, og noen ganger selv når actualUnicode-tegn brukes, kan en forklarende kommentar være svært nyttig.

Eksempler:

Eksempel	Diskusjon
String unitAbbrev = "μs";	Best: helt klart selv uten en kommentar.
String unitAbbrev = "\u03bcs"; // "μs"	Tillatt, men det Er ingen grunn til å gjøre dette.
String unitAbbrev = "\u03bcs"; // Greek letter mu, "s"	Tillatt, men vanskelig og utsatt for feil.
String unitAbbrev = "\u03bcs";	Dårlig: leseren har ingen anelse om hva dette er.
return '\ufeff' + content; // byte order mark	Bra: bruk rømming for ikke-utskrivbare tegn, og kommentere om nødvendig.

Tips: gjør aldri koden mindre lesbar bare ut av frykt for atnoen programmer kan ikke håndtere ikke-ASCII-tegn riktig. Hvis det skulle skje, deprogrammer er ødelagte og de må løses.

3 Kildefil struktur

nøyaktig en tom linje skiller hver seksjon som er til stede.

3.1 Lisens-eller opphavsrettsinformasjon, hvis den finnes

hvis lisens-eller opphavsrettsinformasjon tilhører en fil, tilhører den her.

3.2 Pakke setning

pakken setningen er ikke line-pakket. Kolonnegrensen (Del 4.4, Kolonnegrensen: 100) gjelder ikke for pakkeutskrifter.

3.3 Import setninger

3.3.1 ingen import av jokertegn

Import av Jokertegn, statisk eller på annen måte, brukes ikke.

3.3.2 ingen linjeinnpakning

Importsetninger er ikke linjeinnpakket. Kolonnegrensen (Del 4.4, Kolonnegrensen: 100) gjelder ikke for importstatements.

3.3.3 Bestilling og avstand

Import bestilles som følger:

1. all statisk import i en enkelt blokk.
2. All ikke-statisk import i en enkelt blokk.

hvis det er både statisk og ikke-statisk import, skiller en enkelt tom linje de toblokker. Det er ingen andre tomme linjer mellom import uttalelser.

i hver blokk vises de importerte navnene I ASCII-sorteringsrekkefølge. (Merk: dette er ikke det samme som import-setningene er I ASCII sorteringsrekkefølge, siden’.’sorterer før’;’.)

3.3.4 ingen statisk import for klasser

Statisk import brukes ikke for statiske nestede klasser. De importeres mednormal import.

3.4 Klassedeklarasjon

3.4.1 Nøyaktig En toppklassedeklarasjon

hver toppklasseklasse ligger i en egen kildefil.

3.4.2 Bestilling av klasseinnhold

ordren du velger for medlemmer og initialisatorer av klassen din, kan ha stor effekt pålærbarhet. Det er imidlertid ingen enkelt riktig oppskrift på hvordan du gjør det; forskjellige klasser kan bestille innholdet på forskjellige måter.

det som er viktig er at hver klasse bruker noen logisk rekkefølge, som itsmaintainer kan forklare hvis du blir spurt. For eksempel, nye metoder er ikke bare vanlig lagt til endof klassen, som det ville gi» kronologisk etter dato lagt » bestilling, som ikke er en logiskordeling.

3.4.2.1 Overbelastning: splitt aldri

når en klasse har flere konstruktører, eller flere metoder med samme navn, vises disse sekvensielt, uten annen kode i mellom (ikke engang private medlemmer).

4 Formatering

Terminologi Merk: blokklignende konstruksjon refererer til en klasse, metode eller konstruktør. Merk at Ved Seksjon 4.8.3.1 onarray initializers, kan enhver array initializermay eventuelt behandles som om det var en blokklignende konstruksjon.

4,1 Bukseseler

4,1.1 Bukseseler brukes der valgfrie

Bukseseler brukes medifelsefordo ogwhile setninger, selv når kroppen er tom eller bare inneholder en enkelt setning.

4.1.2 Nonempty blokker: K & r stil

Bukseseler følg Kernighan og Ritchie stil(«Egyptiske braketter») for nonempty blokker og blokk-lignende konstruksjoner:

• ingen linjeskift før åpningen spenne.
• Linjeskift etter åpningen spenne.
• linjeskift før den avsluttende spenne.
• Linjeskift etter den avsluttende klammeparentesen, bare hvis denne klammeparentesen avslutter en setning eller avslutter brødteksten til en metode, konstruktør eller navngitt klasse. For eksempel er det ingen linjeskift etter bøylen hvis den etterfølges av else eller et komma.

Eksempler:

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(); } }};

noen få unntak for enum-klasser er gitt I Seksjon 4.8.1, Enum-klasser.

4.1.3 Tomme blokker: kan være kortfattet

en tom blokk eller blokklignende konstruksjon kan være I K & r-stil (som beskrevet inseksjon 4.1.2). Alternativt kan den lukkes umiddelbart etter at den er åpnet, uten tegn eller linjeskift i mellom ({}), med mindre den er en del av amulti-block-setningen (en som direkte inneholder flere blokker: if/else eller try/catch/finally).

Eksempler:

 // 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 blokk innrykk: +2 mellomrom

Hver gang en ny blokk eller blokklignende konstruksjon åpnes, øker innrykket med to områder. Når blokken slutter, går innrykket tilbake til forrige innrykksnivå. Innrykksnivåetgjelder for både kode og kommentarer i hele blokken. (Se eksemplet I Avsnitt 4.1.2, Nonempty blokker :K & R Stil.)

4.3 En setning per linje

hver setning etterfølges av et linjeskift.

4.4 Kolonne grense: 100

Java-koden har en kolonne grense på 100 tegn. Et «tegn» betyr Ethvert Unicode-kodepunkt.Med unntak av det som er angitt nedenfor, må en linje som overskrider denne grensen, være linjeinnpakket, som forklart i avsnitt 4.5, Linjeinnpakning.

Hvert Unicode-kodepunkt teller som ett tegn, selv om skjermbredden er større eller mindre. For eksempel, hvis du bruker fullwidth tegn, kan du velge å bryte linjen tidligere enn der denne regelen strengt krever.

Unntak:

1. Linjer der det ikke er mulig å adlyde kolonnegrensen (for eksempel en lang URL i Javadoc eller en lang jsni-metodereferanse).
2. package ogimport erklæringer (se Avsnitt 3.2 pakkeuttalelse og 3.3 importuttalelser).
3. Kommandolinjer i en kommentar som kan klippes og limes inn i et skall.

4.5 Line-wrapping

Terminologi Merk: når kode som ellers lovlig kan okkupere en enkelt linje, er delt inn i flere linjer, kalles denne aktiviteten line-wrapping.

det er ingen omfattende, deterministisk formel som viser nøyaktig hvordan man skal bryte inn i hver situasjon. Svært ofte er det flere gyldige måter å line-wrap samme stykke kode.

Merk: mens den typiske årsaken til linjeinnpakning er å unngå å overfylle kolonnegrensen, kan selv kode som faktisk ville passe innenfor kolonnegrensen, kanskje linjeinnpakket etter forfatterens skjønn.

Tips: Utpakking av en metode eller lokal variabel kan løse problemet uten behov for linjeinnpakning.

4.5.1 hvor å bryte

hoveddirektivet for linjeinnpakning er: foretrekker å bryte på ahøyere syntaktisk nivå. Also:

1. når en linje er brutt på en ikke-oppdrag operatør pause kommer før symbolet. (Merk at Dette ikke er den samme praksisen som Brukes I Google-stil for andre språk, For Eksempel C++ og JavaScript.)
   • dette gjelder også for følgende «operator-lignende» symboler:
     • dot-separatoren (.)
     • de to kolonene i en metodereferanse (::)
     • en ampersand i en typebundet (<T extends Foo & Bar>)
     • et rør i en fangstblokk (catch (FooException | BarException e)).
2. når en linje brytes på en oppdragsoperatør, kommer bruddet vanligvis etter symbolet, men uansett er akseptabelt.
   • dette gjelder også kolonet» tildeling-operator-lignende » i en forbedretfor («foreach») – setning.
3. en metode eller konstruktørnavn forblir knyttet til den åpne parentesen (() som følger den.
4. et komma (,) forblir festet til token som går foran det.
5. en linje blir aldri brutt ved siden av pilen i en lambda, bortsett fra at et brudd kan komme umiddelbart etter pilen hvis legemet til lambda består av et enkelt ubrutt uttrykk. Eksempler:

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

Merk: det primære målet for linjeinnpakning er å ha clearcode, ikke nødvendigvis kode som passer i det minste antall linjer.

4.5.2 Innrykk fortsettelseslinjer minst + 4 mellomrom

når linjeinnpakning, er hver linje etter den første (hver fortsettelseslinje) innrykketminst +4 fra den opprinnelige linjen.

når det er flere fortsettelseslinjer, kan innrykk varieres utover + 4 som ønsket. Generelt bruker to fortsettelseslinjer samme innrykksnivå hvis og bare hvis debegynner med syntaktisk parallelle elementer.Seksjon 4.6.3 På Horisontale justeringsadresserden motet praksis med å bruke et variabelt antall mellomrom for å justere bestemte tokens medtidligere linjer.

4.6 Mellomrom

4.6.1 Vertikal Mellomrom

en enkelt tom linje vises alltid:

1. mellom påfølgende medlemmer eller initialisatorer av en klasse: felt, konstruktører, metoder, nestede klasser, statiske initialisatorer og instans initialisatorer.
   • Unntak: en tom linje mellom to påfølgende felt (har ingen annen kode mellom dem) er valgfritt. Slike tomme linjer brukes etter behov for å opprette logiske grupperinger av felt.
   • Unntak: Tomme linjer mellom enum konstanter er dekket I Avsnitt 4.8.1.
2. som kreves av andre deler av dette dokumentet(For Eksempel Seksjon 3, Kildefilstruktur og Seksjon 3.3, Import setninger).

en enkelt tom linje kan også vises hvor som helst det forbedrer lesbarheten, for eksempel mellomuttalelser for å organisere koden i logiske delseksjoner. En tom linje før det første medlemmet eller initialisereren, eller etter det siste medlemmet eller initialisereren i klassen, oppfordres heller ikke nordiscouraged.

Flere påfølgende tomme linjer er tillatt, men aldri nødvendig (eller oppmuntret).

4.6.2 Vannrett mellomrom

Utover der det kreves av språk-eller andre stilregler, og bortsett fra bokstaver, kommentarer ogjavadoc, vises også ET ENKELT ASCII-område bare på følgende steder.

1. Skille et reservert ord, for eksempel iffor eller catch, fra en åpen parentes (() som følger den på den linjen/li>
2. skille et reservert ord, for eksempel elseeller catch, fra en avsluttende krøllete spenne (}) som går foran den på den linjen
3. før en åpen krøllete spenne ({), med to unntak:
   @SomeAnnotation({a, b}) (ingen plass brukes)

String x = {{"foo"}};(ingen plass kreves mellom{{, etter punkt 8 nedenfor)

4. på begge sider av en binær eller trefoldig operatør. Dette gjelder også for følgende» operatorlignende «symboler:
   • ampersand i en konjunktiv type bundet: <T extends Foo & Bar>
   • røret for en fangstblokk som håndterer flere unntak: catch (FooException | BarException e)
   • kolonet (:) i en forbedretfor («foreach») setning
   • pilen i et lambda-uttrykk: (String str) -> str.length()

   men ikke

   • de to kolonene (::) av en metodereferanse, som er skrevet som Object::toString
   • dot-separatoren (.), som er skrevet som object.toString()
5. etter ,:; eller den avsluttende parentes ()) av en støpt
6. på begge sider av den doble skråstrek (//) som begynner en sluttkommentar. Her er flere mellomrom tillatt, men ikke påkrevd.
7. mellom typen og variabelen i en erklæring:List<String> list

Er begge gyldige

8. new int {5, 6} og new int { 5, 6 } er begge gyldige

Mellom en type merknad og eller ....

denne regelen tolkes aldri som å kreve eller forby ekstra plass ved starten av en linje.

4.6.3 Horisontal justering: aldri nødvendig

Terminologi Notat: Horisontal justering erpraksis med å legge til et variabelt antall ekstra mellomrom i koden din med målet om å lage bestemte tokens vises rett under visse andre tokens på tidligere linjer.

denne praksisen er tillatt, Men kreves aldri Av Google-Stil. Det er ikkeselv nødvendig å opprettholde horisontal justering på steder der den allerede var brukt.

Her er et eksempel uten justering, og bruk deretter justering:

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

Tips: Justering kan hjelpe lesbarhet, men det skaper problemer forfremtidig vedlikehold. Tenk på en fremtidig endring som må berøre bare en linje. Denne endringen kan etterlate den tidligere tiltalende formateringen manglet, og det er tillatt. Ofteredet ber koderen (kanskje deg) for å justere mellomrom på nærliggende linjer også, possiblytriggering en cascading serie reformattings. At en linje endring har nå en » blast radius.»Dette kan i verste fall føre til meningsløst arbeid, men i beste fall ødelegger det fortsatt versjonshistorieinformasjon, bremser anmeldere og forverrer fusjonskonflikter.

4.7 Gruppering parenteser: anbefalt

Valgfrie gruppering parenteser utelates bare når forfatter og anmelder er enige om at det ikke er noen grunn til at koden vil bli feiltolket uten dem, og de ville heller ikke ha gjort kodeenklere å lese. Det er ikke rimelig å anta at hver leser har Hele Javaoperator-prioritetstabellen memorisert.

4.8 Spesifikke konstruksjoner

4.8.1 enum klasser

etter hvert komma som følger en enum konstant, er et linjeskift valgfritt. Ekstra blanklines (vanligvis bare en) er også tillatt. Dette er en mulighet:

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

En enum klasse uten metoder og ingen dokumentasjon på dens konstanter kan eventuelt formattedas hvis det var en array initializer (se Avsnitt 4.8.3.1 onarray initializers).

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

siden enum-klasser er klasser, gjelder alle andre regler for formatering av klasser.

4.8.2 Variable deklarasjoner

4.8.2.1 en variabel per deklarasjon

Hver variabeldeklarasjon (felt eller lokal) erklærer bare en variabel: deklarasjoner som int a, b; brukes ikke.

Unntak: Flere variable deklarasjoner er akseptable i overskriften til enfor loop.

4.8.2.2 Deklarert ved behov

Lokale variabler blir ikke vanligvis deklarert ved starten av deres containingblock eller blokklignende konstruksjon. I stedet deklareres lokale variabler nær det punktet de erførst brukt (innenfor grunn), for å minimere omfanget. Lokale variable deklarasjoner har typiskinitialisatorer, eller initialiseres umiddelbart etter erklæring.

4.8.3 Arrays

4.8.3.1 Array initializers: Kan være»block-like»

Enhver array initializer kan eventuelt formateres som om det var en » block-likeconstruct.»For eksempel følgende er alle gyldige (ikke en 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 Ingen c-stil array erklæringer

hakeparentesene danner en del av typen, ikke variabelen:String args, ikkeString args.

4.8.4 Switch setninger

Terminologi Merk: Inne bukseseler av aswitch blokk er en eller flere uttalelse grupper. Hver setningsgruppe består aven eller flere bryteretiketter (enten case FOO: ellerdefault:), etterfulgt av en eller flere setninger (eller, forden siste setningsgruppen, null eller flere setninger).

4.8.4.1 Innrykk

som med alle andre blokker, er innholdet i en bryterblokk innrykket +2.

etter en bryteretikett er det en linjeskift, og innrykksnivået økes +2, akkuratsom om en blokk ble åpnet. Følgende bryteretikett går tilbake til forrige innrykknivå, som om en blokk var lukket.

4.8.4.2 Fall-gjennom: kommentert

i en bryterblokk avsluttes hver setningsgruppe brått (med en breakcontinuereturn eller kastet unntak), eller er merket med en kommentar for å indikere at utførelsen vil eller kan fortsette inn i neste setningsgruppe. Anycomment som kommuniserer ideen om fall-through er tilstrekkelig(typisk // fall through). Denne spesielle kommentaren er ikke nødvendig iden siste setningsgruppen av bryterblokken. Eksempel:

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

Legg Merke til at ingen kommentar er nødvendig etter case 1:, barepå slutten av setningen gruppen.

4.8.4.3default saken er til stede

hver bryter setningen inneholder endefault statementgroup, selv om den ikke inneholder noen kode.

Unntak: en switch-setning for enenum – type kan utelatedefault – setningsgruppe, hvis den inkluderer alle mulige verdier av denne typen. Dette gjør Det Mulig For IDEs eller andre staticanalysis-verktøy å utstede en advarsel hvis noen tilfeller ble savnet.

4.8.5 Merknader

Merknader som gjelder for en klasse, metode eller konstruktør, vises umiddelbart etter dokumentasjonsblokken, og hver merknad er oppført på en egen linje (det vil si en annotasjonper-linje). Disse linjeskiftene utgjør ikke linjeinnpakning (Section4. 5, Linjeinnpakning), slik at innrykksnivået ikke økes. Eksempel:

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

Unntak: En enkelt parameterfri annotering kan i stedet vises sammen med den første linjen i signaturen, for eksempel:

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

Merknader som gjelder for et felt, vises også umiddelbart etter dokumentasjonsblokken, men i dette tilfellet kan flere merknader (muligens parameterisert) være oppført på samme linje;for eksempel:

@Partial @Mock DataLoader loader;

det er ingen spesifikke regler for formatering av merknader på parametere, lokale variabler eller typer.

denne delen omhandler implementeringskommentarer. Javadoc er adressert separat iseksjon 7, Javadoc.

ethvert linjeskift kan innledes med vilkårlig mellomrom etterfulgt av en implementeringskommentar.En slik kommentar gjør linjen ikke-tom.

4.8.6.1 Blokkkommentar stil

blokkkommentarer er innrykket på samme nivå som den omkringliggende koden. De kan være i /* ... */ stil eller // ... stil. For flere linjer/* ... */ kommentarer, må etterfølgende linjer starte med *justert med* på forrige linje.

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

Kommentarer er ikke vedlagt i bokser tegnet med stjerner eller andre tegn.

Tips: når du skriver flere linjekommentarer, bruk/* ... */ – stilen hvis du vil at automatiske kodeformatere rev-vikle linjene når det er nødvendig (avsnittsstil). De fleste formatere ikke re-wrap linjer i // ... stil kommentar blokker.

4.8.7 Modifikatorer

Klasse-og medlemsmodifikatorer, når de er til stede, vises i ordrenanbefalt av Java-Språkspesifikasjonen:

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

4.8.8 Numeriske Bokstaver

long-verdsatte heltallsskrifter bruker store bokstaver L suffiks, neverlowercase (for å unngå forveksling med sifferet 1). For eksempel 3000000000L i stedet for 3000000000l.

5 Naming

5.1 Regler som er felles for alle identifikatorer

Identifikatorer bruker BARE ASCII-bokstaver og sifre, og i et lite antall tilfeller nevnt nedenfor, understreker. Dermed blir hvert gyldig identifikasjonsnavn matchet med det vanlige uttrykket \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.

Klassenavn er vanligvis substantiv eller substantivfraser. For eksempelCharacter eller ImmutableList. Grensesnittnavn kan også være substantiv eller substantiv (for eksempel List), men kan noen ganger beadjektiver eller adjektivfraser i stedet (for eksempelReadable).

det er ingen spesifikke regler eller til og med veletablerte konvensjoner for å navngi annotasjonstyper.

Testklasser er navngitt med navnet på klassen de tester ,og endingwith Test. For eksempelHashTest eller HashIntegrationTest.

5.2.3 Metodenavn

Metodenavn er skrevet i lowerCamelCase.

Metodenavn er vanligvis verb eller verbfraser. For eksempelsendMessage ellerstop.

Understreker kan vises I JUnit testmetode navn for å skille logiske komponenter av thename, med hver komponent skrevet i lowerCamelCase.Et typisk mønster er <methodUnderTest>_<state>,for eksempel pop_emptyStack. Det Er Ingen Riktigmåte å nevne testmetoder på.

5.2.4 Konstante navn

Konstante navn bruk CONSTANT_CASE: alle uppercaseletters, med hvert ord skilt fra det neste med en enkelt understrek. Men hva er egentlig aconstant?

Konstanter er statiske sluttfelt hvis innhold er dypt uforanderlig og hvis metoder har nodetectable bivirkninger. Dette inkluderer primitiver, Strenger, uforanderlige typer og uforanderlige samlinger av uforanderlige typer. Hvis noen av forekomstens observerbare tilstand kan endres, er den ikke akonstant. Bare tenkt å aldri mutere objektet er ikke nok. Eksempler:

// 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"};

disse navnene er vanligvis substantiver eller substantivfraser.

5.2.5 ikke-konstante feltnavn

ikke-konstante feltnavn (statisk eller på annen måte) er skrevet i lowerCamelCase.

disse navnene er vanligvis substantiver eller substantivfraser. For eksempelcomputedValues eller index.

5.2.6 Parameter navn

Parameter navn er skrevet i lowerCamelCase.

parameternavn med ett tegn i offentlige metoder bør unngås.

5.2.7 Lokale variabelnavn

Lokale variabelnavn er skrevet i lowerCamelCase.

selv når de er endelige og uforanderlige, anses ikke lokale variabler for å være konstanter, og bør ikke utformes som konstanter.

5.2.8 type variable navn

hver type variabel er navngitt i en av to stiler:

• en enkelt stor bokstav, eventuelt etterfulgt av et enkelt tall (for eksempelETXT2)
• et navn i form som brukes for klasser (se avsnitt 5.2.2, klassenavn), etterfulgt av stor bokstavT (eksempler: RequestTFooBarT).

5.3 Camel case: definert

Noen ganger er det mer enn en rimelig måte å konvertere en engelsk setning til camel case, for eksempel når akronymer eller uvanlige konstruksjoner som «IPv6» eller «iOS» er til stede. For å forbedreforutsigbarhet, Angir Google Style følgende (nesten) deterministiske skjema.

Begynner med prosaformen av navnet:

1. Konverter uttrykket til vanlig ASCII og fjern eventuelle apostrofer. For eksempel kan» mü algoritme » bli «Muellers algoritme».
2. Del dette resultatet i ord, splitting på mellomrom og gjenværende tegnsetting (vanligvis bindestreker).
   • Anbefalt: hvis et ord allerede har en konvensjonell kamel-case utseende i vanlig bruk, dele dette inn i sine bestanddeler (f. eks, «AdWords» blir «annonseord»). Merk at et ord som » iOS » er egentlig ikke i kamel tilfelle per se; det trosser noen konvensjon, så denne anbefalingen gjelder ikke.
3. nå små bokstaver alt (inkludert akronymer), så store bokstaver bare det første tegnet av:
   • … hvert ord, for å gi øvre kamel sak, eller
   • … hvert ord unntatt det første, for å gi lavere kamel tilfelle
4. Til Slutt, bli med alle ordene i en enkelt identifikator.

Merk at foringsrøret til de opprinnelige ordene nesten er helt ignorert. Eksempler:

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: alltid brukt

en metode er merket med@Override annoteringnår det er lovlig. Dette inkluderer en klassemetode som overstyrer en superklassemetode, en klassemetodeimplementere en grensesnittmetode og en grensesnittmetode som respecifiserer en superinterfacemethod.

Unntak: @Override kan utelates når overordnet metode er @Deprecated.

6.2 Fanget unntak: ikke ignorert

Unntatt som nevnt nedenfor, er det svært sjelden riktig å ikke gjøre noe som svar på en caughtexception. (Typiske svar er å logge det, eller hvis det regnes som «umulig», kast det som enAssertionError.)

når det virkelig er hensiktsmessig å ikke gjøre noe i en fangstblokk, er grunnen til at dette er rettferdiggjort forklart i en kommentar.

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

Unntak: i tester kan et fanget unntak ignoreres uten kommentar hvis navnet er eller begynner med expected. Thefollowing er et veldig vanlig idiom for å sikre at koden under test kaster anexception av forventet type, så en kommentar er unødvendig her.

try { emptyStack.pop(); fail();} catch (NoSuchElementException expected) {}

6.3 Statiske medlemmer: kvalifisert ved hjelp av klasse

når en referanse til et statisk klassemedlem må være kvalifisert, er den kvalifisert med klassens navn, ikke med en referanse eller et uttrykk av klassens type.

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

6.4 Finalizers: ikke brukt

det er ekstremt sjelden å overstyre Object.finalize.

Tips: Ikke gjør det. Hvis du absolutt må, først lese Og forstå Effektiv Java Element 7, «Unngå Finalizers,» veldig nøye, og så ikke gjør det.

7 Javadoc

7.1 Formatering

7.1.1 Generell form

Grunnleggende formatering Av Javadoc-blokker er som vist i dette eksemplet:

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

… eller i dette enkeltlinjeeksemplet:

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

grunnformen er alltid akseptabel. Enkeltlinjeformen kan erstattes når Hele Javadoc-blokken (inkludert kommentarmarkører) kan passe på en enkelt linje. Merk at dette onlyapplies når det ikke er noen blokk koder som @return.

7.1.2 Avsnitt

En tom linje – det vil si en linje som bare inneholder den justerte ledende stjernen (*)—vises mellom avsnitt, og før gruppen av blokkkoder ifpresent. Hvert avsnitt, men det første har <p> umiddelbart før det første ordet, uten plass etter.

7.1.3 Blokk koder

noen av standard «blokk koder» som brukes vises i den rekkefølgen@param@return@throws@deprecated, og disse fire typene aldrivises med en tom beskrivelse. Når en blokkkode ikke passer på en enkelt linje, rykker fortsettelseslinjene inn fire (eller flere) mellomrom fra posisjonen til @.

7.2 sammendragsfragmentet

Hver Javadoc-blokk begynner med et kort sammendragsfragment. Thisfragment er svært viktig: det er den eneste delen av teksten som vises i visse sammenhenger somklasse og metode indekser.

dette er et fragment-et substantiv setning eller verb setning, ikke en komplett setning. Det begynner ikke med A {@code Foo} is a..., eller This method returns..., og danner heller ikke en fullstendig imperativ sentencelike Save the record.. Fragmentet er imidlertid kapitalisert ogpunktuert som om det var en komplett setning.

Tips: en vanlig feil er å skrive enkel Javadoc i skjemaet /** @return the customer ID */. Dette er feil, og bør endres til /** Returns the customer ID. */.

7.3 Der Javadoc brukes

som minimum, Er Javadoc til stede for hverpublic klasse, og hverpublicellerprotected medlem av en slik klasse, med noen unntaknotert nedenfor.

Ytterligere Javadoc-innhold kan også være til stede, som forklart I Avsnitt 7.3.4, Ikke-påkrevd Javadoc.

7.3.1 Unntak: selvforklarende metoder

Javadoc er valgfritt for «enkle, åpenbare» metoder somgetFoo, i tilfeller der det virkelig og virkelig eringenting annet verdt å si, Men «Returnerer foo».

Viktig: det er ikke hensiktsmessig å sitere dette unntaket for å rettferdiggjøre relevant informasjon som en typisk leser kanskje trenger å vite. For eksempel, for en metodenavn getCanonicalName, ikke utelat dokumentasjonen(med begrunnelsen at den bare ville si /** Returns the canonical name. */) hvis en typisk leser kanskje ikke har noen ide hva begrepet «kanonisk navn» betyr!

7.3.2 Unntak: overstyrer

Javadoc finnes ikke alltid på en metode som overstyrer en supertype-metode.

7.3.4 Ikke-påkrevd Javadoc

Andre klasser og medlemmer Har Javadoc etter behov eller ønsket.