Java Language
ओरेकल आधिकारिक कोड मानक

परिचय

टिप्पणियों

नामकरण की परंपरा

पैकेज के नाम

• पैकेज के नाम अंडरस्कोर या अन्य विशेष पात्रों के बिना सभी निचले मामले होने चाहिए।
• पैकेज के नाम डेवलपर की कंपनी के वेब पते के उलट प्राधिकरण भाग से शुरू होते हैं। इस हिस्से को प्रोजेक्ट / प्रोग्राम स्ट्रक्चर डिपेंडेंट पैकेज सबस्ट्रक्चर द्वारा फॉलो किया जा सकता है।
• बहुवचन रूप का उपयोग न करें। मानक एपीआई जो उदाहरण के लिए उपयोग करता है की परिपाटी निम्न java.lang.annotation और नहीं java.lang.annotations ।
• उदाहरण: com.yourcompany.widget.button , com.yourcompany.core.api

क्लास, इंटरफ़ेस और एनम नाम

• क्लास और एनम नाम आमतौर पर संज्ञाएं होनी चाहिए।
• इंटरफ़ेस के नाम आमतौर पर संज्ञा या विशेषण के साथ समाप्त होने चाहिए ... सक्षम होने के साथ।
• ऊपरी मामले में प्रत्येक शब्द में पहले अक्षर के साथ मिश्रित मामले का उपयोग करें (यानी कैमलकेज़ )।
• नियमित अभिव्यक्ति से मिलान करें ^[AZ][a-zA-Z0-9]*$ ।
• पूरे शब्दों का उपयोग करें और संक्षिप्त रूप का उपयोग करने से बचें जब तक कि संक्षिप्त रूप लंबे रूप से अधिक व्यापक रूप से उपयोग नहीं किया जाता है।
• एक शब्द के रूप में एक संक्षिप्त नाम प्रारूपित करें यदि यह एक लंबे वर्ग नाम का हिस्सा है।
• उदाहरण: ArrayList , BigInteger , ArrayIndexOutOfBoundsException , Iterable ।

विधि नाम

विधि के नाम आमतौर पर क्रियाओं या क्रियाओं के अन्य विवरण होने चाहिए

• उन्हें नियमित अभिव्यक्ति ^[az][a-zA-Z0-9]*$ मेल खाना चाहिए।
• निचले मामले में पहले अक्षर के साथ मिश्रित मामले का उपयोग करें।
• उदाहरण: toString , hashCode

चर

परिवर्तनीय नाम निचले मामले में पहले अक्षर के साथ मिश्रित मामले में होना चाहिए

• नियमित अभिव्यक्ति ^[az][a-zA-Z0-9]*$ मिलान करें
• आगे की सिफारिश: चर
• उदाहरण: elements , currentIndex

चर टाइप करें

साधारण मामलों के लिए जहां कुछ प्रकार के चर होते हैं वे एकल ऊपरी अक्षर का उपयोग करते हैं।

• नियमित अभिव्यक्ति से मिलान करें ^[AZ][0-9]?$
• यदि एक पत्र अन्य की तुलना में अधिक वर्णनात्मक है (जैसे कि K और V कुंजी और नक्शे या में मूल्यों के लिए R उपयोग कि एक समारोह वापसी प्रकार के लिए) अन्यथा उपयोग T ।
• ऐसे जटिल मामलों के लिए जहाँ एकल अक्षर प्रकार चर भ्रमित हो जाते हैं, सभी बड़े अक्षरों में लिखे गए लंबे नामों का उपयोग करें और अलग-अलग शब्दों को अंडरस्कोर ( _ ) का उपयोग करें।
• उदाहरण: T , V , SRC_VERTEX

स्थिरांक

स्थिरांक ( static final फ़ील्ड जिनकी सामग्री भाषा के नियमों या कन्वेंशन द्वारा अपरिवर्तनीय है) को अलग-अलग शब्दों में सभी बड़े अक्षरों और अंडरस्कोर ( _ ) के साथ नामित किया जाना चाहिए।

• नियमित अभिव्यक्ति से मिलान करें ^[AZ][A-Z0-9]*(_[A-Z0-9]+)*$
• उदाहरण: BUFFER_SIZE , MAX_LEVEL

नामकरण पर अन्य दिशा-निर्देश

• बाहरी दायरे में छिपने / छाया देने के तरीकों, चर और प्रकार चर से बचें।
• आज्ञा देना नाम की क्रिया क्षेत्र के आकार से संबंधित है। (उदाहरण के लिए, बड़ी कक्षाओं के क्षेत्रों के लिए वर्णनात्मक नाम और स्थानीय अल्पकालिक चर के लिए संक्षिप्त नाम का उपयोग करें।)
• सार्वजनिक स्थैतिक सदस्यों का नामकरण करते समय, पहचानकर्ता को स्व वर्णनात्मक होने दें यदि आपको लगता है कि वे सांख्यिकीय रूप से आयात किए जाएंगे।
• आगे पढ़ने: नामकरण अनुभाग (आधिकारिक जावा स्टाइल गाइड में)

_{स्रोत: ओरेकल से जावा स्टाइल दिशानिर्देश}

जावा स्रोत फ़ाइलें

• सभी पंक्तियों को एक पंक्ति फ़ीड वर्ण (LF, ASCII मान 10) के साथ समाप्त किया जाना चाहिए और उदाहरण के लिए CR या CR + LF नहीं।

• एक पंक्ति के अंत में कोई अनुगामी श्वेत स्थान नहीं हो सकता है।

• स्रोत फ़ाइल का नाम उस श्रेणी के नाम के बराबर होना चाहिए, जिसमें .java एक्सटेंशन होता है, यहां तक कि उन फ़ाइलों के लिए भी जिनमें केवल एक पैकेज निजी वर्ग होता है। यह उन फ़ाइलों पर लागू नहीं होता है जिनमें किसी भी वर्ग की घोषणाएँ नहीं होती हैं, जैसे कि package-info.java ।

विशेष वर्ण

• LF के अलावा एकमात्र स्वीकृत सफेद अंतरिक्ष वर्ण Space (ASCII मान 32) है। ध्यान दें कि इसका अर्थ है कि अन्य सफेद अंतरिक्ष वर्ण (उदाहरण के लिए, स्ट्रिंग और चरित्र शाब्दिक) को बच के रूप में लिखा जाना चाहिए।

• \' , \" , \\ , \t , \b , \r , \f , और \n को इसी अष्टक (जैसे \047 ) या यूनिकोड (जैसे \u0027 ) से बच गए वर्णों से अधिक पसंद किया जाना चाहिए।

• क्या परीक्षण के लिए उपरोक्त नियमों के खिलाफ जाने की आवश्यकता है, परीक्षण को आवश्यक रूप से आवश्यक इनपुट उत्पन्न करना चाहिए।

पैकेज की घोषणा

package com.example.my.package;

पैकेज की घोषणा रेखा से लिपटी नहीं होनी चाहिए, चाहे वह किसी पंक्ति की अनुशंसित अधिकतम लंबाई से अधिक हो।

आयात बयान

// First java/javax packages
import java.util.ArrayList;
import javax.tools.JavaCompiler;

// Then third party libraries
import com.fasterxml.jackson.annotation.JsonProperty;

// Then project imports
import com.example.my.package.ClassA;
import com.example.my.package.ClassB;

// Then static imports (in the same order as above)
import static java.util.stream.Collectors.toList;

• आयात कथनों को क्रमबद्ध किया जाना चाहिए ...

  • … मुख्य रूप से गैर-स्थैतिक / गैर-स्थैतिक आयात के साथ पहले।
  • … दूसरा निम्नलिखित आदेश के अनुसार पैकेज मूल द्वारा
    • जावा पैकेज
    • javax संकुल
    • बाहरी पैकेज (जैसे org.xml)
    • आंतरिक पैकेज (जैसे com.sun)
  • … लेसरिक क्रम में पैकेज और वर्ग पहचानकर्ता द्वारा तृतीयक

• आयात विवरण पंक्तिबद्ध नहीं होना चाहिए, चाहे वह किसी पंक्ति की अनुशंसित अधिकतम लंबाई से अधिक हो।

• कोई अप्रयुक्त आयात मौजूद नहीं होना चाहिए।

वाइल्डकार्ड आयात करता है

• वाइल्डकार्ड आयात का सामान्य उपयोग नहीं किया जाना चाहिए।
• बड़ी संख्या में निकटता से संबंधित कक्षाओं (जैसे कि दर्जनों अलग-अलग "नोड" वर्गों के साथ एक पेड़ पर एक आगंतुक को लागू करने के लिए) आयात करते समय, एक वाइल्डकार्ड आयात का उपयोग किया जा सकता है।
• किसी भी स्थिति में, प्रति फ़ाइल एक वाइल्डकार्ड आयात से अधिक का उपयोग नहीं किया जाना चाहिए।

कक्षा संरचना

कक्षा के सदस्यों का आदेश

कक्षा के सदस्यों को निम्नानुसार आदेश दिया जाना चाहिए:

1. फ़ील्ड (सार्वजनिक, संरक्षित और निजी के क्रम में)
2. कंस्ट्रक्टर्स
3. कारखाने के तरीके
4. अन्य तरीके (सार्वजनिक, संरक्षित और निजी के क्रम में)

फ़ील्ड्स और विधियों को मुख्य रूप से उनके एक्सेस संशोधक या पहचानकर्ता द्वारा ऑर्डर करना आवश्यक नहीं है।

यहाँ इस आदेश का एक उदाहरण है:

class Example {

    private int i;

    Example(int i) {
        this.i = i;
    }

    static Example getExample(int i) {
        return new Example(i);
    }

    @Override
    public String toString() {
        return "An example [" + i + "]";
    }

}

कक्षा के सदस्यों का समूह बनाना

• संबंधित क्षेत्रों को एक साथ समूहीकृत किया जाना चाहिए।
• एक नेस्टेड प्रकार को इसके पहले उपयोग से ठीक पहले घोषित किया जा सकता है; अन्यथा इसे खेतों से पहले घोषित किया जाना चाहिए।
• कन्स्ट्रक्टर्स और ओवरलोड तरीकों को कार्यक्षमता द्वारा एक साथ समूहीकृत किया जाना चाहिए और बढ़ती हुई धमनी के साथ आदेश दिया जाना चाहिए। इसका मतलब यह है कि इन निर्माणों के बीच प्रतिनिधिमंडल कोड में नीचे की ओर बहता है।
• बीच में अन्य सदस्यों के बिना कंस्ट्रक्टर्स को एक साथ समूहित किया जाना चाहिए।
• एक विधि के अतिभारित वेरिएंट को अन्य सदस्यों के बिना एक साथ समूहीकृत किया जाना चाहिए।

संशोधक

class ExampleClass {
    // Access modifiers first (don't do for instance "static public")
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

interface ExampleInterface {
    // Avoid 'public' and 'abstract' since they are implicit
    void sayHello();
}

• संशोधक को निम्नलिखित क्रम में जाना चाहिए

  • पहुँच संशोधक ( public / private / protected )
  • abstract
  • static
  • final
  • transient
  • volatile
  • default
  • synchronized
  • native
  • strictfp

• संशोधित किए जाने पर संशोधक को बाहर नहीं लिखा जाना चाहिए। उदाहरण के लिए, इंटरफ़ेस विधियों को न तो public घोषित किया जाना चाहिए और न ही abstract , और नेस्टेड एनम और इंटरफेस को स्थिर घोषित नहीं किया जाना चाहिए।

• जब तक यह पठनीयता या दस्तावेजों को एक वास्तविक डिजाइन निर्णय में सुधार नहीं करता है, तब तक पैरामीटर और स्थानीय चर को final घोषित नहीं किया जाना चाहिए।

• फ़ील्ड्स को तब तक final घोषित किया जाना चाहिए जब तक कि उन्हें आपस में जोड़ने के लिए एक सम्मोहक कारण न हो।

खरोज

• इंडेंटेशन लेवल चार स्पेस है ।
• केवल अंतरिक्ष पात्रों का उपयोग इंडेंटेशन के लिए किया जा सकता है। कोई टैब नहीं।
• खाली लाइनों को इंडेंट नहीं किया जाना चाहिए। (यह बिना पीछे चल रहे सफेद अंतरिक्ष नियम से निहित है।)
• case लाइनों को चार स्थानों के साथ इंडेंट किया जाना चाहिए, और मामले के भीतर बयानों को अन्य चार स्थानों के साथ इंडेंट किया जाना चाहिए।

switch (var) {
    case TWO:
        setChoice("two");
        break;
    case THREE:
        setChoice("three");
        break;
    default:
        throw new IllegalArgumentException();
}

निरंतरता लाइनों को कैसे इंडेंट करें, इस दिशा निर्देशों के लिए रैपिंग स्टेटमेंट देखें।

रैपिंग स्टेटमेंट्स

• स्रोत कोड और टिप्पणियां आम तौर पर प्रति पंक्ति 80 वर्णों से अधिक नहीं होनी चाहिए और शायद ही कभी प्रति पंक्ति 100 वर्णों से अधिक हों, जिसमें इंडेंटेशन भी शामिल है।

  वर्ण सीमा का निर्धारण केस के आधार पर किया जाना चाहिए। जो वास्तव में मायने रखता है वह है लाइन का "घनत्व" और पठनीयता। लाइनों को कृतज्ञतापूर्वक लंबे समय तक पढ़ना उन्हें कठिन बनाता है; इसी तरह, उन्हें 80 स्तंभों में फिट करने के लिए "वीरतापूर्ण प्रयास" करना भी उन्हें पढ़ने के लिए कठिन बना सकता है। यहां बताए गए लचीलेपन का उद्देश्य डेवलपर्स को इन चरम सीमाओं से बचने में सक्षम करना है, न कि मॉनिटर रियल-एस्टेट का अधिकतम उपयोग करना।

• URL या उदाहरण कमांड को लपेटा नहीं जाना चाहिए।

// Ok even though it might exceed max line width when indented.
Error e = isTypeParam
        ? Errors.InvalidRepeatableAnnotationNotApplicable(targetContainerType, on)
        : Errors.InvalidRepeatableAnnotationNotApplicableInContext(targetContainerType));

// Wrapping preferable
String pretty = Stream.of(args)
                      .map(Argument::prettyPrint)
                      .collectors(joining(", "));

// Too strict interpretation of max line width. Readability suffers.
Error e = isTypeParam
        ? Errors.InvalidRepeatableAnnotationNotApplicable(
                targetContainerType, on)
        : Errors.InvalidRepeatableAnnotationNotApplicableInContext(
                targetContainerType);

// Should be wrapped even though it fits within the character limit
String pretty = Stream.of(args).map(Argument::prettyPrint).collectors(joining(", "));

• उच्च सिंटैक्टिकल स्तर पर रैपिंग को कम सिंटैक्टिकल स्तर पर रैपिंग से अधिक पसंद किया जाता है।

• प्रति पंक्ति में अधिकतम 1 कथन होना चाहिए।

• एक निरंतरता रेखा निम्न चार तरीकों में से एक में इंडेंट होनी चाहिए

  • वेरिएंट 1 : पिछली पंक्ति के इंडेंटेशन के सापेक्ष 8 अतिरिक्त स्थान।
  • वेरिएंट 2 : लिपटे हुए अभिव्यक्ति के शुरुआती कॉलम के सापेक्ष 8 अतिरिक्त स्थान।
  • वेरिएंट 3 : पिछली भाई-बहनों की अभिव्यक्ति (जब तक यह स्पष्ट है कि यह एक निरंतरता रेखा है) के साथ संरेखित किया गया है
  • वेरिएंट 4 : एक जंजीर अभिव्यक्ति में पिछले विधि कॉल के साथ संरेखित।

रैपिंग मेथड डिक्लेरेशन

int someMethod(String aString,
               List<Integer> aList,
               Map<String, String> aMap,
               int anInt,
               long aLong,
               Set<Number> aSet,
               double aDouble) {
    …
}

int someMethod(String aString, List<Integer> aList,
        Map<String, String> aMap, int anInt, long aLong,
        double aDouble, long aLong) {
    …
}

int someMethod(String aString,
               List<Map<Integer, StringBuffer>> aListOfMaps,
               Map<String, String> aMap)
        throws IllegalArgumentException {
    …
}

int someMethod(String aString, List<Integer> aList,
        Map<String, String> aMap, int anInt)
                throws IllegalArgumentException {
    …
}

• विधि घोषणाओं को तर्कों को लंबवत या एक नई पंक्ति और +8 अतिरिक्त रिक्त स्थान द्वारा सूचीबद्ध किया जा सकता है
• यदि एक थ्रो क्लॉज को लपेटने की आवश्यकता होती है, तो थ्रो क्लॉज के सामने लाइन ब्रेक लगाएं और सुनिश्चित करें कि यह तर्क सूची से बाहर निकलता है, या तो फ़ंक्शन घोषणा के सापेक्ष +8, या पिछली लाइन के सापेक्ष +8।

रैपिंग एक्सप्रेशंस

• यदि कोई रेखा अधिकतम वर्ण सीमा तक पहुंचती है, तो हमेशा लाइन को लपेटने के बजाय इसे कई कथनों / अभिव्यक्तियों में तोड़ने पर विचार करें।
• ऑपरेटरों से पहले तोड़ो।
• से पहले तोड़ो। जंजीर विधि कॉल में।

popupMsg("Inbox notification: You have "
        + newMsgs + " new messages");

// Don't! Looks like two arguments
popupMsg("Inbox notification: You have " +
         newMsgs + " new messages");

श्वेत रिक्ति

कार्यक्षेत्र व्हाट्सएप

• एक अलग लाइन को अलग करने के लिए इस्तेमाल किया जाना चाहिए ...

  • पैकेज की घोषणा
  • वर्ग घोषणाएँ
  • कंस्ट्रक्टर्स
  • तरीके
  • स्टेटिक इनिशियलाइज़र
  • उदाहरण शुरुआती

• … और तार्किक समूहों को अलग करने के लिए इस्तेमाल किया जा सकता है

  • आयात बयान
  • खेत
  • बयान

• एकाधिक लगातार रिक्त लाइनों का उपयोग केवल संबंधित सदस्यों के अलग-अलग समूहों के लिए किया जाना चाहिए न कि मानक अंतर-सदस्य रिक्ति के रूप में।

क्षैतिज व्हाट्सएप

• एक एकल स्थान का उपयोग किया जाना चाहिए ...

  • कोष्ठक और ब्रेसिज़ को खोलने या बंद करने से कीवर्ड को अलग करने के लिए
  • पहले और बाद के सभी बाइनरी ऑपरेटर और ऑपरेटर जैसे प्रतीक जैसे कि लंबोदर एक्सप्रेशंस में तीर और लूप के लिए वर्धित बृहदान्त्र (लेकिन लेबल के बृहदान्त्र से पहले नहीं)
  • के बाद // जो एक टिप्पणी शुरू करता है।
  • अल्पविराम के बाद तर्कों और अर्धविरामों को एक लूप के हिस्सों को अलग करना।
  • एक कलाकार के समापन कोष्ठक के बाद।

• चर घोषणाओं में यह प्रकार और चर संरेखित करने के लिए अनुशंसित नहीं है।

परिवर्तनीय घोषणाएँ

• एक चर प्रति घोषणा (और प्रति पंक्ति अधिकतम एक घोषणा)
• सरणियों के वर्ग कोष्ठक प्रकार ( String[] args ) पर होने चाहिए न कि चर पर ( String args[] )।
• पहली बार उपयोग किए जाने से ठीक पहले एक स्थानीय वैरिएबल की घोषणा करें, और इसे यथासंभव घोषणा के करीब शुरू करें।

एनोटेशन

घोषणा-पत्र को एनोटेशन घोषित किए जाने से अलग लाइन पर रखा जाना चाहिए।

@SuppressWarnings("unchecked")
public T[] toArray(T[] typeHolder) {
    ...
}

हालाँकि, एकल-लाइन विधि की व्याख्या करने वाले कुछ या छोटे एनोटेशन को उसी लाइन पर रखा जा सकता है जब वह पठनीयता में सुधार करता है। उदाहरण के लिए, कोई भी लिख सकता है:

@Nullable String getName() { return name; }

स्थिरता और पठनीयता के मामले के लिए, या तो सभी एनोटेशन को एक ही लाइन पर रखा जाना चाहिए या प्रत्येक एनोटेशन को एक अलग लाइन पर रखा जाना चाहिए।

// Bad.
@Deprecated @SafeVarargs
@CustomAnnotation
public final Tuple<T> extend(T... elements) {
    ...
}

// Even worse.
@Deprecated @SafeVarargs
@CustomAnnotation public final Tuple<T> extend(T... elements) {
    ...
}

// Good.
@Deprecated
@SafeVarargs
@CustomAnnotation
public final Tuple<T> extend(T... elements) {
    ...
}

// Good.
@Deprecated @SafeVarargs @CustomAnnotation
public final Tuple<T> extend(T... elements) {
    ...
}

लैंबडा एक्सप्रेशन

Runnable r = () -> System.out.println("Hello World");

Supplier<String> c = () -> "Hello World";

// Collection::contains is a simple unary method and its behavior is
// clear from the context. A method reference is preferred here.
appendFilter(goodStrings::contains);

// A lambda expression is easier to understand than just tempMap::put in this case
trackTemperature((time, temp) -> tempMap.put(time, temp));

• एक्सप्रेशन लैम्ब्डा को सिंगल-लाइन ब्लॉक लैम्ब्डा से अधिक पसंद किया जाता है।
• विधि संदर्भों को आमतौर पर लंबोदर अभिव्यक्तियों पर प्राथमिकता दी जानी चाहिए।
• बाध्य उदाहरण विधि संदर्भों के लिए, या एक से अधिक arity वाले तरीकों के लिए, एक लंबोदर अभिव्यक्ति को समझना आसान हो सकता है और इसलिए पसंद किया जाता है। खासकर अगर विधि का व्यवहार संदर्भ से स्पष्ट नहीं है।
• जब तक वे पठनीयता में सुधार नहीं करते तब तक पैरामीटर प्रकारों को छोड़ दिया जाना चाहिए।
• यदि एक लंबोदर अभिव्यक्ति कुछ रेखाओं से अधिक फैलती है, तो एक विधि बनाने पर विचार करें।

निरर्थक कोष्ठक

return flag ? "yes" : "no";

String cmp = (flag1 != flag2) ? "not equal" : "equal";

// Don't do this
return (flag ? "yes" : "no");

• यदि वे पठनीयता में सुधार करते हैं तो निरर्थक समूहीकरण कोष्ठक (अर्थात मूल्यांकन को प्रभावित नहीं करने वाले कोष्ठक) का उपयोग किया जा सकता है।
• निरर्थक समूहीकरण कोष्ठकों को आम तौर पर आम ऑपरेटरों को शामिल करने वाले छोटे भावों में छोड़ दिया जाना चाहिए, लेकिन लंबे समय तक अभिव्यक्तियों या अभिव्यक्तियों में ऐसे संचालकों को शामिल किया जाना चाहिए जिनकी पूर्वता और सहानुभूति बिना कोष्ठक के अस्पष्ट है। गैर-तुच्छ परिस्थितियों के साथ तिर्यक अभिव्यक्तियाँ बाद की हैं।
• एक return कीवर्ड के बाद संपूर्ण अभिव्यक्ति को कोष्ठकों से घिरा नहीं होना चाहिए।

शाब्दिक

long l = 5432L;
int i = 0x123 + 0xABC;
byte b = 0b1010;
float f1 = 1 / 5432f;
float f2 = 0.123e4f;
double d1 = 1 / 5432d;  // or 1 / 5432.0
double d2 = 0x1.3p2;

• long शाब्दिक ऊपरी मामले पत्र L प्रत्यय का उपयोग करना चाहिए।
• हेक्साडेसिमल शाब्दिकों को ऊपरी केस अक्षरों A - F उपयोग करना चाहिए।
• अन्य सभी संख्यात्मक उपसर्ग, infixes, और प्रत्यय लोअरकेस अक्षर का उपयोग करना चाहिए।

ब्रेसिज़

class Example {
    void method(boolean error) {
        if (error) {
            Log.error("Error occurred!");
            System.out.println("Error!");
        } else { // Use braces since the other block uses braces.
            System.out.println("No error");
        }
    }
}

• खुलने वाले ब्रेसिज़ को वर्तमान लाइन के अंत में रखा जाना चाहिए बजाय इसके कि एक लाइन पर।

• एक ब्रेसिंग ब्रेस के सामने एक नई रेखा होनी चाहिए जब तक कि ब्लॉक खाली न हो (नीचे संक्षिप्त रूप देखें)

• जहां भाषा उन्हें वैकल्पिक बनाती है, वहां भी ब्रेसेस की सिफारिश की जाती है, जैसे एकल-पंक्ति अगर और लूप बॉडी।

  • यदि कोई ब्लॉक एक से अधिक पंक्ति (टिप्पणियों सहित) में है, तो उसमें ब्रेसिज़ होना चाहिए।
  • एक में ब्लॉक में से एक हैं if / else बयान ब्रेसिज़ है, अन्य ब्लॉक भी करना चाहिए।
  • यदि ब्लॉक किसी एन्कोडिंग ब्लॉक में आता है, तो उसमें ब्रेसिज़ होना चाहिए।

• else , catch और while कीवर्ड do…while लूप उसी पंक्ति पर चलते हैं जो पूर्ववर्ती ब्लॉक के बंद ब्रेस के रूप में होता है।

लघु रूप

enum Response { YES, NO, MAYBE }
public boolean isReference() { return true; }

उपरोक्त सिफारिशों का उद्देश्य एकरूपता में सुधार करना है (और इस प्रकार परिचितता / पठनीयता में वृद्धि करना)। कुछ मामलों में "छोटे रूप" जो उपरोक्त दिशा-निर्देशों से विचलित होते हैं, केवल पढ़ने योग्य होते हैं और उनका उपयोग किया जा सकता है। इन मामलों में उदाहरण के लिए सरल एनुम घोषणाएं और तुच्छ तरीके और लंबोदर अभिव्यक्ति शामिल हैं।