কোড শৈলী গাইড

অ্যান্ড্রয়েড ফ্রেমওয়ার্কে HIDL কোড স্টাইলটি C++ কোডের মতো, যেখানে ৪-স্পেস ইন্ডেন্ট এবং মিশ্র-কেস ফাইলের নাম ব্যবহৃত হয়। প্যাকেজ ডিক্লারেশন, ইমপোর্ট এবং ডকস্ট্রিংগুলো সামান্য কিছু পরিবর্তনসহ জাভার মতোই।

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

নামকরণের নিয়মাবলী

ফাংশনের নাম, ভেরিয়েবলের নাম এবং ফাইলের নাম বর্ণনামূলক হওয়া উচিত; অতিরিক্ত সংক্ষিপ্তকরণ পরিহার করুন। সংক্ষিপ্ত রূপকে (acronym) শব্দ হিসেবে গণ্য করুন (উদাহরণস্বরূপ, INFC এর পরিবর্তে INfc ব্যবহার করুন)।

ডিরেক্টরি কাঠামো এবং ফাইলের নামকরণ

ডিরেক্টরি কাঠামোটি নিম্নরূপ হওয়া উচিত:

  • ROOT-DIRECTORY
    • MODULE
      • SUBMODULE (ঐচ্ছিক, একাধিক স্তর থাকতে পারে)
        • VERSION
          • Android.mk
          • I INTERFACE_1 .hal
          • I INTERFACE_2 .hal
          • …
          • I INTERFACE_N .hal
          • types.hal (ঐচ্ছিক)

কোথায়:

  • ROOT-DIRECTORY হলো:
    • কোর HIDL প্যাকেজগুলোর জন্য hardware/interfaces ।
    • vendor/ VENDOR /interfaces , যেখানে VENDOR বলতে একজন SoC ভেন্ডর বা একজন OEM/ODM-কে বোঝায়।
  • MODULE একটি ছোট হাতের অক্ষরের শব্দ হবে যা সাবসিস্টেমটির বর্ণনা দেয় (উদাহরণস্বরূপ, nfc )। যদি একাধিক শব্দের প্রয়োজন হয়, তবে নেস্টেড SUBMODULE ব্যবহার করুন। এখানে একাধিক স্তরের নেস্টিং থাকতে পারে।
  • VERSION অবশ্যই ভার্সনস -এ বর্ণিত ভার্সনের (মেজর.মাইনর) হুবহু অনুরূপ হতে হবে।
  • I INTERFACE_X হলো ইন্টারফেসের নাম যা ইন্টারফেসের নাম অংশে বর্ণিত অনুযায়ী UpperCamelCase / PascalCase (উদাহরণস্বরূপ, INfc ) অক্ষরে বিন্যস্ত থাকতে হবে।

উদাহরণ:

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

দ্রষ্টব্য: সমস্ত ফাইলের অবশ্যই নন-এক্সিকিউটেবল পারমিশন থাকতে হবে (গিট-এ)।

প্যাকেজের নাম

প্যাকেজের নাম অবশ্যই নিম্নলিখিত পূর্ণ-যোগ্য নাম (FQN) বিন্যাসে লিখতে হবে (যা PACKAGE-NAME নামে পরিচিত):

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

কোথায়:

  • PACKAGE হলো সেই প্যাকেজ যা ROOT-DIRECTORY কে ম্যাপ করে। বিশেষত, PACKAGE হলো:
    • কোর HIDL প্যাকেজগুলির জন্য 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 (যদি থাকে) স্বয়ংক্রিয়ভাবে ইম্পোর্ট করা হয় (এটি আলাদাভাবে ইম্পোর্ট করার প্রয়োজন নেই)।

সম্পূর্ণ যোগ্য নাম (FQNs)

ব্যবহারকারী-সংজ্ঞায়িত টাইপ ইম্পোর্টের জন্য শুধুমাত্র প্রয়োজন হলেই সম্পূর্ণ যোগ্য নাম ব্যবহার করুন। যদি ইম্পোর্ট টাইপটি একই প্যাকেজে থাকে তবে 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 ইন্টারফেসের সংজ্ঞা থাকতে পারে ( I NAME ইন্টারফেসটি I NAME .hal ফাইলে থাকা উচিত)।

কার্যাবলী

ফাংশনের নাম, আর্গুমেন্ট এবং রিটার্ন ভেরিয়েবলের নামের ক্ষেত্রে lowerCamelCase ব্যবহার করুন। উদাহরণ:

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

স্ট্রাক্ট এবং ইউনিয়ন ফিল্ডের নাম

স্ট্রাক্ট বা ইউনিয়ন ফিল্ডের নামের ক্ষেত্রে lowerCamelCase ) ব্যবহার করুন। উদাহরণ:

struct FooReply {
    vec<uint8_t> replyData;
}

নাম টাইপ করুন

টাইপের নাম বলতে struct বা union ডেফিনিশন, 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 মন্তব্যের জন্য // সমর্থন করে, তবুও এর ব্যবহার নিরুৎসাহিত করা হয়, কারণ এগুলো তৈরি হওয়া আউটপুটে দেখা যায় না।
  • জেনারেটেড ডকুমেন্টেশনের জন্য /** */ ব্যবহার করুন। এগুলো শুধুমাত্র টাইপ, মেথড, ফিল্ড এবং এনাম ভ্যালু ডিক্লারেশনের ক্ষেত্রে প্রয়োগ করা যায়। উদাহরণ: 
    /** 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-এর জন্য, এটি development/docs/copyright-templates/c.txt ফাইলে থাকা AOSP Apache লাইসেন্স হওয়া উচিত। বছরটি আপডেট করতে এবং উপরে বর্ণিত /* */ স্টাইলের মাল্টি-লাইন কমেন্ট ব্যবহার করতে মনে রাখবেন।

আপনি চাইলে লাইসেন্স নোটিশের পরে একটি খালি লাইন রাখতে পারেন, এবং তারপরে চেঞ্জলগ/ভার্সনিং তথ্য দিতে পারেন। উপরে বর্ণিত পদ্ধতি অনুযায়ী /* */ স্টাইলের মাল্টি-লাইন কমেন্ট ব্যবহার করুন, চেঞ্জলগের পরে খালি লাইনটি রাখুন এবং তারপরে প্যাকেজ ডিক্লারেশনটি দিন।

করণীয় মন্তব্য

TODO-তে অবশ্যই বড় হাতের অক্ষরে TODO শব্দটি লিখতে হবে এবং তারপরে একটি কোলন দিতে হবে। উদাহরণ: 

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

শুধুমাত্র ডেভেলপমেন্ট পর্যায়ে 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 অবশ্যই যোগ করতে হবে। এর পরে প্যারামিটারের নাম এবং তারপরে ডকস্ট্রিং দিতে হবে।
  • প্রতিটি রিটার্ন ভ্যালুর জন্য @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);

বিন্যাস নিয়মাবলী

সাধারণ বিন্যাস নিয়মাবলীর মধ্যে রয়েছে:

  • লাইনের দৈর্ঘ্য । প্রতিটি টেক্সট লাইন সর্বাধিক ১০০ কলাম দীর্ঘ হতে হবে।
  • লাইনের শেষে কোনো ফাঁকা স্থান রাখা যাবে না; খালি লাইনেও কোনো ফাঁকা স্থান থাকা যাবে না।
  • স্পেস বনাম ট্যাব । শুধু স্পেস ব্যবহার করুন।
  • ইন্ডেন্ট সাইজ । ব্লকের জন্য ৪ স্পেস এবং লাইন র‍্যাপের জন্য ৮ স্পেস ব্যবহার করুন।
  • বন্ধনী । অ্যানোটেশন মান ব্যতীত, একটি খোলা বন্ধনী তার পূর্ববর্তী কোডের সাথে একই লাইনে বসে, কিন্তু একটি বন্ধ বন্ধনী এবং তার পরের সেমিকোলন পুরো লাইনটি জুড়ে থাকে। উদাহরণ: 
    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 পরবর্তী খোলা বন্ধনীর সাথে একই লাইনে থাকে, তাহলে তার পরে একটি স্পেস দিন।
  • সমস্ত প্যারামিটার এবং রিটার্ন মান সারিবদ্ধ করুন (যদি সম্ভব হয়)।
  • ডিফল্ট ইন্ডেন্টেশন হলো ৪ স্পেস।
  • র‍্যাপ করা প্যারামিটারগুলো পূর্ববর্তী লাইনের প্রথম প্যারামিটারের সাথে সারিবদ্ধ থাকে, অন্যথায় সেগুলোতে ৮-স্পেসের ইন্ডেন্ট থাকে।

টীকা

টীকা লেখার জন্য নিম্নলিখিত বিন্যাসটি ব্যবহার করুন: 

@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 ঘোষণার জন্য নিম্নলিখিত নিয়মগুলি ব্যবহার করুন:

  • যদি enum ডিক্লারেশনগুলো অন্য কোনো প্যাকেজের সাথে শেয়ার করা হয়, তাহলে ডিক্লারেশনগুলো কোনো ইন্টারফেসের ভেতরে এমবেড না করে types.hal এ রাখুন।
  • কোলনের আগে ও পরে একটি স্পেস দিন এবং খোলা বন্ধনীর আগে তার নিচের লেখার পরে একটি স্পেস দিন।
  • শেষ enum ভ্যালুটিতে অতিরিক্ত কমা নাও থাকতে পারে।

কাঠামোগত ঘোষণা

স্ট্রাক্ট ঘোষণার জন্য নিম্নলিখিত নিয়মগুলি ব্যবহার করুন:

  • যদি struct ডিক্লারেশনগুলো অন্য কোনো প্যাকেজের সাথে শেয়ার করা হয়, তাহলে ডিক্লারেশনগুলো কোনো ইন্টারফেসের ভেতরে এমবেড না করে types.hal এ রাখুন।
  • খোলা বন্ধনীর আগে struct টাইপের নামের পরে একটি স্পেস ব্যবহার করুন।
  • ফিল্ডের নামগুলো সারিবদ্ধ করুন (ঐচ্ছিক)। উদাহরণ: 
    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 এবং খোলা কোণ বন্ধনী।
  • খোলা অ্যাঙ্গেল ব্র্যাকেট এবং এলিমেন্ট টাইপ ( ব্যতিক্রম: এলিমেন্ট টাইপটি যদি একটি 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;