কোডিং স্ট্যান্ডার্ডে কী হওয়া উচিত? [বন্ধ]


34

একটি ভাল (পড়া: দরকারী) কোডিং স্ট্যান্ডার্ডে কী হওয়া উচিত?

  • কোড থাকা উচিত।
  • কোডগুলি থাকা উচিত নয়।
  • কোডিং স্ট্যান্ডার্ডে ভাষা, সংকলক, বা কোড ফর্ম্যাটার প্রয়োগকারী জিনিসগুলির সংজ্ঞা অন্তর্ভুক্ত করা উচিত?
  • সাইক্লোমেটিক জটিলতা, ফাইলের প্রতি লাইন ইত্যাদির মতো মেট্রিকগুলি সম্পর্কে কী?

উত্তর:


40

প্রতিটি প্রয়োজনের একটি কারণ। এইভাবে, মান অনুসরণ করা কোনও ধরণের কার্গো কাল্ট হয়ে ওঠে না এবং লোকেরা জানে যে স্ট্যান্ডার্ডটি পরিবর্তন করা ঠিক আছে কারণ যদি এর কারণটি আর প্রয়োগ না হয় বা নির্দিষ্ট ক্ষেত্রে যেখানে কারণটি স্পষ্টভাবে প্রয়োগ না করে তবে মানটিকে লঙ্ঘন করা ঠিক আছে ok ।


3
একেবারে। স্ট্যান্ডার্ডের প্রতিটি আইটেমের যুক্তিটি স্পষ্টভাবে নির্দিষ্ট করা উচিত।
আশেলী

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

9
@ ডেভিড: কোডিং স্ট্যান্ডার্ড থাকার জন্য এটি একটি সম্পূর্ণ বৈধ কারণ। যদি সে কারণটি হয় তবে এটিকে কেবল এ জাতীয় হিসাবে বলা উচিত, যেমন "কারণ: কোডবেজের ধারাবাহিকতা উন্নত করার জন্য" "
dsimcha

আসলে, একটি কোডিং মান সম্পর্কে সবচেয়ে গুরুত্বপূর্ণ বিষয় যে আছে হয় না। কি সত্যিই মাধ্যমিক আছে হয়।
জার্গ ডব্লু মিত্তাগ

20

ট্যাব বনাম স্পেস! আমার এক সহকর্মী দুর্ঘটনাক্রমে স্থানগুলিতে স্থান পরিবর্তন করার জন্য প্রচুর ট্যাব সঞ্চার করলে আমি পাগল আপডেট পেতে পারি


1
আমি আন্তরিকভাবে রাজি!
মাটিয়াশ

2
আইএমএইচও, এটি একটিমাত্র জিনিস যা কোডিং স্ট্যান্ডার্ডে থাকার যোগ্য।
পি


2
আইএমএইচও, কোডিং মানটি কী not েকে রাখে না তার একটি দুর্দান্ত উদাহরণ ।
বজার্ক ফ্রুন্ড-হ্যানসেন

@ বারজারেফ, আপনি কি মিশ্র ট্যাব এবং স্পেস কোড পছন্দ করেন?
Jé ক্যু

19

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

সম্পাদনা: এর অর্থ হ'ল নির্দেশিকাগুলির নামকরণ, বিধি নামকরণ নয়।

উদাহরণস্বরূপ, একটি গাইডলাইন হবে All boolean values should begin with Is/Can/Has/etc when possible। একটি নিয়ম হবেAll boolean values must start with Is


3
এলপিএসজেড * lppsz_CPP_MrKim_ClassOf স্টুডেন্টস [] [];
মতিন উলহাক

3
-1: এটি হ'ল নিম্ন-স্তরের বিশদটির ধরণের যা বিকাশকারীদের মান অগ্রাহ্য করে। আপনি পাশাপাশি হ্যান্ডেট করতে পারেন যে প্রত্যেকে নেটিটিস পরে।
TMN

2
@ টিএমএন: নামকরণের কনভেনশনগুলির অভাব হ'ল সঠিক ধরণের জিনিস যা বিকাশকারীদের কোডটি সর্বদা বোঝার জন্য হতাশ হয়ে পড়ে। এগুলি নিট-পিক হতে হবে না, তবে কয়েকটি সাধারণ নির্দেশিকা প্রচুর পরিমাণে সহায়তা করবে।
ডেভিড থর্নলি

1
@ রাচেল: হ্যাঁ, আমাদের কাছে "সমস্ত বুলিয়ান সম্পত্তি অবশ্যই 'ইস' স্ট্যান্ডার্ড দিয়ে শুরু হওয়া উচিত। IsCanUpdateএবং এর মতো বৈশিষ্ট্যগুলির সাথে ক্ষতবিক্ষত হবে IsHasChildren। অবশ্যই, এটি ভুল, তবে এটি স্ট্যান্ডার্ডে ডিক্রি হয়েছিল। এবং এটি আমার বক্তব্য: একবার আপনি এই বিষয়গুলি নির্দিষ্ট করে তোলা শুরু করার পরে আপনাকে নিশ্চিত করতে হবে যে আপনি সমস্ত ঘাঁটিটি coverেকে রেখেছেন, না হলে লোকেরা এমন কোনও কিছুতে চালিত হয় যা স্ট্যান্ডার্ডটি আবরণ করে না, বা খারাপভাবে কভার করে, এবং তারপরে তারা হয় এমন কিছু লিখেন যা ভুল, অথবা তারা মানটিকে উপেক্ষা করে শুরু করে। যেভাবেই হোক, দল হেরে যায়।
টিএমএন

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

10

একটি গোষ্ঠীর কোডিং মানের মধ্যে সতর্কতা এবং ত্রুটিগুলির জন্য সংকলক বিকল্পগুলি অন্তর্ভুক্ত করা উচিত যা মোকাবিলা করতে হবে।

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

প্রোগ্রামাররা কীভাবে কেস-বাই-কে এই ধরনের সতর্কতাগুলি অক্ষম করতে পারে, এই জাতীয় মানটিকেও সম্বোধন করতে হবে, যদি কোনও ব্যতিক্রমী কোড থাকে যা অন্যথায় মেনে চলবে না।


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

এটি কি আপনার মেকফাইলে রাখা উচিত এবং মান হিসাবে নয়?
বজর্কে ফ্রেইন্ড-হানসেন

@ বারজারকফ: শেষ পর্যন্ত বিকল্পগুলি হ্যাঁ, মেকফিলের মধ্যে চলে যাবে। তবে এটি স্ট্যান্ডার্ডের মধ্যে রাখার বিষয়টি হ'ল মানকে মান্য করা উচিত addressed উদাহরণস্বরূপ, বিকাশকারীদের কি সবসময় সিরিয়ালাইজেশন আইডি তৈরি করা উচিত? এটি বাধ্যতামূলক করা উচিত বা উপেক্ষা করা উচিত কিনা তা সিদ্ধান্ত নেওয়া দলটির হাতে to
ম্যাকনিল

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

9

আমি পছন্দ করি এমন কিছু মানদণ্ড (আমি জানি তাদের মধ্যে অনেকগুলি রয়েছে তবে আমি সেগুলি পছন্দ করি):

  • 80% ইউনিট পরীক্ষা কভারেজ
  • কোডের সম্মিলিত মালিকানা (সংকলক নয়, আপনার দলের সতীর্থদের দ্বারা পড়ার জন্য কোড লিখুন)
  • মন্তব্য লিখুন। আপনি কোন নতুনকে কী বলবেন তা লিখুন।
  • সহজবোধ্য রাখো

ইউনিট পরীক্ষার কভারেজ সম্পর্কিত প্রয়োজনীয়তাগুলি কোডিং মানগুলিতে যেতে পারে এমন এক সেরা জিনিস।
অ্যাডাম ক্রসল্যান্ড

পরীক্ষার কভারেজ সম্পর্কিত: কেন কেবল ৮০%? এটি কি আবার ৮০/২০ বিধিবিধানের উদাহরণ, যেখানে আপনার অভিজ্ঞতায় চূড়ান্ত ২০% অর্জনে আরও ১০০% বেশি সময় লাগবে? এছাড়াও, কভারেজ কি ধরণের? [উদাহরণস্বরূপ বিবৃতি কভারেজ? ফাংশন কভারেজ? সিদ্ধান্ত কভারেজ? শর্ত কভারেজ?]
ম্যাকনিল

@ ম্যাকনিল: হ্যাঁ এরকম কিছু। আমি দেখেছি যে 80% বেশিরভাগ শ্রেণীর জন্য "ভাল ধারণা" এবং এটি একটি ভাল নম্বর। আমি একবার 95% অর্জন করার চেষ্টা করেছি এবং এটি ছিল সময়ের অপচয়। অবশ্যই যদি কিছু শ্রেণীর জন্য 100% অর্জন করা সহজ হয় তবে এগিয়ে যান

সুতরাং যে বিবৃতি কভারেজ? দেখে মনে হচ্ছে অনেক সরঞ্জাম আপনাকে এর চেয়ে বেশি দেয় না। আপনি কোন সরঞ্জামটি ব্যবহার করেন?
ম্যাকনিল

আমি এটি বিল্ডিং সহ টেস্টড্রাইভন.net ব্যবহার করি

7

কোডিং স্ট্যান্ডার্ডগুলি যখন আপনি প্রথমবার কোডটি লিখছেন তখন কিছুটা সহায়তা করে , আপনি বা আপনার প্রতিস্থাপনের জন্য, 2 বছর পরে কোডটি আপডেট করার সময় তারা অনেক সহায়তা করে ।

আদর্শ মানটি কোডের দিকে নিয়ে যায় যেখানে আপনি কোডের যেকোন স্বেচ্ছাসেবী পৃষ্ঠায় ঝাঁপিয়ে পড়তে পারেন এবং প্রথম পঠনের মাধ্যমে এটি কী করছে তা সুনির্দিষ্টভাবে বুঝতে পারবেন কারণ

  • নামগুলি স্পষ্টভাবে বর্ণনা করে যে কী ডেটা ম্যানিপুলেট করা হচ্ছে,
  • বন্ধনীগুলি নিয়ন্ত্রণের প্রবাহকে পরিষ্কার করে দেয়,
  • মন্তব্যগুলি কোনও অ-সুস্পষ্ট অ্যালগরিদম ইত্যাদি ব্যাখ্যা করে explain

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

  • এই নিয়মটি কোডটি সঠিক কিনা তা নিশ্চিত করতে সহায়তা করে ?
  • এই বিধিটি কোডটি পরিষ্কার কিনা তা নিশ্চিত করতে সহায়তা করে ?

যদি উভয়ই সত্য না হয় তবে আইটেমটি কেবল স্বেচ্ছাসেবী এবং সম্ভবত অপ্রয়োজনীয়


আমি লিখি এমন একটি স্ট্যান্ডার্ডে আমি নিম্নলিখিত বিষয়গুলি অন্তর্ভুক্ত করব:

স্বচ্ছতার জন্য:

  • ফাইল সংগঠন: কোনও ফাইলের আইটেমগুলির জন্য একটি নির্দিষ্ট অর্ডার নির্দিষ্ট করে টিমটিকে সহজেই অন্যদের ফাইল নেভিগেট করতে দেয়। আপনার # ডেফাইনস বা কাঠামোর সংজ্ঞা অনুসন্ধান করতে হবে না।

  • নামকরণের কনভেনশন: ধারাবাহিক নামকরণের সাহায্যের পাঠযোগ্যতা। তবে অত্যধিক নির্দিষ্ট করে দেওয়া অনেকগুলি নিয়ম এড়ান, যা লেখার পক্ষে ক্ষয়ক্ষতি করে।

  • কোড গঠন। কোঁকড়া ধনুর্বন্ধনী প্লেসমেন্ট, ইনডেন্টেশন স্তরগুলি, ফাঁকা বনাম ট্যাব ইত্যাদি etc. হ্যাঁ, এটি শক্তিশালী ব্যক্তিগত পছন্দ হতে পারে তবে লক্ষ্যটি স্পষ্ট কোড। দলের জন্য সর্বোত্তম বিকল্পটি সন্ধান করুন এবং এটির সাথে আঁকুন।

সঠিকতার জন্য:

  • আপনার সমস্যার ধরণের সুনির্দিষ্ট সেরা অভ্যাস: মেমরির বরাদ্দ, বা সহনীয়তা, বা বহনযোগ্যতা সম্পর্কে নিয়ম।

  • "কনস্টেন্ট কারেক্টেনেস", এর সঠিক ব্যবহার staticএবং volatileইত্যাদি,

  • প্রিপ্রোসেসর ম্যাক্রোগুলি এবং ভাষার অন্যান্য সহজেই আপত্তিজনক বৈশিষ্ট্যগুলি সম্পর্কে বিধিগুলি।


6

অনুপ্রেরণামূলক, বাস্তববাদী ধারণা যা মানুষের চিন্তাভাবনা করে না বরং নেতিবাচক বিধিনিষেধের পরিবর্তে যা মানুষের চিন্তাভাবনা বন্ধ করে দেয়।

অন্যথায়, আপনি কোড বানর পেয়েছেন যারা কলা পরে যেতে ভয় পান ।


4

কোডিং স্ট্যান্ডার্ডে কী হওয়া উচিত? যত কম সম্ভব। কম বরং আরও। এবং ন্যায়সঙ্গত সঙ্গে, দয়া করে।

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

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


3

স্ট্যান্ডার্ড প্রয়োগের জন্য কোড পর্যালোচনার জন্য একটি পদ্ধতি। ওহ, এবং বাগগুলিও খুঁজে পেতে।


3

কিছু ভাল পুরানো সাধারণ জ্ঞান ভুল হবে না; অনেকগুলি কোডিং মানক দলিল রয়েছে যা অপ্রাসঙ্গিক পয়েন্টগুলিতে শ্রম দেয় (ফন্টের ধরণ এবং আকারের মতো আইটেমগুলি আমি দেখেছি এমন আরও চরম একগুলির মধ্যে একটি)।

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

দিনের শেষে স্পষ্ট এবং বোধগম্য কোড বিন্যাস বা টাইপোগ্রাফি সম্পর্কিত যে কোনও কঠোর নিয়মের চেয়ে বেশি গুরুত্বপূর্ণ।


ফন্টের ধরণ এবং আকার কীভাবে চেক হয়?
Jue Queue

@ এক্সপচ, এটি সেই সময়ে দৃশ্যত ছিল। সেই সময়ের মানদণ্ডে থাকার কারণটি দ্বিগুণ ছিল, মুদ্রকটি যখন মুদ্রিত হয়েছিল তখন ম্যানেজারের পক্ষে এটি পড়া সহজ ছিল এবং টাইপফেসটি ফাঁক করার সমস্যাগুলি সমাধান করার জন্য নির্দিষ্ট করা হয়েছিল (একক স্থানটি দাবি করা হয়েছিল) সুতরাং অক্ষরের প্রতিটি কলামের জন্য সারিবদ্ধ
গ্রম্পিমনকি

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

2

অন্যরা যেমন উল্লেখ করেছে, কোড টেস্টের কভারেজটি গুরুত্বপূর্ণ। আমি দেখতেও পছন্দ করি:

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

  • উন্নয়ন প্রক্রিয়া. কোডের আগে পরীক্ষা লিখবেন? ভাঙ্গা বিল্ডিং ঠিক করা কি উন্নয়নের চেয়ে অগ্রাধিকার গ্রহণ করে? কোড পর্যালোচনাগুলি কখন করা হয় এবং তাদের কী আচ্ছাদন করা উচিত?

  • উত্স কোড পরিচালনা। কখন চেক ইন করা হয়? ডিজাইন ডক্স এবং পরীক্ষার পরিকল্পনাগুলি কি সংশোধন-নিয়ন্ত্রিত? আপনি কখন শাখা করবেন এবং কখন আপনি ট্যাগ করবেন? আপনি কি পূর্ববর্তী বিল্ডগুলি রাখেন, এবং যদি তাই হয় কত / কত দিন?

  • স্থাপনার মান। একটি বিল্ড প্যাকেজ কীভাবে হয়? রিলিজ নোটে যাওয়ার কী দরকার? আপগ্রেড স্ক্রিপ্টগুলি কীভাবে তৈরি / নিয়ন্ত্রিত / চালিত হয়?

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


2

আমি মনে করি সম্বোধন করার জন্য দুটি জিনিস রয়েছে এবং আমি আসলে এগুলি আলাদাভাবে বিবেচনা করব কারণ সেগুলি একই পদ্ধতিতে যোগাযোগ করা যায় না, যদিও আমি উভয়কেই গুরুত্বপূর্ণ বলে মনে করি।

  • প্রযুক্তিগত দিক: যার ঝুঁকিপূর্ণ বা খারাপ-গঠন কোড এড়ানো লক্ষ্য (সংকলক / দোভাষী দ্বারা গ্রহণ করা হলেও)
  • উপস্থাপনা দিক: যা প্রোগ্রামটি পাঠকদের কাছে পরিষ্কার করার সাথে নিজেকে উদ্বেগিত করে

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

কোডিং স্ট্যান্ডার্ড

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

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

যুক্তি এবং ব্যতিক্রমগুলি অত্যন্ত গুরুত্বপূর্ণ, কারণ তারা কেন এবং কখন সংক্ষেপ করে।

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

সি ++ লোমযুক্ত বলে মনে করা সত্ত্বেও সুটার এবং আলেকজান্দ্রেস্কু কেবলমাত্র একশত আইটেমের একটি তালিকা রাখতে পেরেছিলেন;)

কোডিং স্টাইল

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

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

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

নামকরণের কনভেনশনের জন্য, আমি শ্রেণি / প্রকারগুলি সহজেই ভেরিয়েবল / বৈশিষ্ট্যগুলি থেকে আলাদা করার চেষ্টা করব।

আমি এই "বিভাগগুলি" এর মতো শ্রেণীবদ্ধ করি this

  • সংক্ষিপ্ত থেকে দীর্ঘ পদ্ধতির পছন্দ: দীর্ঘায়িত বিষয়টির সাথে একমত হওয়া সাধারণত কঠিন
  • ইন্ডেন্টেশন হ্রাস করতে প্রারম্ভিক রিটার্ন / চালিয়ে যাওয়া / বিরতি পছন্দ করুন

বিবিধ?

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


তবে এগুলি আসলে প্রয়োগ এবং প্রয়োগ না করা হলে কিছুই নয় ।

কোড পর্যালোচনা চলাকালীন যে কোনও লঙ্ঘন করা উচিত, এবং যদি কোনও লঙ্ঘন অসামান্য হয় তবে কোনও কোড পর্যালোচনা ঠিক হবে না:

  • নিয়মের সাথে মেলে কোড ঠিক করুন
  • নিয়মটি ঠিক করুন যাতে কোডটি আর দাঁড়ায় না

স্পষ্টতই, একটি নিয়ম পরিবর্তন করার অর্থ নেতাদের কাছ থেকে "এগিয়ে যান"।


2

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

ইন্টারফেস সদস্যদের প্রয়োগকারী বিভাগে এখানে একটি উদাহরণ রয়েছে যা স্পষ্টভাবে এর মধ্যে নিম্নলিখিত আইটেম রয়েছে (নোট আমি বার্ভিটির পক্ষে যুক্তি বাদ দিয়েছি)

ইন্টারফেস সদস্যদের এরকম দৃ strong় কারণ না রেখে সুস্পষ্টভাবে প্রয়োগ করা এড়িয়ে চলুন

ইন্টারফেসের সদস্যদের স্পষ্টভাবে বাস্তবায়নের বিষয়ে বিবেচনা করুন যদি সদস্যদের কেবল ইন্টারফেসের মাধ্যমে আহ্বান করা হয়।

সুরক্ষা সীমানা হিসাবে সুস্পষ্ট সদস্যদের ব্যবহার করবেন না

না কোনো সুরক্ষিত ভার্চুয়াল সদস্য অফার করে একই কার্যকারিতা> স্পষ্টভাবে বাস্তবায়িত সদস্য হিসেবে যদি কার্যকারিতা বোঝানো হয় উদ্ভূত শ্রেণীর দ্বারা বিশেষ করা প্রদান।

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


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

1

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


+1: অভিজ্ঞ এবং বিকাশকারীরা এমনকি এটি এবং বহুলিপি পড়া বিবেচনাগুলি প্রায়শই অজানা বা ভুল বোঝা যায়।
TMN

1

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

টেমপ্লেট। সি ++ ধরণের নয়, তবে কপি-পেস্ট করার জন্য এবং লাইভ দিয়ে পূর্ণ করার জন্য। আপনার কাছ থেকে অনুলিপি করার কোনও রেফারেন্স পাওয়া গেলে 24-লাইনের বয়লারপ্লেট মন্তব্যটি পাওয়া খুব সহজ।


1

এক নম্বর বৈশিষ্ট্য: দুটি পৃষ্ঠাতে পরম সর্বোচ্চ।

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


1

কোডিং মানগুলি আসলে বেশ কয়েকটি আইটেম:

কোডিং কনভেনশনস

  • এই বিষয়গুলির জন্য প্রাক্তনের জন্য "কোড বেসের ধারাবাহিকতা" এর অন্য কোনও কারণের প্রয়োজন নেই। ব্যক্তিগত সদস্যের ভেরিয়েবলগুলিতে '_' ব্যবহার করতে বা না করতে।
  • বেশ কয়েকটি সঠিক পন্থা থাকতে পারে। ধারাবাহিকতার জন্য কেবল একটি বাছাই করা দরকার। প্রাক্তন জন্য ব্যতিক্রম বা ত্রুটি কোডগুলি ব্যবহার করে ত্রুটিগুলি পরিচালনা করা।

সেরা অনুশীলন

  • এই আইটেমগুলির সবসময় কিছু পরিষ্কার উদাহরণ সহ একটি ভাল কারণ প্রয়োজন

প্রাক্তন জন্য চেষ্টা করার পরে কখনও খালি ক্যাচ ছেড়ে যাবেন না

try { Foo(); } catch { //do nothing }

1) যদি ফু দ্বারা নিক্ষেপ করা একটি ব্যতিক্রম থাকে () এটি অনুসরণ করে এমন ফাংশনগুলিতে অন্যান্য সমস্যার কারণ হতে পারে, যে ধরে নিয়েছিল যে foo সফল ছিল।

2) গ্লোবাল ত্রুটি হ্যান্ডলারটি যখন ব্যতীত হয় তখন ব্যতিক্রম সমর্থন দলকে অবহিত করবে না

  • "ডিফেন্সিভ কোডিং" এর অনুশীলনগুলি কভার করে যেমন আপনার অনুমানগুলি পরীক্ষা করার জন্য অ্যাসেটস ব্যবহার করে।

কোডিং পরিবেশ

  • পুরো টিম ব্যবহার করে এমন সরঞ্জামগুলি। প্রাক্তন জন্য ভিএস ২০১০, পুনঃভাগ, কিল, ইত্যাদি ..

0

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

বিন্যাসে কী থাকতে হবে,

  • কিভাবে ভেরিয়েবল, ম্যাক্রো, ধ্রুবক, আক্ষরিক, ফাংশন ইত্যাদির নাম রাখবেন
  • কীভাবে {,}, (,), [,] রাখে যখন এটি আসে if, অন্য কোনও উদ্দেশ্যে ফাংশন বডি, স্টেটমেন্ট ব্লক,
  • ইন্ডেন্টেশন কত প্রশস্ত হওয়া উচিত,
  • পাঠ্যের একটি লাইন কত অক্ষর অনুমোদিত allowed
  • কোডটি প্রত্যাখ্যান করা / রিফ্যাক্টরিংয়ের জন্য প্রেরণের আগে কত স্তরের ইন্ডেন্টেশন অনুমোদিত
  • রিফ্যাক্টরিংয়ের জন্য ফেরত পাঠানোর আগে ফাংশনটিতে কত লাইনের কোড অনুমোদিত
  • রিফ্যাক্টরিংয়ের জন্য ফেরত পাঠানোর আগে কোনও ফাংশন নিতে পারে সর্বাধিক সংখ্যক যুক্তি
  • কোনও ক্রিয়াকলাপ সংক্ষেপে এটি কী করে তা ব্যাখ্যা করার আগে কয়েক লাইনের মন্তব্যে, যদি স্ক্রিন কোডে শরীরের কোনও পৃষ্ঠা অতিক্রম করতে হয়; ফাংশনের শরীরে কোডটিতে কীভাবে বস্তুটি অর্জন করা যায় তা রেখে leaving

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


প্রায় কয়েক বছর ধরে কোড বিউটিফায়ার রয়েছে। আপনার ভাষার জন্য গুগল একটি, আপনি একটি খুঁজে পাবেন।
gbjbaanb

0

আমি গুগল জাভাস্ক্রিপ্ট স্টাইল গাইড পছন্দ করি

এটির নির্দেশিকাগুলিতে এর সংক্ষিপ্তসারগুলিতে এখনও আপনার যদি প্রয়োজন হয় তার বিশদ রয়েছে।


আপনি এটি কি করে সে সম্পর্কে আরও ব্যাখ্যা করতে আপত্তি করবেন এবং আপনি কেন জিজ্ঞাসিত প্রশ্নের উত্তর হিসাবে এটি সুপারিশ করবেন? "লিঙ্ক কেবল-উত্তর" বেশ স্ট্যাক এক্সচেঞ্জ এ স্বাগত জানাই হয় না
মশা

-1

স্ব ডকুমেন্টিং কোড (মন্তব্য, ভেরিয়েবল নাম, ফাংশন নাম, ইত্যাদি)

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