নামকরণ বিরোধগুলি এড়ানো সি প্রকল্প


13

আমি মাঝারি আকারের সি লাইব্রেরী প্রকল্পের জন্য ফাংশন নামকরণের কনভেনশন সম্পর্কে বাস্তববাদী বাস্তব-বিশ্বের পরামর্শ সন্ধানের জন্য সংগ্রাম করছি। আমার লাইব্রেরি প্রকল্পটি তাদের নিজস্ব শিরোনাম সহ কয়েকটি মডিউল এবং সাবমডিউলগুলিতে পৃথক করা হয়েছে এবং শিথিলভাবে একটি ওও স্টাইল অনুসরণ করে (সমস্ত ফাংশন একটি নির্দিষ্ট কাঠামোকে প্রথম যুক্তি হিসাবে চিহ্নিত করে, কোনও গ্লোবাল ইত্যাদি)। এটি আমাদের মতো কিছু রাখে:

MyLib
  - Foo
    - foo.h
    - foo_internal.h
    - some_foo_action.c
    - another_foo_action.c
    - Baz
      - baz.h
      - some_baz_action.c
  - Bar
    - bar.h
    - bar_internal.h
    - some_bar_action.c

সাধারণত ফাংশনগুলি স্টিকের তুলনায় অনেক বড় (উদাহরণস্বরূপ) স্টিক some_foo_actionএবং another_foo_actionএকটি foo.cবাস্তবায়ন ফাইলে, বেশিরভাগ ফাংশনকে স্থির করে তোলে এবং এটিকে একটি দিন বলে।

গ্রাহকগণের তাদের ক্লায়েন্ট প্রোগ্রামগুলির সাথে দ্বন্দ্ব এড়ানোর জন্য গ্রন্থাগারটি তৈরি করার সময় আমি আমার অভ্যন্তরীণ ("মডিউল প্রাইভেট") চিহ্নগুলি ছিনিয়ে নেওয়ার বিষয়ে ডিল করতে পারি, তবে প্রশ্নটি কীভাবে আমার লাইব্রেরিতে চিহ্নগুলির নাম রাখা যায়? এখনও পর্যন্ত আমি করছি:

struct MyLibFoo;
void MyLibFooSomeAction(MyLibFoo *foo, ...);

struct MyLibBar;
void MyLibBarAnAction(MyLibBar *bar, ...);

// Submodule
struct MyLibFooBaz;
void MyLibFooBazAnotherAction(MyLibFooBaz *baz, ...);

তবে আমি পাগল দীর্ঘ প্রতীক নামগুলি (উদাহরণগুলির চেয়ে অনেক দীর্ঘ) দিয়ে শেষ করছি। যদি আমি "জাল নেমস্পেস" দিয়ে নামগুলি উপস্থাপন না করি তবে মডিউলগুলির অভ্যন্তরীণ প্রতীকগুলির নামগুলি সংঘর্ষে লিপ্ত।

দ্রষ্টব্য: আমি ক্যামেলকেস / প্যাসকাল কেস ইত্যাদির জন্য, কেবল নিজের নামগুলিই যত্ন করি না।

উত্তর:


10

উপসর্গ (ভাল, affixing) সত্যিই একমাত্র বিকল্প। আপনি দেখতে পাবেন এমন কিছু নিদর্শনগুলি <library>_<name>হ'ল (উদাঃ ওপেনজিএল, ওবিজেসি রানটাইম), <module/class>_<name>(যেমন লিনাক্সের অংশ), <library>_<module/class>_<name>(যেমন, জিটিকে +)। আপনার স্কিম পুরোপুরি যুক্তিসঙ্গত।

পূর্বাভাসযোগ্য হলে লম্বা নামগুলি অগত্যা খারাপ হয় না। আপনি একক উত্স ফাইলে সম্পর্কিত ফাংশনগুলির সাথে আঁকতে খুব বড় আকারের ক্রেজি দীর্ঘ নাম এবং ফাংশনগুলি শেষ করছেন তা বিভিন্ন উদ্বেগ উত্থাপন করে। আপনার কি আরও কিছু দৃ concrete় উদাহরণ রয়েছে?


আমি দেখতে পাচ্ছি আপনি কোথা থেকে আসছেন - আমি ভাবলাম যে আমি আলাদা ফাইলগুলিতে বিভক্ত হওয়ার বিষয়ে খুব বেশি প্যাডেন্টিক হচ্ছি কিনা, তবে এটি পঠনযোগ্যতা, রক্ষণাবেক্ষণ এবং git mergeআইএনজি-তে অনেক সাহায্য করে । উদাহরণস্বরূপ আমি যেমন OpenGL সঙ্গে UI 'তে অঙ্কনের জন্য একটি মডিউল আছে, এবং আমি পৃথক আছে .cপ্রতিটি উপাদানের জন্য ফাইল আমি প্রয়োজন ( slider.c, indicator.cইত্যাদি)। এই উপাদানগুলির বাস্তবায়নে একটি মূল অঙ্কন ফাংশন হতে পারে কয়েকশ লাইন দীর্ঘ এবং এর staticমধ্যে বেশ কয়েকটি সহায়ক সহায়ক । তারা ইউআই মডিউল থেকে কিছু বিশুদ্ধ জ্যামিতি ফাংশন কল করে। শব্দটি কি মোটামুটি সাধারণ?
ড্যান হলিডে

দীর্ঘ নামগুলির একটি আরও ভাল উদাহরণ হতে পারে আমার অডিও মডিউল হতে পারে - আমার একটি হায়ারার্কি রয়েছে Audio Module > Engines > Channels > Filtersযার অর্থ কিছুটা MyLibAudioEngines<EngineName>Channel<ActionName>। অথবা আমার ফিল্টারগুলিতে সাবমডিউল: MyLibAudioFilters<FilterName><Type><Action>যেমন। MyLibAudioFiltersBigSoundingCompressorFloat32Process
ড্যান হলিডে

এর কোনওটিই অযৌক্তিক বলে মনে হয় না। একটি ফাংশনটির জন্য কয়েকশ লাইন কিছুটা দীর্ঘ বলে মনে হচ্ছে তবে আপনি যা আঁকছেন তা যদি জটিল হয় তবে তা এড়ানো কঠিন। এটি শাখা ভারী না শুধুমাত্র নির্দেশাবলী অনেক?
ব্যবহারকারী 2313838

পুনরায়: অডিও মডিউলটির নামগুলি, আপনি অডিও ফিল্টারগুলি / অডিও ইঞ্জিনগুলি সংক্ষিপ্ত করতে পারেন কারণ আমি মনে করি এটি নামের ভিত্তিতে কোনও ফিল্টার বা মডিউল কিনা তা বলা সহজ হবে। ফ্লাট 32 এর মতো ডেটাটাইপ কোয়ালিফায়ারগুলির সংক্ষিপ্তকরণও করা যেতে পারে (যেমন 'ডি', 'চ') সি প্রোগ্রামিংয়ে যেমন সংক্ষিপ্তসারগুলি সাধারণ।
ব্যবহারকারী 2313838

আপনার উত্তরের জন্য ধন্যবাদ - কখনও কখনও সি প্রোগ্রাম আর্কিটেকচারের (বিশেষত উচ্চ স্তরের ভাষার তুলনায়) ভাল তথ্য পাওয়া অসম্ভব বলে মনে হয়। আমি অনেক সি বই পড়েছি সবে একাধিক মডিউল বা এমনকি একাধিক ফাইল থাকার ধারণা বিবেচনা করে! সামগ্রিকভাবে, আমি মনে করি না যে আমি দীর্ঘ কিছুটির সংক্ষিপ্তসার নিয়ে বাস করব কিনা তা বিবেচনা করে আমি অনেক পরিবর্তন করব।
ড্যান হলিডে

5

সি লাইব্রেরির জন্য সাধারণ কনভেনশনটি হ'ল বাহ্যিকভাবে ব্যবহারযোগ্য নামগুলির জন্য লাইব্রেরির নামটিকে উপসর্গ হিসাবে ব্যবহার করা হয়, যেমন

struct MyLibFoo;
void MyLibAFooAction(...);

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

struct MyLibInternalFooBaz;
void MyLibInternalFooBazAction();

আমি সম্মত হই যে এর ফলে নামগুলি বেশ দীর্ঘ এবং টাইপ করা শক্ত হতে পারে, তবে দুর্ভাগ্যক্রমে সি ++ নেমস্পেসের মতো কোনও ব্যবস্থা না রাখার জন্য আমাদের এই মূল্য দিতে হবে। নামগুলির দৈর্ঘ্য হ্রাস করার জন্য, কিছু স্পষ্টতার মূল্যে, আপনি নিজের নামগুলিতে সংক্ষেপগুলি ব্যবহার করতে বেছে নিতে পারেন, তবে আপনাকে সুবিধাগুলি এবং অসুবিধাগুলি যত্ন সহকারে বিবেচনা করতে হবে।


3

যদি আপনি দীর্ঘ উপসর্গ এড়াতে চান, আপনি অ্যাপল আইওএস এবং ওএস এক্স এর মতো লাইব্রেরির নাম সংক্ষেপণ করতে পারেন:

  • এনএসএসটিং হ'ল ওএসের নেক্সটস্টেপ শিকড় থেকে আসা একটি স্ট্রিং
  • ক্যালায়ার একটি কোর অ্যানিমেশন স্তর

2

বিশ্বব্যাপী কাঠামোর পরিবর্তনশীল ফাংশন পয়েন্টারগুলির সাথে প্রিফিল্ড কী হবে?

lib.h

#pragma once

typedef struct
{
    void (*doFoo)(int x);
    const char *(*doBar)(void *p);
} YourApi;

extern const YourApi yourApi;

lib.c:

#include "lib.h"

#include <stdio.h>

static void doFoo(int x)
{
    printf("Doing foo %d\n", x);
}

static const char *doBar(void *p)
{
    printf("Doing bar: %p\n", p);
    return "Hello";
}

const YourApi yourApi = {
    doFoo,
    doBar};

কাজে লাগান:

#include "lib.h"

int main()
{
    yourApi.doFoo(42);
    yourApi.doBar("asd");
}

স্থিতিশীল কীওয়ার্ডটি অনুবাদ ইউনিটে সুযোগটি সীমাবদ্ধ করে তাই এটি অন্যের সাথে সংঘর্ষে নেমে না।

ব্যবহারকারী তারপর মত একটি পয়েন্টার ব্যবহার করে এটি খাটো করতে পারেন YourApi *ya = &yourApi, তারপর ব্যবহার ya->doFoo(...)

এটি পরীক্ষার জন্য আপনার গ্রন্থাগারকে উপহাস করার জন্য একটি দুর্দান্ত উপায়ও সরবরাহ করে।


দুর্দান্ত প্যাটার্ন, এটিতে কিছুটা বয়লারপ্লেট প্রয়োজন, তবে এটি স্বতঃপূরণকে আরও দরকারী করে তুলবে।
রিক লাভ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.