কোড স্টাইল গাইড

HIDL কোড শৈলী 4-স্পেস ইন্ডেন্ট এবং মিশ্র-কেস ফাইলের নাম সহ Android ফ্রেমওয়ার্কের 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;
};

নামকরণ অনুষ্ঠান

ফাংশনের নাম, পরিবর্তনশীল নাম এবং ফাইলের নাম বর্ণনামূলক হওয়া উচিত; অতিরিক্ত সংক্ষিপ্তকরণ এড়িয়ে চলুন। সংক্ষিপ্ত শব্দগুলিকে শব্দ হিসাবে বিবেচনা করুন (যেমন, 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 সংস্করণে বর্ণিত একই সংস্করণ (major.minor) হওয়া উচিত।
  • 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. 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);

কাঠামো/ইউনিয়ন ক্ষেত্রের নাম

struct/ইউনিয়ন ক্ষেত্রের নামের জন্য, lowerCamelCase ব্যবহার করুন। উদাহরণ:

struct FooReply {
    vec<uint8_t> replyData;
}

নাম টাইপ করুন

টাইপ নামগুলি স্ট্রাকট/ইউনিয়ন সংজ্ঞা, এনাম টাইপ সংজ্ঞা এবং typedef এসকে উল্লেখ করে। এই নামের জন্য, UpperCamelCase / PascalCase ব্যবহার করুন। উদাহরণ:

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

এনাম মান

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-এর জন্য, এটি development/docs/copyright-templates/c.txt এ AOSP Apache লাইসেন্স হওয়া উচিত। বছর আপডেট করতে মনে রাখবেন এবং /* */ শৈলী মাল্টি-লাইন মন্তব্যগুলি উপরে ব্যাখ্যা করা হয়েছে।

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

TODO মন্তব্য

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 s এবং @return s যোগ করতে হবে:

  • @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);
}

অতিরিক্ত তথ্য:

  • একটি খোলা বন্ধনী সর্বদা ফাংশনের নামের মতো একই লাইনে থাকে।
  • ফাংশনের নাম এবং খোলা বন্ধনীর মধ্যে কোনো স্পেস নেই।
  • বন্ধনী এবং পরামিতিগুলির মধ্যে কোন ফাঁকা নেই যখন তাদের মধ্যে লাইন ফিড থাকে।
  • যদি 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)

যদি পুরো মান অ্যারে একই লাইনে ফিট করতে না পারে, তাহলে খোলা ধনুর্বন্ধনী { এবং অ্যারের ভিতরে প্রতিটি কমা পরে লাইন বিরতি দিন। শেষ মানের পরে অবিলম্বে বন্ধ বন্ধনী রাখুন। শুধুমাত্র একটি মান থাকলে ধনুর্বন্ধনী লাগাবেন না।

যদি পুরো মান অ্যারে একই লাইনে ফিট করতে পারে, তাহলে খোলা ধনুর্বন্ধনীর পরে এবং বন্ধনী বন্ধ করার আগে স্পেস ব্যবহার করবেন না এবং প্রতিটি কমা পরে একটি স্পেস ব্যবহার করবেন। উদাহরণ:

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