হেডার ফাইলটিতে কী এবং কী হওয়া উচিত নয়? [বন্ধ]

Question

কোন বিষয়গুলি একেবারে শিরোনাম ফাইলটিতে অন্তর্ভুক্ত করা উচিত নয়?

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

শিরোনাম ফাইলটিতে কোন ফাংশন থাকা উচিত?
কোন ফাংশন করা উচিত নয়?

Comments

সংক্ষিপ্ত এবং বেদনাদায়ক: সংজ্ঞা এবং ঘোষণা যা একাধিক মডিউলে প্রয়োজনীয়।

— অট--

এই প্রশ্নটিকে "অত্যধিক বিস্তৃত" হিসাবে চিহ্নিত করা এবং বন্ধ করা সংযমের একান্ত লজ্জাজনক ওভারকিল। এই প্রশ্নটি হুবহু জিজ্ঞাসা করছে আমি কী খুঁজছি - প্রশ্নটি ভালভাবে গঠিত এবং খুব পরিষ্কার প্রশ্ন জিজ্ঞাসা করে: সর্বোত্তম অনুশীলনগুলি কী কী? এটি যদি সফ্টওয়্যারেনজিনিয়ারিংয়ের জন্য "খুব বেশি বিস্তৃত" হয় .. আমরা পুরো ফোরামটি বন্ধ করে দিতে পারি।

— গেউউবার

টি এল; ডাঃ. সি ++ এর জন্য, বার্জন স্ট্রোস্ট্রুপ (এর স্রষ্টা) দ্বারা রচিত "দ্য সি ++ প্রোগ্রামিং ল্যাঙ্গুয়েজ" এর চতুর্থ সংস্করণে বিভাগের 15.2.2 এ বর্ণনা করা হয়েছে যে শিরোনামটি কী কী থাকা উচিত এবং কী করা উচিত নয়। আমি জানি আপনি প্রশ্নটি সিটিতে ট্যাগ করেছেন, তবে কয়েকটি পরামর্শও প্রযোজ্য। আমি মনে করি এটি একটি ভাল প্রশ্ন ...

— হ্যারো

Answer 1

হেডারগুলিতে কী রাখবেন:

• #includeহেডারকে কোনও উত্স ফাইলে অন্তর্ভুক্ত করা হলে শিরোনামকে সংকলনযোগ্য করতে প্রয়োজনীয় ন্যূনতম নির্দেশাবলীর সেট ।
• প্রিপ্রসেসর প্রতীক সংজ্ঞাগুলির যেগুলির ভাগ করা দরকার এবং এটি কেবল প্রিপ্রসেসরের মাধ্যমে সম্পন্ন করা যায়। এমনকি সিতে, প্রিপ্রোসেসর চিহ্নগুলি সর্বনিম্ন রাখা হয়।
• কাঠামোর সংজ্ঞা, ফাংশন প্রোটোটাইপস এবং শিরোনামের শরীরে বৈশ্বিক পরিবর্তনশীল ঘোষণাগুলি সংকলনযোগ্য করে তুলতে প্রয়োজনীয় কাঠামোগুলির অগ্রবর্তী ঘোষণা ward
• একাধিক উত্স ফাইলগুলির মধ্যে ভাগ করা ডেটা স্ট্রাকচার এবং গণনার সংজ্ঞা।
• ফাংশন এবং ভেরিয়েবলের জন্য ঘোষণা যার সংজ্ঞা লিঙ্কারের কাছে দৃশ্যমান হবে।
• ইনলাইন ফাংশন সংজ্ঞা, তবে এখানে যত্ন নিন।

কোন শিরোলেখ অন্তর্ভুক্ত নয়:

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

#includeবিবৃতি সর্বনিম্ন সেট গঠন কি ?

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

কৃতজ্ঞ #includeনির্দেশের জন্য একটি জায়গা রয়েছে এবং এটি একটি স্বয়ংক্রিয় পরীক্ষায়। একটি সফ্টওয়্যার প্যাকেজে প্রতিটি শিরোনাম ফাইলের জন্য, আমি স্বয়ংক্রিয়ভাবে উত্পন্ন করে নীচেরগুলি সংকলন করি:

#include "path/to/random/header_under_test"
int main () { return 0; }

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

Comments

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

— মারকাসজে

@ মার্কাসজে - আমি প্রথম শিরোনামের মধ্যে যা অন্তর্ভুক্ত না তার নীচে তালিকাভুক্তটি ছিল অকৃতজ্ঞ # বিবৃতি অন্তর্ভুক্ত। হেডার ফাইল বি যদি হেডার ফাইল এ এর ​​সংজ্ঞাগুলির উপর নির্ভর করে না, তবে শিরোনাম ফাইল বিতে শিরোনাম ফাইল A অন্তর্ভুক্ত করবেন না বি একটি শিরোনাম ফাইল তৃতীয় পক্ষের নির্ভরতা নির্দিষ্ট করার বা নির্দেশাবলী তৈরি করার জায়গা নয়। এগুলি অন্য কোথাও যায় যেমন শীর্ষ স্তরের রিডমি ফাইল।

— ডেভিড হামেন

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

— ডেভিড হামেন

হ্যাঁ এটি কেস 2, দুঃখিত আমার মন্তব্যটি লাইব্রেরি বি এর শিরোনামগুলিতে লাইব্রেরি এ-তে ঘোষিত প্রকারগুলি ব্যবহার করে এড়িয়ে গেছে, আমি ভেবেছিলাম যে আমি এটি ঘোষণা করতে সক্ষম হতে পারি, তবে আমার মনে হয় না এটি কার্যকর হবে। আপডেটের জন্য ধন্যবাদ.

— মারকাসজে

একটি শিরোলেখ ফাইলটিতে ধ্রুবকগুলি যুক্ত করা কি বড় নম্বর-নন?

— এমডিং 5692

Answer 2

ইতিমধ্যে যা বলা হয়েছে তা ছাড়াও।

এইচ ফাইলগুলিতে সর্বদা থাকা উচিত:

• সোর্স কোড ডকুমেন্টেশন !!! সর্বনিম্ন, ফাংশনগুলির বিভিন্ন পরামিতি এবং রিটার্ন মানগুলির উদ্দেশ্য কী।
• শিরোনাম রক্ষীরা, # আইফেন্ডেফ এমওয়াইএইডিআইডিএইচ # নির্ধারিত মাইএইইডিআইডিইএইচ ... # তফত

এইচ ফাইলগুলিতে কখনই থাকা উচিত নয়:

• ডেটা বরাদ্দের কোনও ফর্ম।
• ফাংশন সংজ্ঞা ইনলাইন ফাংশন কিছু ক্ষেত্রে বিরল ব্যতিক্রম হতে পারে।
• কিছু লেবেলযুক্ত static।
• টাইপিডেফস, # নির্দিষ্টকরণ বা ধ্রুবকগুলির সাথে বাকী অ্যাপ্লিকেশনটির কোনও প্রাসঙ্গিকতা নেই।

(আমি এও বলব যে অবিচ্ছিন্ন গ্লোবাল / বাহ্যিক চলকগুলি যে কোনও জায়গায় ব্যবহার করার কোনও কারণ নেই, তবে এটি অন্য পোস্টের জন্য আলোচনা discussion)

Comments

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

— মার্টিয়ারেট

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

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

সম্ভবত "উত্স কোড ডকুমেন্টেশন" এখানে খুব বিস্তৃত, এটি সত্যই উত্স কোডের অন্তর্গত। ইনপুট এবং আউটপুট, প্রাক- এবং পোস্টকন্ডিশনগুলি এবং পার্শ্ব-প্রতিক্রিয়া সহ "ব্যবহারের ডকুমেন্টেশন" অবশ্যই সেখানে যেতে হবে, মহাকাব্যগুলিতে নয়, একটি সংক্ষিপ্ত আকারে।

— সুরক্ষিত করুন

কিছুটা বিলেড, তবে ডকুমেন্টেশনের জন্য +1। কেন এই শ্রেণীর অস্তিত্ব আছে? কোডটি নিজের পক্ষে কথা বলে না । এই ফাংশনটি কী করে? আরটিএফসি (সূক্ষ্ম .cpp ফাইলটি পড়ুন) একটি অশ্লীল চার অক্ষরের সংক্ষিপ্ত বিবরণ। বোঝার জন্য কখনই আরটিএফসিএর হওয়া উচিত নয়। শিরোনামের প্রোটোটাইপটি সংক্ষিপ্ত করে নেওয়া উচিত, কিছু এক্সট্র্যাকটেবল মন্তব্যে (যেমন, ডক্সিন), আর্গুমেন্টগুলি কী এবং ফাংশনটি কী করে। এই ডেটা সদস্যটি কেন বিদ্যমান, এতে কী রয়েছে এবং মিটার, ফুট বা ফারলংসের মূল্য কী? এটিও (এক্সট্র্যাকটেবল) মন্তব্যের জন্য অন্য একটি বিষয়।

— ডেভিড হামেন

Answer 3

আমি সম্ভবত কখনই বলব না, তবে যে বিবৃতিগুলি ডেটা এবং কোড পার্স করার সাথে সাথে উত্পন্ন করে তা কোনও .h ফাইলে থাকা উচিত নয়।

ম্যাক্রোস, ইনলাইন ফাংশন এবং টেমপ্লেটগুলি ডেটা বা কোডের মতো দেখতে পারে তবে তারা পার্স করার সাথে সাথে কোডটি উত্পন্ন করে না, পরিবর্তে যখন সেগুলি ব্যবহৃত হয়। এই আইটেমগুলি প্রায়শই একাধিক .c বা .cpp ব্যবহার করা প্রয়োজন, সুতরাং এগুলি হ।

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

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

Answer 4

শিরোনাম ফাইলে নিম্নলিখিত সংস্থা থাকা উচিত:

• টাইপ এবং ধ্রুবক সংজ্ঞা
• বাহ্যিক বস্তু ঘোষণা
• বাহ্যিক ফাংশন ঘোষণা

শিরোনাম ফাইলগুলিতে কখনই অবজেক্ট সংজ্ঞা থাকতে পারে না, কেবল টাইপ সংজ্ঞা এবং অবজেক্ট ডিক্লেয়ারেশন থাকে।

Comments

ইনলাইন ফাংশন সংজ্ঞা সম্পর্কে কি?

— কোস

যদি ইনলাইন ফাংশনটি কোনও "সহায়ক" ফাংশন হয় যা কেবলমাত্র একটি সি মডিউলের অভ্যন্তরে ব্যবহৃত হয়, তবে কেবল এটি। সি ফাইলটিতে রেখে দিন। যদি, ইনলাইন ফাংশনটি অবশ্যই দুটি বা ততোধিক মডিউলে দৃশ্যমান হয়, এটি হেডার ফাইলের মধ্যে রেখে দিন।

— theD

এছাড়াও, যদি ফাংশনটি একটি লাইব্রেরির সীমানা জুড়ে দৃশ্যমান হতে হয়, তবে এটিকে ইনলাইন করবেন না যা প্রত্যেকটি জিনিস পরিবর্তন করার সময় লাইব্রেরি ব্যবহার করে এমন প্রত্যেককে পুনরায় কম্পাইল করতে বাধ্য করে।

— ডোনাল ফেলো

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

— ডেভিড হামেন

Answer 5

যে বিবৃতিগুলি পার্স করা হয় সে হিসাবে ডেটা এবং কোড উত্পন্ন করে, কোনও .hফাইলে থাকা উচিত নয় । যতদূর আমার দৃষ্টিকোণ সম্পর্কিত, একটি শিরোনাম ফাইলের কোনও সংশ্লিষ্ট .cবা এর সাথে সর্বনিম্ন ব্যবহারিক ইন্টারফেস থাকতে হবে .cpp।