คู่มือแนะนำเกี่ยวกับรูปแบบโค้ด

รูปแบบโค้ด HIDL คล้ายกับโค้ด C++ ในเฟรมเวิร์ก Android โดยมีการเยื้อง 4 เว้นวรรคและชื่อไฟล์แบบผสม การประกาศแพ็กเกจ การนําเข้า และสตริงเอกสารมีลักษณะคล้ายกับใน 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 (ไม่บังคับ อาจมีได้มากกว่า 1 ระดับ)
        • VERSION
          • Android.mk
          • IINTERFACE_1.hal
          • IINTERFACE_2.hal
          • …
          • IINTERFACE_N.hal
          • types.hal (ไม่บังคับ)

สถานที่:

  • ROOT-DIRECTORY คือ
    • hardware/interfaces สำหรับแพ็กเกจ HIDL หลัก
    • vendor/VENDOR/interfaces สำหรับแพ็กเกจของผู้ให้บริการ โดยที่ VENDOR หมายถึงผู้ให้บริการ SoC หรือ OEM/ODM
  • MODULE ควรเป็นคำตัวพิมพ์เล็ก 1 คำที่อธิบายถึงระบบย่อย (เช่น nfc) หากต้องใช้มากกว่า 1 คำ ให้ใช้ SUBMODULE ที่ฝังอยู่ การฝังอาจมีได้มากกว่า 1 ระดับ
  • VERSION ควรเป็นเวอร์ชันเดียวกันทุกประการ (major.minor) ตามที่อธิบายไว้ในเวอร์ชัน
  • IINTERFACE_X ควรเป็นชื่ออินเทอร์เฟซที่มี UpperCamelCase/PascalCase (เช่น INfc) ตามที่อธิบายไว้ในชื่ออินเทอร์เฟซ

ตัวอย่าง

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

หมายเหตุ: ไฟล์ทั้งหมดต้องมีสิทธิ์ที่ไม่สามารถเรียกใช้ได้ (ใน Git)

ชื่อแพ็กเกจ

ชื่อแพ็กเกจต้องใช้รูปแบบชื่อที่สมบูรณ์ในตัวเอง (FQN) ต่อไปนี้ (เรียกว่า PACKAGE-NAME)

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

สถานที่:

  • PACKAGE คือแพ็กเกจที่แมปกับ ROOT-DIRECTORY โดยเฉพาะอย่างยิ่ง PACKAGE มีคุณสมบัติดังนี้
    • android.hardware สำหรับแพ็กเกจ HIDL หลัก (การแมปกับ hardware/interfaces)
    • vendor.VENDOR.hardware สำหรับแพ็กเกจของผู้ให้บริการ โดยที่ VENDOR หมายถึงผู้ให้บริการ SoC หรือ OEM/ODM (แมปกับ vendor/VENDOR/interfaces)
  • MODULE[.SUBMODULE[.SUBMODULE[…]]]@VERSION เป็นชื่อโฟลเดอร์เดียวกันทุกประการในโครงสร้างที่อธิบายไว้ในโครงสร้างไดเรกทอรี
  • ชื่อแพ็กเกจควรเป็นตัวพิมพ์เล็ก หากมีความยาวมากกว่า 1 คำ ควรใช้คำดังกล่าวเป็นโมดูลย่อยหรือเขียนเป็น 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ของแพ็กเกจปัจจุบัน (หากมี) โดยอัตโนมัติ (อย่านำเข้าtypes.halดังกล่าวโดยชัดแจ้ง)

ชื่อที่สมบูรณ์ในตัวเอง (FQN)

ใช้ชื่อที่สมบูรณ์ในตัวเองสำหรับการนําเข้าประเภทที่ผู้ใช้กําหนดเมื่อจําเป็นเท่านั้น ละเว้น PACKAGE-NAME หากประเภทการนําเข้าอยู่ในแพ็กเกจเดียวกัน FQN ต้องไม่มีการเว้นวรรค ตัวอย่างชื่อที่สมบูรณ์ในตัวเอง

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 ในไฟล์ IFoo.hal ไฟล์นี้ต้องมีคำจำกัดความสำหรับอินเทอร์เฟซ IFoo เท่านั้น (อินเทอร์เฟซ INAME ควรอยู่ใน INAME.hal )

ฟังก์ชัน

สําหรับชื่อฟังก์ชัน อาร์กิวเมนต์ และชื่อตัวแปรที่แสดงผล ให้ใช้ lowerCamelCase ตัวอย่าง

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

ชื่อฟิลด์ Struct และ Union

สำหรับชื่อช่อง struct หรือ union ให้ใช้ lowerCamelCase ตัวอย่าง

struct FooReply {
    vec<uint8_t> replyData;
}

ชื่อประเภท

ชื่อประเภทหมายถึงคําจํากัดความของโครงสร้างหรือยูเนียน คําจํากัดความประเภท enum และ typedef สำหรับชื่อเหล่านี้ ให้ใช้ UpperCamelCase/PascalCase ตัวอย่างเช่น

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

ค่า enum

ค่า Enum ควรเป็น 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 จริงจึงชัดเจนกว่า

สำหรับชื่อแบบเต็มที่สมบูรณ์ของค่า enum ระบบจะใช้โคลอนระหว่างชื่อประเภท 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:
 * ...
 */

แสดงความคิดเห็น

เริ่มต้นไฟล์แต่ละไฟล์ด้วยประกาศการอนุญาตให้ใช้สิทธิที่เหมาะสม สำหรับ HAL หลัก ไฟล์นี้ควรเป็นใบอนุญาต Apache ของ AOSP ใน development/docs/copyright-templates/c.txt อย่าลืมอัปเดตปีและใช้ความคิดเห็นแบบหลายบรรทัดสไตล์ /* */ ตามที่อธิบายไว้ข้างต้น

คุณอาจใส่บรรทัดว่างไว้หลังประกาศเกี่ยวกับใบอนุญาต แล้วตามด้วยข้อมูลบันทึกการเปลี่ยนแปลง/การกำหนดเวอร์ชันก็ได้ ใช้ความคิดเห็นแบบหลายบรรทัดสไตล์ /* */ ตามที่อธิบายไว้ข้างต้น ใส่บรรทัดว่างไว้หลังบันทึกการเปลี่ยนแปลง แล้วตามด้วยการประกาศแพ็กเกจ

ความคิดเห็น TODO

TODO ควรมีสตริง TODO ตัวพิมพ์ใหญ่ทั้งหมดตามด้วยโคลอน ตัวอย่าง

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

อนุญาตให้ใส่ความคิดเห็น TODO ในระหว่างการพัฒนาเท่านั้น โดยต้องไม่มีความคิดเห็น TODO ในอินเทอร์เฟซที่เผยแพร่

ความคิดเห็นเกี่ยวกับอินเทอร์เฟซและฟังก์ชัน (สตริงเอกสารประกอบ)

ใช้ /** */ สำหรับสตริงเอกสารแบบหลายบรรทัดและแบบบรรทัดเดียว อย่าใช้ // สำหรับสตริงเอกสาร

สตริงเอกสารสำหรับอินเทอร์เฟซควรอธิบายกลไกทั่วไปของอินเทอร์เฟซ เหตุผลการออกแบบ วัตถุประสงค์ ฯลฯ สตริงเอกสารสำหรับฟังก์ชันควรอธิบายเฉพาะฟังก์ชันนั้นๆ (เอกสารประกอบระดับแพ็กเกจจะอยู่ในไฟล์ 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 สําหรับพารามิเตอร์แต่ละรายการ โดยควรตามด้วยชื่อพารามิเตอร์แล้วตามด้วย docstring
  • คุณต้องเพิ่ม @return สำหรับผลลัพธ์แต่ละรายการ ตามด้วยชื่อของผลลัพธ์แล้วตามด้วย docstring

ตัวอย่าง

/**
 * 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);
}

รายละเอียดเพิ่มเติม:

  • เครื่องหมายวงเล็บเปิดจะอยู่บรรทัดเดียวกับชื่อฟังก์ชันเสมอ
  • ไม่มีเว้นวรรคระหว่างชื่อฟังก์ชันกับวงเล็บเปิด
  • ไม่มีเว้นวรรคระหว่างวงเล็บกับพารามิเตอร์ ยกเว้นเมื่อมีบรรทัดแบ่งระหว่างกัน
  • หาก generates อยู่ในบรรทัดเดียวกับวงเล็บปิดก่อนหน้า ให้เว้นวรรคก่อน หาก generates อยู่ในบรรทัดเดียวกับวงเล็บเปิดถัดไป ให้เว้นวรรคตาม
  • จัดแนวพารามิเตอร์และค่าผลลัพธ์ทั้งหมด (หากเป็นไปได้)
  • การเยื้องเริ่มต้นคือ 4 วรรค
  • พารามิเตอร์ที่ตัดขึ้นบรรทัดใหม่จะจัดแนวกับพารามิเตอร์แรกในบรรทัดก่อนหน้า หรือจะเยื้อง 8 เว้นวรรคก็ได้

คำอธิบายประกอบ

ใช้รูปแบบต่อไปนี้สำหรับคำอธิบายประกอบ

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

จัดเรียงคำอธิบายประกอบตามลําดับตัวอักษร และใช้การเว้นวรรครอบเครื่องหมายเท่ากับ ตัวอย่าง

@callflow(key = value)
@entry
@exit

ตรวจสอบว่าคำอธิบายประกอบอยู่เต็มบรรทัด ตัวอย่าง

/* Good */
@entry
@exit

/* Bad */
@entry @exit

หากคำอธิบายประกอบไม่พอในบรรทัดเดียวกัน ให้เยื้องด้วยเว้นวรรค 8 ช่อง ตัวอย่าง

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

หากอาร์เรย์ค่าทั้งหมดไม่พอที่จะใส่ในบรรทัดเดียวกัน ให้ใส่การแบ่งบรรทัดหลังวงเล็บเปิด { และหลังคอมมาแต่ละตัวในอาร์เรย์ วางวงเล็บปิดไว้หลังค่าสุดท้าย อย่าใส่วงเล็บปีกกาหากมีเพียงค่าเดียว

หากอาร์เรย์ค่าทั้งหมดใส่ในบรรทัดเดียวกันได้ โปรดอย่าเว้นวรรคหลังวงเล็บเปิดและก่อนวงเล็บปิด และใช้การเว้นวรรค 1 ครั้งหลังเครื่องหมายคอมมาแต่ละตัว ตัวอย่าง

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

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

ต้องไม่มีบรรทัดว่างระหว่างคําอธิบายประกอบกับประกาศฟังก์ชัน ตัวอย่าง

/* Good */
@entry
foo();

/* Bad */
@entry

foo();

การประกาศ enum

ใช้กฎต่อไปนี้สำหรับการประกาศ enum

  • หากมีการแชร์การประกาศ enum กับแพ็กเกจอื่น ให้ใส่การประกาศใน types.hal แทนการฝังไว้ในอินเทอร์เฟซ
  • เว้นวรรคก่อนและหลังโคลอน และเว้นวรรคหลังประเภทพื้นฐานก่อนวงเล็บเปิด
  • ค่า enum สุดท้ายอาจไม่มีคอมมาเกิน

การประกาศ Struct

ใช้กฎต่อไปนี้สำหรับการประกาศ Struct

  • หากมีการแชร์การประกาศ Struct กับแพ็กเกจอื่น ให้ใส่การประกาศใน types.hal แทนการฝังไว้ในอินเทอร์เฟซ
  • ใช้เว้นวรรคหลังชื่อประเภทโครงสร้างก่อนวงเล็บเปิด
  • จัดแนวชื่อช่อง (ไม่บังคับ) ตัวอย่าง 
    struct MyStruct {
    vec<uint8_t>   data;
    int32_t        someInt;
}

การประกาศอาร์เรย์

อย่าเว้นวรรคระหว่างรายการต่อไปนี้

  • ประเภทองค์ประกอบและวงเล็บเหลี่ยมเปิด
  • วงเล็บเหลี่ยมเปิดและขนาดอาร์เรย์
  • ขนาดอาร์เรย์และวงเล็บเหลี่ยมปิด
  • เครื่องหมายวงเล็บเหลี่ยมปิดและเครื่องหมายวงเล็บเหลี่ยมเปิดถัดไป หากมีมิติข้อมูลมากกว่า 1 รายการ

ตัวอย่าง

/* Good */
int32_t[5] array;

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

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

เวกเตอร์

อย่าเว้นวรรคระหว่างรายการต่อไปนี้

  • vec และวงเล็บสามเหลี่ยมเปิด
  • วงเล็บสามเหลี่ยมเปิดและประเภทองค์ประกอบ (ข้อยกเว้น: ประเภทองค์ประกอบเป็น 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;