कोड स्टाइल गाइड

HIDL कोड स्टाइल, Android फ़्रेमवर्क में C++ कोड से मिलती-जुलती है. इसमें चार स्पेस वाले इंडेंट और मिक्स्ड-केस वाले फ़ाइलनाम होते हैं. पैकेज के एलान, इंपोर्ट, और डॉकस्ट्रिंग, Java में मौजूद एलान, इंपोर्ट, और डॉकस्ट्रिंग से मिलते-जुलते हैं. हालांकि, इनमें कुछ बदलाव किए गए हैं.

IFoo.hal और types.hal के लिए यहां दिए गए उदाहरणों में, HIDL कोड स्टाइल के बारे में बताया गया है. साथ ही, हर स्टाइल के बारे में ज़्यादा जानकारी पाने के लिए क्विक लिंक दिए गए हैं. IFooClientCallback.hal, IBar.hal, और IBaz.hal को शामिल नहीं किया गया है.

hardware/interfaces/foo/1.0/IFoo.hal
/*
 * (License Notice)
 */

package android.hardware.foo@1.0;

import android.hardware.bar@1.0::IBar;

import IBaz;
import IFooClientCallback;

/**
 * IFoo is an interface that…
 */
interface IFoo {

    /**
     * This is a multiline docstring.
     *
     * @return result 0 if successful, nonzero otherwise.
     */
     foo() generates (FooStatus result);

    /**
     * Restart controller by power cycle.
     *
     * @param bar callback interface that…
     * @return result 0 if successful, nonzero otherwise.
     */
    powerCycle(IBar bar) generates (FooStatus result);

    /** Single line docstring. */
    baz();


    /**
     * The bar function.
     *
     * @param clientCallback callback after function is called
     * @param baz related baz object
     * @param data input data blob
     */
    bar(IFooClientCallback clientCallback,
        IBaz baz,
        FooData data);

};
hardware/interfaces/foo/1.0/types.hal
/*
 * (License Notice)
 */

package android.hardware.foo@1.0;

/** Replied status. */
enum Status : int32_t {
    OK,
    /* invalid arguments */
    ERR_ARG,
    /* note, no transport related errors */
    ERR_UNKNOWN = -1,
};

struct ArgData {
    int32_t[20]  someArray;
    vec<uint8_t> data;
};

नाम रखने के नियम

फ़ंक्शन के नाम, वैरिएबल के नाम, और फ़ाइल के नाम ऐसे होने चाहिए जिनसे उनके बारे में पता चले. नामों को बहुत छोटा न करें. अक्रोनियम को शब्दों की तरह इस्तेमाल करें. उदाहरण के लिए, INFC के बजाय INfc का इस्तेमाल करें.

डायरेक्ट्री का स्ट्रक्चर और फ़ाइल का नाम

डायरेक्ट्री का स्ट्रक्चर ऐसा दिखना चाहिए:

  • ROOT-DIRECTORY
    • MODULE
      • SUBMODULE (ज़रूरी नहीं, एक से ज़्यादा लेवल हो सकते हैं)
        • VERSION
          • Android.mk
          • IINTERFACE_1.hal
          • IINTERFACE_2.hal
          • …
          • IINTERFACE_N.hal
          • types.hal (वैकल्पिक)

जगह:

  • ROOT-DIRECTORY है:
    • hardware/interfaces का इस्तेमाल किया जाता है.
    • vendor/VENDOR/interfaces वेंडर पैकेज के लिए, जहां VENDOR का मतलब SoC वेंडर या OEM/ODM से है.
  • MODULE अंग्रेज़ी के छोटे अक्षरों में लिखा गया एक ऐसा शब्द होना चाहिए जो सबसिस्टम के बारे में बताता हो. उदाहरण के लिए, nfc. अगर एक से ज़्यादा शब्दों की ज़रूरत है, तो नेस्ट किए गए SUBMODULE का इस्तेमाल करें. नेस्टिंग के एक से ज़्यादा लेवल हो सकते हैं.
  • VERSION का वर्शन (मेजर.माइनर) वही होना चाहिए जो वर्शन में बताया गया है.
  • IINTERFACE_X, इंटरफ़ेस का नाम होना चाहिए. साथ ही, इसमें UpperCamelCase/PascalCase (उदाहरण के लिए, INfc) होना चाहिए. इसके बारे में इंटरफ़ेस के नाम में बताया गया है.

उदाहरण:

  • hardware/interfaces
    • nfc
      • 1.0
        • Android.mk
        • INfc.hal
        • INfcClientCallback.hal
        • types.hal

ध्यान दें: सभी फ़ाइलों के लिए, Git में नॉन-एक्ज़ीक्यूटेबल अनुमतियां होनी चाहिए.

पैकेज के नाम

पैकेज के नाम, पूरी तरह क्वालिफ़ाइड नाम (एफ़क्यूएन) के इस फ़ॉर्मैट (PACKAGE-NAME के तौर पर दिखाया गया) में होने चाहिए:

PACKAGE.MODULE[.SUBMODULE[.SUBMODULE[…]]]@VERSION

जगह:

  • PACKAGE वह पैकेज है जो ROOT-DIRECTORY पर मैप होता है. खास तौर पर, PACKAGE यह है:
    • कोर एचआईडीएल पैकेज के लिए android.hardware (hardware/interfaces पर मैपिंग).
    • vendor.VENDOR.hardware वेंडर पैकेज के लिए, जहां VENDOR से SoC वेंडर या OEM/ODM (vendor/VENDOR/interfaces से मैपिंग) का पता चलता है.
  • MODULE[.SUBMODULE[.SUBMODULE[…]]]@VERSION डायरेक्ट्री स्ट्रक्चर में बताए गए स्ट्रक्चर में फ़ोल्डर के नाम बिल्कुल एक जैसे हों.
  • पैकेज के नाम छोटे अक्षरों में होने चाहिए. अगर वे एक से ज़्यादा शब्दों के हैं, तो शब्दों को सबमॉड्यूल के तौर पर इस्तेमाल किया जाना चाहिए या snake_case में लिखा जाना चाहिए.
  • इसमें स्पेस नहीं होना चाहिए.

पैकेज के एलान में हमेशा FQN का इस्तेमाल किया जाता है.

वर्शन

वर्शन इस फ़ॉर्मैट में होने चाहिए: 

MAJOR.MINOR

MAJOR और MINOR, दोनों वर्शन एक ही पूर्णांक होने चाहिए. HIDL, सिमेंटिक वर्शनिंग के नियमों का इस्तेमाल करता है.

इंपोर्ट

इंपोर्ट किए गए डेटा को इन तीन फ़ॉर्मैट में से किसी एक में रखा जाता है:

  • पूरे पैकेज का इंपोर्ट: import PACKAGE-NAME;
  • आंशिक इंपोर्ट: import PACKAGE-NAME::UDT; (या, अगर इंपोर्ट किया गया टाइप एक ही पैकेज में है,तो import UDT;
  • सिर्फ़ टाइप इंपोर्ट करना: import PACKAGE-NAME::types;

PACKAGE-NAME, पैकेज के नामों में दिए गए फ़ॉर्मैट के मुताबिक होना चाहिए. मौजूदा पैकेज का types.hal (अगर मौजूद है) अपने-आप इंपोर्ट हो जाता है. इसे अलग से इंपोर्ट न करें.

पूरी तरह क्वालिफ़ाइड नाम (एफ़क्यूएन)

उपयोगकर्ता के तय किए गए टाइप को इंपोर्ट करने के लिए, पूरी तरह क्वालिफ़ाइड नामों का इस्तेमाल सिर्फ़ तब करें, जब ज़रूरी हो. अगर इंपोर्ट टाइप एक ही पैकेज में है, तो PACKAGE-NAME को शामिल न करें. एफ़क्यूएन में स्पेस नहीं होना चाहिए. पूरी तरह क्वालिफ़ाइड नाम का उदाहरण:

android.hardware.nfc@1.0::INfcClientCallback

android.hardware.nfc@1.0 में मौजूद किसी दूसरी फ़ाइल में, ऊपर दिए गए इंटरफ़ेस को INfcClientCallback के तौर पर देखें. इसके अलावा, सिर्फ़ पूरी तरह से क्वालिफ़ाइड नाम का इस्तेमाल करें.

इंपोर्ट को ग्रुप करना और क्रम से लगाना

पैकेज के बारे में जानकारी देने के बाद (इंपोर्ट से पहले) एक खाली लाइन का इस्तेमाल करें. हर इंपोर्ट को एक लाइन में लिखा जाना चाहिए और उसमें इंडेंट नहीं होना चाहिए. ग्रुप इंपोर्ट इस क्रम में किए जाते हैं:

  1. अन्य android.hardware पैकेज (पूरी तरह क्वालिफ़ाइड नामों का इस्तेमाल करें).
  2. अन्य vendor.VENDOR पैकेज (पूरी तरह क्वालिफ़ाइड नामों का इस्तेमाल करें).
    • हर वेंडर एक ग्रुप होना चाहिए.
    • वेंडर को वर्णमाला के क्रम में लगाएं.
  3. एक ही पैकेज में मौजूद अन्य इंटरफ़ेस से इंपोर्ट करता है (सामान्य नामों का इस्तेमाल करें).

ग्रुप के बीच एक खाली लाइन का इस्तेमाल करें. हर ग्रुप में, इंपोर्ट को वर्णमाला के क्रम में लगाएं. उदाहरण:

import android.hardware.nfc@1.0::INfc;
import android.hardware.nfc@1.0::INfcClientCallback;

/* Importing the whole module. */
import vendor.barvendor.bar@3.1;

import vendor.foovendor.foo@2.2::IFooBar;
import vendor.foovendor.foo@2.2::IFooFoo;

import IBar;
import IFoo;

इंटरफ़ेस के नाम

इंटरफ़ेस के नाम, I से शुरू होने चाहिए. इसके बाद, UpperCamelCase/PascalCase का नाम होना चाहिए. IFoo.hal फ़ाइल में, IFoo नाम वाला इंटरफ़ेस तय किया जाना चाहिए. इस फ़ाइल में, सिर्फ़ IFoo इंटरफ़ेस की परिभाषाएं शामिल हो सकती हैं. इंटरफ़ेस INAME, INAME.hal में होना चाहिए.

फ़ंक्शन

फ़ंक्शन के नाम, आर्ग्युमेंट, और रिटर्न वैरिएबल के नामों के लिए, lowerCamelCase का इस्तेमाल करें. उदाहरण:

open(INfcClientCallback clientCallback) generates (int32_t retVal);
oneway pingAlive(IFooCallback cb);

स्ट्रक्ट और यूनियन फ़ील्ड के नाम

स्ट्रक्ट या यूनियन फ़ील्ड के नामों के लिए, lowerCamelCase का इस्तेमाल करें. उदाहरण:

struct FooReply {
    vec<uint8_t> replyData;
}

नाम टाइप करें

टाइप के नाम, स्ट्रक्चर या यूनियन की परिभाषाओं, enum टाइप की परिभाषाओं, और typedefs के बारे में बताते हैं. इन नामों के लिए, UpperCamelCase/PascalCase का इस्तेमाल करें. उदाहरण:

enum NfcStatus : int32_t {
    /*...*/
};
struct NfcData {
    /*...*/
};

ईनम वैल्यू

इनम वैल्यू UPPER_CASE_WITH_UNDERSCORES होनी चाहिए. फ़ंक्शन के आर्ग्युमेंट के तौर पर enum वैल्यू पास करते समय और उन्हें फ़ंक्शन के रिटर्न के तौर पर दिखाते समय, enum टाइप का इस्तेमाल करें. इंटिजर टाइप का इस्तेमाल न करें. उदाहरण:

enum NfcStatus : int32_t {
    HAL_NFC_STATUS_OK               = 0,
    HAL_NFC_STATUS_FAILED           = 1,
    HAL_NFC_STATUS_ERR_TRANSPORT    = 2,
    HAL_NFC_STATUS_ERR_CMD_TIMEOUT  = 3,
    HAL_NFC_STATUS_REFUSED          = 4
};

ध्यान दें: किसी enum टाइप का बुनियादी टाइप, कोलन के बाद साफ़ तौर पर बताया जाता है. यह कंपाइलर पर निर्भर नहीं करता. इसलिए, असली enum टाइप का इस्तेमाल करना ज़्यादा सही है.

एनम वैल्यू के पूरी तरह क्वालिफ़ाइड नामों के लिए, एनम टाइप के नाम और एनम वैल्यू के नाम के बीच कोलन का इस्तेमाल किया जाता है:

PACKAGE-NAME::UDT[.UDT[.UDT[…]]:ENUM_VALUE_NAME

पूरी तरह क्वालिफ़ाइड नाम में स्पेस नहीं होना चाहिए. पूरी तरह क्वालिफ़ाइड नाम का इस्तेमाल सिर्फ़ तब करें, जब ज़रूरी हो. साथ ही, गैर-ज़रूरी हिस्सों को हटा दें. उदाहरण:

android.hardware.foo@1.0::IFoo.IFooInternal.FooEnum:ENUM_OK

टिप्पणियां

एक लाइन वाली टिप्पणी के लिए, //, /* */, और /** */ का इस्तेमाल किया जा सकता है.

// This is a single line comment
/* This is also single line comment */
/** This is documentation comment */
  • टिप्पणियों के लिए /* */ का इस्तेमाल करें. HIDL में टिप्पणियों के लिए // का इस्तेमाल किया जा सकता है. हालांकि, ऐसा न करने का सुझाव दिया जाता है, क्योंकि ये जनरेट किए गए आउटपुट में नहीं दिखती हैं.
  • जनरेट किए गए दस्तावेज़ के लिए, /** */ का इस्तेमाल करें. इन्हें सिर्फ़ टाइप, तरीके, फ़ील्ड, और enum वैल्यू के एलान पर लागू किया जा सकता है. उदाहरण: 
    /** Replied status */
enum TeleportStatus {
    /** Object entirely teleported. */
    OK              = 0,
    /** Methods return this if teleportation is not completed. */
    ERROR_TELEPORT  = 1,
    /**
     * Teleportation could not be completed due to an object
     * obstructing the path.
     */
    ERROR_OBJECT    = 2,
    ...
}
  • मल्टी-लाइन वाली टिप्पणियां शुरू करने के लिए, अलग लाइन में /** लिखें. हर लाइन की शुरुआत में * का इस्तेमाल करें. टिप्पणी के आखिर में, */ को अलग लाइन में डालें और तारांकों को अलाइन करें. उदाहरण: 
    /**
 * My multi-line
 * comment
 */
  • लाइसेंसिंग की सूचना और बदलावों की जानकारी, नई लाइन से शुरू होनी चाहिए. इसके लिए, /* (एक तारा) का इस्तेमाल करें. हर लाइन की शुरुआत में * का इस्तेमाल करें. साथ ही, आखिरी लाइन में सिर्फ़ */ लिखें (तारे एक लाइन में होने चाहिए). उदाहरण: 
    /*
 * Copyright (C) 2017 The Android Open Source Project
 * ...
 */

/*
 * Changelog:
 * ...
 */

फ़ाइल पर की गई टिप्पणियां

हर फ़ाइल की शुरुआत में, लाइसेंस के बारे में सही सूचना दें. कोर एचएएल के लिए, यह development/docs/copyright-templates/c.txt में AOSP Apache लाइसेंस होना चाहिए. साल अपडेट करना न भूलें. साथ ही, ऊपर बताए गए तरीके से /* */ स्टाइल वाले एक से ज़्यादा लाइनों वाले कमेंट का इस्तेमाल करें.

लाइसेंस की सूचना के बाद, एक खाली लाइन जोड़ी जा सकती है. इसके बाद, बदलाव का लॉग/वर्शन की जानकारी दी जा सकती है. ऊपर बताए गए तरीके से, /* */ स्टाइल वाले एक से ज़्यादा लाइनों वाले कमेंट का इस्तेमाल करें. बदलाव के बारे में जानकारी देने वाले लॉग के बाद खाली लाइन डालें. इसके बाद, पैकेज के बारे में जानकारी दें.

TODO टिप्पणियां

TODO में, अंग्रेज़ी के बड़े अक्षरों में TODO स्ट्रिंग के बाद कोलन शामिल होना चाहिए. उदाहरण:

// TODO: remove this code before foo is checked in.

TODO टिप्पणियों का इस्तेमाल सिर्फ़ डेवलपमेंट के दौरान किया जा सकता है. पब्लिश किए गए इंटरफ़ेस में इनका इस्तेमाल नहीं किया जाना चाहिए.

इंटरफ़ेस और फ़ंक्शन के बारे में टिप्पणियां (डॉकस्ट्रिंग)

एक से ज़्यादा लाइन और एक लाइन वाली docstring के लिए, /** */ का इस्तेमाल करें. डॉकस्ट्रिंग के लिए // का इस्तेमाल न करें.

इंटरफ़ेस के लिए डॉकस्ट्रिंग में, इंटरफ़ेस के सामान्य तरीकों, डिज़ाइन के तर्क, मकसद वगैरह के बारे में बताया जाना चाहिए. फ़ंक्शन के लिए डॉकस्ट्रिंग, फ़ंक्शन के हिसाब से होनी चाहिए. पैकेज-लेवल का दस्तावेज़, पैकेज डायरेक्ट्री में मौजूद README फ़ाइल में होता है.

/**
 * IFooController is the controller for foos.
 */
interface IFooController {
    /**
     * Opens the controller.
     *
     * @return status HAL_FOO_OK if successful.
     */
    open() generates (FooStatus status);

    /** Close the controller. */
    close();
};

आपको हर पैरामीटर/वापसी की वैल्यू के लिए @param और @return जोड़ने होंगे:

  • हर पैरामीटर के लिए @param जोड़ना ज़रूरी है. इसके बाद, पैरामीटर का नाम और फिर डॉकस्ट्रिंग होना चाहिए.
  • हर रिटर्न वैल्यू के लिए, @return को जोड़ना ज़रूरी है. इसके बाद, रिटर्न वैल्यू का नाम और फिर डॉकस्ट्रिंग होना चाहिए.

उदाहरण:

/**
 * Explain what foo does.
 *
 * @param arg1 explain what arg1 is
 * @param arg2 explain what arg2 is
 * @return ret1 explain what ret1 is
 * @return ret2 explain what ret2 is
 */
foo(T arg1, T arg2) generates (S ret1, S ret2);

फ़ॉर्मैटिंग के नियम

फ़ॉर्मैटिंग के सामान्य नियमों में ये शामिल हैं:

  • लाइन की लंबाई. टेक्स्ट की हर लाइन में ज़्यादा से ज़्यादा 100 कॉलम होने चाहिए.
  • व्हाइटस्पेस. लाइनों के आखिर में कोई व्हाइटस्पेस नहीं होना चाहिए. खाली लाइनों में व्हाइटस्पेस नहीं होना चाहिए.
  • स्पेस बनाम टैब. सिर्फ़ स्पेस का इस्तेमाल करें.
  • इंडेंट का साइज़. ब्लॉक के लिए 4 स्पेस और लाइन रैप के लिए 8 स्पेस का इस्तेमाल करें
  • ब्रैसिंग. एनोटेशन की वैल्यू को छोड़कर, ओपन ब्रेस, पहले वाले कोड की लाइन में ही होता है. हालांकि, क्लोज़ ब्रेस और उसके बाद का सेमीकोलन, पूरी लाइन में होता है. उदाहरण: 
    interface INfc {
    close();
};

पैकेज के एलान वाला फ़ॉर्म

पैकेज का एलान, लाइसेंस की सूचना के बाद फ़ाइल में सबसे ऊपर होना चाहिए. यह पूरी लाइन में होना चाहिए और इसमें इंडेंट नहीं होना चाहिए. पैकेज के नाम इस फ़ॉर्मैट में बताए जाते हैं. नाम के फ़ॉर्मैट के लिए, पैकेज के नाम देखें:

package PACKAGE-NAME;

उदाहरण:

package android.hardware.nfc@1.0;

फ़ंक्शन के एलान

अगर फ़ंक्शन का नाम, पैरामीटर, generates, और दिखाई गई वैल्यू एक ही लाइन में आ सकती हैं, तो उन्हें एक ही लाइन में होना चाहिए. उदाहरण:

interface IFoo {
    /** ... */
    easyMethod(int32_t data) generates (int32_t result);
};

अगर वे एक ही लाइन में फ़िट नहीं होते हैं, तो पैरामीटर और दिखाई गई वैल्यू को एक ही इंडेंट लेवल में रखें. साथ ही, generate को अलग से दिखाएं, ताकि पढ़ने वाले व्यक्ति को पैरामीटर और दिखाई गई वैल्यू तुरंत दिख सकें. उदाहरण:

interface IFoo {
    suchALongMethodThatCannotFitInOneLine(int32_t theFirstVeryLongParameter,
                                          int32_t anotherVeryLongParameter);
    anEvenLongerMethodThatCannotFitInOneLine(int32_t theFirstLongParameter,
                                             int32_t anotherVeryLongParameter)
                                  generates (int32_t theFirstReturnValue,
                                             int32_t anotherReturnValue);
    superSuperSuperSuperSuperSuperSuperLongMethodThatYouWillHateToType(
            int32_t theFirstVeryLongParameter, // 8 spaces
            int32_t anotherVeryLongParameter
        ) generates (
            int32_t theFirstReturnValue,
            int32_t anotherReturnValue
        );
    /* method name is even shorter than 'generates' */
    foobar(AReallyReallyLongType aReallyReallyLongParameter,
           AReallyReallyLongType anotherReallyReallyLongParameter)
        generates (ASuperLongType aSuperLongReturnValue, // 4 spaces
                   ASuperLongType anotherSuperLongReturnValue);
}

अतिरिक्त जानकारी:

  • खुला हुआ ब्रैकेट हमेशा फ़ंक्शन के नाम वाली लाइन में होता है.
  • फ़ंक्शन के नाम और ओपन पैरंटheses के बीच कोई स्पेस नहीं होना चाहिए.
  • ब्रैकेट और पैरामीटर के बीच कोई स्पेस नहीं होना चाहिए. सिर्फ़ तब स्पेस होना चाहिए, जब उनके बीच लाइन फ़ीड हों.
  • अगर generates, पिछले क्लोज़िंग पैरंटheses के साथ एक ही लाइन में है, तो पहले स्पेस का इस्तेमाल करें. अगर generates, अगले ओपन पैरंटheses के साथ एक ही लाइन में है, तो इसके बाद स्पेस जोड़ें.
  • सभी पैरामीटर और रिटर्न वैल्यू को अलाइन करें (अगर हो सके).
  • डिफ़ॉल्ट इंडेंटेशन चार स्पेस होता है.
  • रैप किए गए पैरामीटर, पिछली लाइन के पहले पैरामीटर के साथ अलाइन किए जाते हैं. अगर ऐसा नहीं होता है, तो उनमें आठ स्पेस का इंडेंट होता है.

टिप्पणियां

एनोटेशन के लिए, इस फ़ॉर्मैट का इस्तेमाल करें:

@annotate(keyword = value, keyword = {value, value, value})

एनोटेशन को वर्णमाला के क्रम में लगाएं. साथ ही, बराबर के निशान के आस-पास स्पेस का इस्तेमाल करें. उदाहरण:

@callflow(key = value)
@entry
@exit

पक्का करें कि एनोटेशन पूरी लाइन में हो. उदाहरण:

/* Good */
@entry
@exit

/* Bad */
@entry @exit

अगर एनोटेशन एक ही लाइन में नहीं आ सकते, तो आठ स्पेस का इंडेंटेशन करें. उदाहरण:

@annotate(
        keyword = value,
        keyword = {
                value,
                value
        },
        keyword = value)

अगर वैल्यू का पूरा कलेक्शन एक ही लाइन में नहीं आ सकता, तो ओपन ब्रेसिज़ { के बाद और कलेक्शन में मौजूद हर कॉमा के बाद लाइन ब्रेक डालें. आखिरी वैल्यू के तुरंत बाद क्लोज़िंग ब्रैकेट लगाएं. अगर सिर्फ़ एक वैल्यू है, तो ब्रेसिज़ न लगाएं.

अगर वैल्यू की पूरी ऐरे एक ही लाइन में फ़िट हो सकती है, तो ओपन ब्रेसिज़ के बाद और क्लोज़िंग ब्रेसिज़ से पहले स्पेस का इस्तेमाल न करें. साथ ही, हर कॉमा के बाद एक स्पेस का इस्तेमाल करें. उदाहरण:

/* Good */
@callflow(key = {"val", "val"})

/* Bad */
@callflow(key = { "val","val" })

एनोटेशन और फ़ंक्शन के एलान के बीच कोई खाली लाइन नहीं होनी चाहिए. उदाहरण:

/* Good */
@entry
foo();

/* Bad */
@entry

foo();

Enum के एलान

इनम के एलान के लिए, इन नियमों का इस्तेमाल करें:

  • अगर enum के एलान किसी दूसरे पैकेज के साथ शेयर किए जाते हैं, तो एलान को इंटरफ़ेस में एम्बेड करने के बजाय, types.hal में रखें.
  • कोलन से पहले और बाद में एक स्पेस का इस्तेमाल करें. साथ ही, ओपन ब्रेस से पहले, अंडरलाइंग टाइप के बाद एक स्पेस का इस्तेमाल करें.
  • आखिरी इनम वैल्यू में अतिरिक्त कॉमा नहीं होना चाहिए.

स्ट्रक्चर के एलान

स्ट्रक्ट के एलान के लिए, इन नियमों का पालन करें:

  • अगर स्ट्रक्चर के एलान किसी दूसरे पैकेज के साथ शेयर किए जाते हैं, तो एलान को इंटरफ़ेस में एम्बेड करने के बजाय, types.hal में रखें.
  • ओपन ब्रेस से पहले, स्ट्रक्चर टाइप के नाम के बाद स्पेस का इस्तेमाल करें.
  • फ़ील्ड के नामों को अलाइन करें (ज़रूरी नहीं). उदाहरण: 
    struct MyStruct {
    vec<uint8_t>   data;
    int32_t        someInt;
}

ऐरे के एलान

इनके बीच स्पेस न डालें:

  • एलिमेंट टाइप और ओपन स्क्वेयर ब्रैकेट.
  • ओपन स्क्वेयर ब्रैकेट और ऐरे का साइज़.
  • ऐरे का साइज़ और क्लोज़ स्क्वेयर ब्रैकेट.
  • क्लोज़ स्क्वेयर ब्रैकेट और अगला ओपन स्क्वेयर ब्रैकेट, अगर एक से ज़्यादा डाइमेंशन मौजूद हैं.

उदाहरण:

/* Good */
int32_t[5] array;

/* Good */
int32_t[5][6] multiDimArray;

/* Bad */
int32_t [ 5 ] [ 6 ] array;

वेक्टर

इनके बीच स्पेस न डालें:

  • vec और ओपन ऐंगल ब्रैकेट.
  • ओपन ऐंगल ब्रैकेट और एलिमेंट टाइप (अपवाद: एलिमेंट टाइप भी a vec है).
  • तत्व का टाइप और क्लोज़ ऐंगल ब्रैकेट (अपवाद: एलिमेंट का टाइप भी vec है).

उदाहरण:

/* Good */
vec<int32_t> array;

/* Good */
vec<vec<int32_t>> array;

/* Good */
vec< vec<int32_t> > array;

/* Bad */
vec < int32_t > array;

/* Bad */
vec < vec < int32_t > > array;