হেডার ফাইল বা উত্স ফাইলটিতে ফাংশনগুলি নথিভুক্ত করা ভাল?


86

যে ভাষাগুলিতে একটি "উত্স" এবং "শিরোনাম" ফাইলের মধ্যে পার্থক্য রয়েছে (প্রধানত সি এবং সি ++), শিরোনাম ফাইলটিতে ফাংশনগুলি নথিভুক্ত করা আরও ভাল:

( সিসিএএন থেকে চালিত )

/**
 * time_now - return the current time
 *
 * Example:
 *  printf("Now is %lu seconds since epoch\n", (long)time_now().tv_sec);
 */
struct timeval time_now(void);

না সোর্স ফাইলে?

(পোস্টগ্রিজ এসকিউএল থেকে চালিত)

/*
 * Convert a UTF-8 character to a Unicode code point.
 * This is a one-character version of pg_utf2wchar_with_len.
 *
 * No error checks here, c must point to a long-enough string.
 */
pg_wchar
utf8_to_unicode(const unsigned char *c)
{
...

নোট করুন যে কিছু জিনিস কেবল শিরোনামে সংজ্ঞায়িত করা হয় যেমন স্ট্রাক্টস, ম্যাক্রোস এবং static inlineফাংশনগুলি। আমি কেবল সেই বিষয়গুলি নিয়েই বলছি যা একটি শিরোনাম ফাইলে ঘোষিত হয় এবং উত্স ফাইলে সংজ্ঞায়িত হয়।

এখানে আমি কিছু যুক্তি যা ভাবতে পারি। আমি উত্স ফাইলটিতে নথির দিকে ঝুঁকছি, সুতরাং আমার "প্রো-হেডার" যুক্তিগুলি কিছুটা দুর্বল হতে পারে।

প্রো-শিরোলেখ:

  • ডকুমেন্টেশন দেখতে ব্যবহারকারীর উত্স কোডের প্রয়োজন নেই।
    • উত্সটি অর্জন করা অসুবিধাজনক এমনকি অসম্ভবও হতে পারে।
    • এটি ইন্টারফেস এবং বাস্তবায়নকে আরও পৃথক করে রাখে।

প্রো-উৎস:

  • এটি শিরোনামকে আরও খাটো করে তোলে, পাঠককে সামগ্রিকভাবে মডিউলটির পাখি-দর্শন দেয়।
  • এটি কোনও ফাংশনের ডকুমেন্টেশনটিকে এর বাস্তবায়নের সাথে যুক্ত করে, এটি সহজেই দেখতে দেয় যে কোনও ফাংশন এটি যা বলে তা যা করে তা করে।

উত্তর দেওয়ার সময়, কী কী সরঞ্জাম এবং "আধুনিক আইডিই" করতে পারে তার উপর ভিত্তি করে যুক্তি থেকে সাবধান থাকুন। উদাহরণ:

  • প্রো-শিরোনাম: কোড ফোল্ডিং মন্তব্যগুলি লুকিয়ে রেখে মন্তব্য করা শিরোনামকে আরও নাব্য করে তুলতে সহায়তা করতে পারে।
  • প্রো-উৎস: cscope এর Find this global definitionবৈশিষ্ট্য সোর্স ফাইল (যেখানে প্রদর্শিত হয় সংজ্ঞা হয়) বরং হেডার ফাইল (যেখানে ঘোষণা যায়)।

আমি বলছি না যে এই জাতীয় যুক্তি দেবেন না, তবে মনে রাখবেন যে আপনি যে সরঞ্জামগুলি ব্যবহার করছেন তার সাথে সকলেই স্বাচ্ছন্দ্যবোধ করেন না।


একই প্রশ্নটি পাস্কল / ডেলফির ক্ষেত্রে প্রয়োগ করতে পারে যেখানে আমাদের কাছে সোর্স এবং শিরোনাম ফাইল নেই তবে ইন্টারফেস এবং বাস্তবায়ন বিভাগ রয়েছে।
জান ডোগজেন

1
আরও দেখুন stackoverflow.com/questions/355619/...
cp.engr

উত্তর:


96

আমার মতে...

  • শিরোনাম ফাইলে কীভাবে ফাংশনটি ব্যবহার করবেন, বা আরও সঠিকভাবে ঘোষণার নিকটে ডকুমেন্ট করুন।

  • উত্স ফাইলে কীভাবে ফাংশনটি কাজ করে (যদি তা কোড থেকে স্পষ্ট না হয়) বা আরও সঠিকভাবে সংজ্ঞাটির নিকটে ডকুমেন্ট করুন।

শিরোনামে পাখি-চোখের জিনিসটির জন্য, আপনার অগত্যা যে ডকুমেন্টেশনটি খুব কাছে দরকার নেই - আপনি একবারে ঘোষণার দলগুলি নথিভুক্ত করতে পারেন।

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


13
+1 - অর্থ শিরোনামে ইন্টারফেসটি নথি করুন। উত্সটিতে কীভাবে এবং কেন তার গ্যুরি বিশদ।
দ্রুত_আবার 15:30 '

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

স্বাভাবিকভাবেই, কখনও কখনও ঘোষণা এবং সংজ্ঞা এক এবং এক হয়।
Deduplicator

@ প্রতিলিপি - যখন একই বিধিগুলি এখনও বিশেষ ক্ষেত্রে সঠিক জিনিসকে নিয়ে যায় তখন কেন প্রতিটি বিশেষ ক্ষেত্রে এই নিয়মগুলি প্রতিধ্বনিত হয়? নিশ্চয় কোনও অনুচ্ছেদে তা চাওয়া উচিত নয়?
স্টিভ 314

1
@ উত্সাহক - অবশ্যই এটি আপনার পরামর্শ অনুসরণ না করার জন্য ব্যাপকভাবে উত্সাহিত করার যুক্তি, তবে আমি এটির সাথে লেগে আছি।
স্টিভ 314

34

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

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

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


2
+1 - এমন একটি প্রমাণ দিয়ে যে আপনি ডক্সিজেন ব্যবহার করলেও, এর অর্থ এই নয় যে আপনি কখনই উত্স থেকে সরাসরি পড়তে যাবেন না। অক্সিজেন টীকা এমনকি কখনও কখনও গ্রেপ করার জন্য স্ট্যান্ডার্ড নিদর্শন হিসাবে কার্যকর হয় এবং আপনি যে টীকাটি খুঁজে পান সেটি বর্ণিত কোডের নিকটে থাকলে এটি কার্যকর।
স্টিভ 314

1
@ স্টিভ 314 অবশ্যই আমি এটি বলিনি যে আপনি কখনও কোনও লাইব্রেরির উত্স কোডটি দেখতে চান না - তবে এটি প্রথম স্থান নয় যা আপনি এপিআই দেখতে দেখতে এবং এটি কীভাবে ব্যবহার করবেন তা সন্ধান করতে চান না।
জেস্পার

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

12

আমরা উত্স ফাইলে ব্যবহার করা যেতে পারে এমন একটি ডেডফাইন (উদাহরণস্বরূপ পাবলিক, প্রাইভেট ইত্যাদি) সমাধান করেছে যা উত্স ফাইলে ব্যবহার করা যেতে পারে এবং একটি awk স্ক্রিপ্ট (ভয়াবহতা) দ্বারা স্ক্যান করা হয়েছিল এমন একটি গুচ্ছ তৈরি করে (প্রায় 25 বছর আগে) এই সমস্যাটি সমাধান করেছি !) ফাইলগুলি স্বয়ংক্রিয়ভাবে তৈরি করতে। এর অর্থ হ'ল সমস্ত মন্তব্য উত্সে থাকত এবং উত্পন্ন .h ফাইলটিতে অনুলিপি করা হয়েছিল (যখন উপযুক্ত হবে)। আমি জানি যে এটি বেশ পুরাতন স্কুল, তবে এটি এই ধরণের ইনলাইন ডকুমেন্টেশনকে ব্যাপকভাবে সরল করেছে।


1
হুম আমি জানি এই স্টাইলের জিনিসটি কার্যকর হতে পারে তবে আমার দৃষ্টিকোণ থেকে আমি সর্বদা এ জাতীয় ডকুমেন্টেশনকে সর্বদা বিরক্তিকর বলে মনে করি ...
ওসিরিসগোথর

1
ডোনাল্ড রুমসফেল্ডকে ( যাকে আমি পছন্দ করি না ) প্যারাফ্রেস করতে , "আপনি আপনার কাছে থাকা সরঞ্জামগুলি দিয়ে প্রোগ্রাম করেন, আপনি যে সরঞ্জামগুলি চান সেগুলি দিয়ে নয়।" আমি গত 40+ বছর ধরে যে ভাষা নিয়ে কাজ করেছি তার কমপক্ষে একটি বড় ওয়ার্ট রয়েছে (যদি না হয় তবে)। আমাদের সমাধান ক) কাজ করেছে, খ) সেই সময়ে ব্যবহৃত সরঞ্জামগুলি ব্যবহৃত হয়েছিল, গ) আসুন উপার্জনের কোডটি দরজার বাইরে পেয়ে আমাদের সময় ব্যয় করি।
পিটার রোয়েল

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

ওহ, আমি সম্প্রতি একই প্যাটার্নটি 2000
ডলারে

3
আমাদের ক্ষেত্রে আমরা উত্পন্ন ফাইলগুলির কোনওটিকে সংস্করণ নিয়ন্ত্রণে রাখিনি কারণ সেগুলি ট্র্যাক করা ফাইলগুলি থেকে সহজে এবং সরাসরি (পুনরায়) উত্পন্ন হয়েছিল।
পিটার রোয়েল

9

ধরে নেওয়া যাক এই একটি বৃহত্তর প্রকল্পের মধ্যে কোড (যেখানে ডেভেলপারদের উৎস এবং হেডার এর মধ্যে চলমান করা হবে না প্রায়ই) , এবং এই প্রদানের নয় একটি লাইব্রেরি / মধ্যম গুদাম, যেখানে অন্যদের উৎস অ্যাক্সেস নাও থাকতে পারে, আমি এই কাজ পাওয়া করেছি সেরা ...

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

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

অবশ্যই আপনি একটি সম্মেলন বাছাই করতে পারেন এবং সমস্ত দেব অনুসরণ করতে পারেন তা নিশ্চিত করে আমি কনভেনশনটি সর্বাধিক প্রাকৃতিক-ফিটের উপরে পেয়েছি এবং এটি বজায় রাখতে কমপক্ষে সমস্যা সৃষ্টি করে।


সর্বোপরি, বড় প্রকল্পগুলির জন্য - যখন অন্যরা সংস্করণ নিয়ন্ত্রণ আপডেট করে তখন সম্ভাব্যভাবে 100 বা 1000 এর ফাইলগুলি পুনরায় সংকলন করতে চলেছে যখন আপনি জানেন তখন একটি শিরোনামে ছোট সংশোধন না করার প্রবণতা রয়েছে - দ্বিখণ্ডিত ত্রুটিগুলিও কমিয়ে দেয়।


5

আমার (বরং সীমাবদ্ধ এবং পক্ষপাতদুষ্ট) মতে আমি উত্সের উত্সের কোডের চিন্তার উপায়। আমি যখন সি ++ তে বিটস এবং টুকরো করি, আমি সাধারণত একবারে শিরোনাম ফাইলটি সম্পাদনা করি এবং তারপরে আমি সত্যিই কখনও ফিরে যাই না।

আমি যখন সোর্স ফাইলে ডকুমেন্টেশন রাখি, আমি কোডগুলি সম্পাদনা করতে বা পড়ার সময় সর্বদা এটি দেখতে পাচ্ছি। আমার ধারণা এটি অভ্যাসের জিনিস।

তবে এটাই আমি ...


1
আপনার কাছে থাকা সমস্তগুলি যদি সংকলিত গ্রন্থাগার এবং শিরোনাম ফাইল হয় তবে খুব ভাল কাজ করে না। সেক্ষেত্রে শিরোনামে আরও তথ্য হ'ল একটি ভাল জিনিস কারণ এটির একমাত্র ইন্টারফেস ডকুমেন্টেশন।
দ্রুত_নু

আপনি ডক্সিজেনের সাথে ডকুমেন্টেশন তৈরি করতে পারেন - এটি এটি .c ফাইলগুলি থেকেও নেয়। সুতরাং আপনি সংকলিত গ্রন্থাগারগুলি দিয়ে সহজেই ডকুমেন্টেশন বিতরণ করতে পারেন। তবে সমস্যাটি আইডিইর সাথে থাকবে যা ফাংশনটি ব্যবহার করার সময় শিরোলেখের ফাইলগুলি পার্স করতে এবং আপনাকে ডকুমেন্টেশন দিতে পারে ... তবে সম্ভবত এটি কিছু মোতায়েন করা স্ক্রিপ্ট সমাধান করতে পারে যা ফাংশন মন্তব্যগুলিকে
ক। ক। এ। ক

5

মন্তব্যগুলি ডকুমেন্টেশন নয়। কোনও ফাংশনের ডকুমেন্টেশন সাধারণত ডায়াগ্রামের সাহায্যে 2K পাঠ্য হতে পারে - উদাহরণস্বরূপ উইন্ডোজ এসডিকে ফাংশনগুলির জন্য ডকুমেন্টেশন দেখুন। এমনকি যদি আপনার মন্তব্য-টু-ডক এইরকম কোনও জিনিসকে অনুমতি দেয় তবে আপনি এমন কোড তৈরি করবেন যাতে মন্তব্যটি অপঠনযোগ্য। আপনি যদি ডকুমেন্টেশন তৈরি করতে চান তবে একটি ওয়ার্ড-প্রসেসর ব্যবহার করুন।


আপডেট করুন, এই দিনটি (সেখানে Qt স্রষ্টার মতো স্টাফ সহ) ডক্সিঞ্জন (বা ক্লোন) উপায়ে ডকুমেন্ট করা খুব সহজ, উদাহরণস্বরূপ, Qtc এ আপনি মন্তব্যটির আগে কয়েকবার / কী টিপুন এবং অর্ধেক আপনার জন্য কাজ করা হয়েছে। এই জাতীয় জিনিসগুলির কারণে, আমি সন্দেহ করি লোকেরা কেবল তাদের কোডটি নথিভুক্ত করতে কোনও ওয়ার্ড প্রসেসরে ঝাঁপিয়ে পড়তে চাইবে। আমি 2005 সালে ফিরে এটি মঞ্জুর করে দিয়েছিলাম, তবে এখনই আর তা করব না। এমনকি এইচটিএমএল সম্পাদক ব্যবহার করা এখন বেশ প্রত্নতাত্ত্বিক বলে মনে হচ্ছে।
osirisgothra

@osirisgothra ডক্সিজেন- "ডকুমেন্টেশন" করা সহজ হতে পারে এবং অবশ্যই খুব দ্রুত লিখিত এলওসি তৈরি করে তবে উত্পাদিত "ডকুমেন্টেশন" এর মান বেশিরভাগ ক্ষেত্রেই বিতর্কিত থেকে যায়। অক্সিজেনের মন্তব্যগুলিও ভাল ডকুমেন্টেশন নয় (প্রায় সমস্ত গুরুত্বপূর্ণ বিবরণ সাধারণভাবে নিখোঁজ রয়েছে), বা তারা ভাল মন্তব্যও করেনি (তারা স্বাক্ষর থেকে ইতিমধ্যে যা স্পষ্ট তা পুনরাবৃত্তি করে)। আমি মনে করি এনবিটি সঠিকভাবে বলেছে যে কোডের সাথে বাস্তব ডকুমেন্টেশন সবচেয়ে ভাল মিশ্রিত নয় কারণ এটি কোড পঠনযোগ্যতার পক্ষে ক্ষতিকারক। এটি যে কোনও উপায়ে সিঙ্কের বাইরে চলে যাবে, এর জন্য কোনও রূপোর বুলেট নেই।
13

4

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

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


0

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


1
এই কিছু সারগর্ভ প্রস্তাব উপর পয়েন্ট হয়েছে এবং পূর্বে 7 টি উত্তর ব্যাখ্যা বলে মনে হচ্ছে না
মশা

1
পূর্ববর্তী 7 টি উত্তর থেকে আগত @ শিরোনামের বিরুদ্ধে কোডের পক্ষে কেবল একটি। এবং যে এক সম্পূর্ণ ভিন্ন যুক্তি দিচ্ছে।
স্লাভা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.