কোডিং গাইডলাইন: পদ্ধতিগুলিতে 7 টির বেশি বিবৃতি থাকা উচিত নয়?

Question

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

AV1500

পদ্ধতিগুলি 7 টি স্টেটমেন্টের বেশি হওয়া উচিত নয় এমন একটি পদ্ধতিতে 7 টির বেশি বিবৃতি প্রয়োজন যা অনেক বেশি করে চলেছে বা এর অনেক বেশি দায়বদ্ধতা রয়েছে। কোডটি কী করছে তা বোঝার জন্য মানব মনকে সঠিক বিবৃতি বিশ্লেষণ করাও প্রয়োজন। স্ব-ব্যাখ্যাকারী নাম সহ এটি একাধিক ছোট এবং কেন্দ্রীভূত পদ্ধতিতে ভেঙে দিন।

আপনারা কি বেশিরভাগ লোকেরা এই বিধি অনুসরণ করেন? এমনকি যদি একটি নতুন পদ্ধতি তৈরি করার থেকে কিছুটা বাঁচানো যায় না (আপনার কোডটি এখনও ডিআরওয়াই ) বহুলাংশে পঠনযোগ্যতা বাদ দিয়ে? এবং আপনার সংখ্যা এখনও 7 হিসাবে কম? আমি 10 এর দিকে আরও ঝোঁক চাই।

আমি বলছি না যে আমি সমস্ত জায়গা জুড়ে এই নিয়ম লঙ্ঘন করেছি - বিপরীতে, আমার পদ্ধতিগুলি 95% ছোট এবং মনোনিবেশযুক্ত তবে বলছেন যে আপনি কখনই এই নিয়ম লঙ্ঘন করবেন না আমাকে সত্যই দূরে সরিয়ে দিয়েছে।

আমি সত্যই জানতে চাই যে প্রত্যেকে এই বিধি লঙ্ঘন করার বিষয়ে কখনই চিন্তা করে (এটি কোডিং স্ট্যান্ডার্ডের একটি '1' - যার অর্থ এটি কখনও করবেন না)। তবে আমি মনে করি যে এমন কোনও কোডবেস খুঁজে পেতে আপনার সমস্যা হবে যা এটির নয়।

Comments

তারা কি caseকোনও গানে বিবৃতি গণনা switchকরে? যাইহোক, এটি একটি বোকা, অকেজো প্রয়োজন ছাড়া কিছুই নয় nothing যারা এটি লিখেছেন তারা প্রোগ্রামিং সম্পর্কে কিছুই জানেন না।

— এসকে-যুক্তি

কোডিং স্ট্যান্ডার্ডে '1' হওয়া উচিত এমন একমাত্র নিয়মটি হ'ল "আপনি নুনের দানার সাথে সমস্ত কোডিং নির্দেশিকা গ্রহণ করবেন।"

— মাইক নাকিস

@ এসকে-লজিক 1027 হয় খারাপ নয় - আপনার যদি খালি স্ট্রিংটিকে নাল স্ট্রিংয়ের সমান হিসাবে বিবেচনা করতে হয় তবে মজাদার রাইটিং কোডটি অবশ্যই অনুপস্থিত ডেটা হ্যান্ডেল করতে হবে।

— কোয়ান্ট_দেব

এই গাইডলাইনটি পড়ার সময় আমি কোনও কোডবেস পূর্ণরূপে প্রত্যাশা করব: অকার্যকর ডসোমথিং () {ডোসোমথিং ফার্স্টসভিনলাইনস (); DoSomethingSecondSevenLines (); DoSomethingThirdSevenLines (); ইত্যাদি; }

— tugs

.NET ফ্রেমওয়ার্কের বেশিরভাগ প্রতিফলনের চেষ্টা করুন এবং দেখুন যে কতগুলি পদ্ধতিতে 7 টিরও কম বক্তব্য রয়েছে ...

— ডেভিড বোইক

Answer 1

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

Comments

"প্রক্সি দ্বারা মাইক্রো ম্যানেজমেন্ট" এর জন্য +1। আমি সন্দেহ করি যে কেউ "7 প্লাস বা বিয়োগ 2" রুল ( en.wikedia.org/wiki/… ) সম্পর্কে পড়েছেন এবং দীর্ঘমেয়াদী স্টোরেজ সহ বিভ্রান্ত স্বল্পমেয়াদী তথ্য ধারণাকে যেমন কোনও কোড সম্পাদক আপনি জানেন।

— ফ্লাফি

কোনও বোধগম্যভাবে চিন্তা-ভাবনা করা স্ট্যান্ডার্ড কোডে ম্যাজিক সংখ্যা নিষিদ্ধ করে, তাই না? আপনি ভাববেন যে কোডিং স্ট্যান্ডার্ডটিও সেই মান ধরে রাখা হবে held 7 নম্বরটি অবশ্যই এটির কাছে অবশ্যই একটি "জাদু" গুণ রয়েছে।

— অ্যাডাম ক্রসল্যান্ড

যদি আপনার দস্তাবেজের শিরোনামটি " GuidlinesC # 3.0 এবং 4.0 এর জন্য কোডিং না" হয় তবে আপনার উত্তরটি আরও

— অ্যান্ডি

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

— Spoike

আমি এই দস্তাবেজটি ডাউনলোড করেছি এবং এটির মাধ্যমে সন্ধান শুরু করি। ১.6-তে এটি উল্লেখ করেছে: "নথিতে এই কথা বলা হয়নি যে প্রকল্পগুলি অবশ্যই এই নির্দেশিকাগুলি মেনে চলবে, না তাও বলে না যে কোন দিকনির্দেশনা অন্যদের চেয়ে বেশি গুরুত্বপূর্ণ However তবে আমরা প্রকল্পগুলিকে কোন দিকনির্দেশনা গুরুত্বপূর্ণ তা সিদ্ধান্ত নিতে উত্সাহিত করি, কোন প্রকল্প কী বিচ্যুতি ঘটবে ব্যবহার করুন, সন্দেহ দেখা দেওয়ার ক্ষেত্রে পরামর্শক কে এবং উত্স কোডের জন্য কী ধরণের লেআউট ব্যবহার করা উচিত "" যদিও 1 এর অর্থ "এমন নির্দেশিকাগুলি যা আপনার কখনই এড়ানো উচিত নয় এবং সমস্ত সমাধানের জন্য প্রযোজ্য হওয়া উচিত", আপনি এটিকে পরিবর্তন করতে বেছে নিতে পারেন।

— ক্রিশ

Answer 2

জিনিসগুলি সামান্য পদ্ধতিতে বিভক্ত করা সাধারণত ভাল ধারণা। তবে গুরুত্বপূর্ণ বিষয়টি এমন জিনিসগুলিকে বিভক্ত করা যেখানে এটি বোঝা যায়।

যদি এটি বিভক্ত করার কোনও অর্থ হয় না, তবে বিচ্ছেদ করবেন না। এটি প্রায়শই কিছু পদ্ধতি বা জিইউআই কোডের ক্ষেত্রে হয়।

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

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

Comments

দুর্দান্ত উত্তর। শেষ দুটি লাইন বিশেষত পয়েন্টটি বাড়ির দিকে চালিত করে।

— জোনাট্রন

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

— hugomg

কোড সম্পূর্ণ ভাল স্টাফ পূর্ণ। প্রত্যেক প্রোগ্রামারকে প্রতিদিন দুপুরের খাওয়ার সময় এর একটি টুকরো খাওয়া উচিত।

— ডেডালনিক্স

Answer 3

এটি থাম্বের নিয়ম হিসাবে বিবেচনা করা উচিত।

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

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

Comments

"80/100/120" কলামগুলির সীমাটি তাই আমরা কোডটি পড়তে পারি। বেশিরভাগ টার্মিনালগুলি 80 টি কলামে খোলা থাকে এবং প্রতিটি পাঠক যখনই কোডটি পড়তে চান তখন তাদের পাঠককে তাদের টার্মিনালের আকার পরিবর্তন করার চেয়ে লেখককে 80 টি কলামে মোড়ানো করার চেষ্টা কম হয়। অন্যান্য সীমাগুলির বিপরীতে, এন-কলামের সীমা কোডের শব্দার্থকে প্রভাবিত করে না, এটি একটি সম্পূর্ণরূপে শৈলীগত নিয়ম; "4-স্পেসের ট্যাবগুলি ব্যবহার করুন" বা "তাদের নিজস্ব লাইনে ফাংশনগুলির জন্য খোলার ধনুর্বন্ধনী রাখুন" হিসাবে একই বিভাগে।

— ডায়েটারিচ এপ্প

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

— লঙ্ঘনেরও

একবিংশ শতাব্দীতে, আমার আইডিইতে "গতিশীল শব্দ মোড়ানো" নামে এই বৈশিষ্ট্যটি রয়েছে called

— গিরিগিরিস আন্দ্রেসেক

@ গিরিগিরিঅ্যান্ডসেক: তবে প্রত্যেকে আপনার আইডিই সর্বদা ব্যবহার করে না: আমরা গিটহাবের কোডগুলিতে, টার্মিনালগুলিতে less, ভিতরে vimএবং সাথে দেখি emacs; এবং স্বয়ংক্রিয়ভাবে মোড়ক সেরা বলে মনে হচ্ছে। কোডিং মানগুলি আপনার সুবিধার জন্য নয়, তারা দলে কাজ করে এমন লোকদের সুবিধার্থে।

— ডায়েটারিচ এপ্পি

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

— অকর্মা

Answer 4

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

Comments

পাঠযোগ্যতার জন্য +1। কোনও পদ্ধতি 20, 30 বা এমনকি 50 লাইন দীর্ঘ কিনা তা বিবেচ্য নয়। ডিআরওয়াই এবং এসআরপি যদি আপনার লক্ষ্য হয় তবে পদ্ধতিগুলি দীর্ঘায়ু দিক থেকে কিছুটা কম বলে মনে হচ্ছে তা বিবেচ্য নয় ... যদিও বেশিরভাগ ক্ষেত্রেই আপনি দেখতে পাবেন যে আপনি যত বেশি পাঠযোগ্য আপনার কোড তৈরি করার চেষ্টা করছেন, আপনার পদ্ধতিগুলি সংক্ষিপ্ত স্বাভাবিকভাবে পরিণত হবে।

— এস.রোবিনস

Answer 5

এটা আনুমানিক

এই ধরণের নিয়মগুলি খুব আক্ষরিক অর্থে নেওয়া উচিত নয়। তারা বলতে পারত " পদ্ধতিগুলি সংক্ষিপ্ত হওয়া উচিত "। তবে কিছু লোক "1 পৃষ্ঠার কম" এবং অন্যদের "সর্বাধিক 2 লাইন" হিসাবে ব্যাখ্যা করেছিলেন।

আমি ধরে নেব যে তারা আপনাকে একটি মোটামুটি ধারণা দেওয়ার জন্য "7 টি স্টেটমেন্ট" বলেছিল (যদিও আমি মনে করি তাদের "প্রায় 7" বলা উচিত ছিল)। আপনার যদি একবারে 9 বার প্রয়োজন হয় তবে এটি ঘামবেন না। তবে আপনি যদি 20 টি হিট করেন তবে আপনি জানতে পারবেন আপনি এই নিয়মের জন্য সঠিক বলপার্কে নেই।

Comments

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

— ব্রায়ান

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

— নাথান লং

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

— ব্রায়ান

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

— Spoike

Answer 6

7 সম্পূর্ণরূপে স্বেচ্ছাচারিত সংখ্যা যা একেবারেই তাত্পর্য নয়।

সাইক্লোমেটিক জটিলতা বিবৃতি সংখ্যার চেয়ে বড় সমস্যা। আমি একটি একক পদ্ধতিতে 100s স্টেটমেন্ট রয়েছে এমন কোড দেখেছি (যা আমি ভয়ানক বলে মনে করি) তবে এটির একটি চক্রবৃত্তীয় জটিলতা ছিল এবং এটি সত্যই কেবল 1 টি কাজ করেছিল। সেখানে অনেকগুলি পদক্ষেপ ছিল। আমরা এটিকে ছোট পদ্ধতিতে বিভক্ত করার বিষয়ে আলোচনা করেছি, তবে এই পদ্ধতিগুলি কেবল এই একটি পদ্ধতি দ্বারা ডাকা হবে।

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

উদাহরণস্বরূপ একটি স্যুইচ / কেস স্টেটমেন্ট নিন। আপনার যদি 7 টিরও বেশি সম্ভাব্য মান থাকে তবে আপনার মূল্যায়নকে একাধিক পদ্ধতিতে ভেঙে ফেলতে হবে? অবশ্যই না, এটি নির্বোধ হবে।

7 টির নীচে স্টেটমেন্টের সংখ্যা রাখার জন্য কৃত্রিমভাবে কোডটিকে আরও পদ্ধতিতে ভঙ্গ করা আপনার কোডটিকে আরও খারাপ করে।

গাইডলাইনটি হওয়া উচিত প্রতিটি পদ্ধতির 1 টি কাজ করা উচিত এবং আপনার কোডটি DRY রাখা উচিত।

Comments

+1: স্বেচ্ছাসেবক সীমাগুলি কেবল স্বেচ্ছাকৃতভাবে কার্যকর। একটি পদ্ধতিতে একটি বিমূর্ত স্তরের একক সুসংগত ক্রিয়াকলাপ থাকা উচিত। এ জাতীয় পারমাণবিক ইউনিট ভাঙ্গা কোডটিকে আরও জটিল করে তোলে, কোড বোঝা শক্ত করে তোলে।

— অ্যালন গুরালেনেক

ডিআরওয়াই ওভার রেটযুক্ত। বেশিরভাগ সময় এর অর্থ এমন কিছুর দু'টি দিককে শক্তভাবে মিলিত করা যা শক্তভাবে মিলিত হওয়া উচিত নয়।

— ব্র্যাড টমাস

Answer 7

ঠিক আছে, এটি কিছুটা নির্ভর করে। আমি প্রচুর কোড লিখি যা ডেটাবেস অ্যাক্সেস করে। ব্যতিক্রম হ্যান্ডলিংয়ের জন্য বয়লার প্লেট কোডটি অনেক ক্ষেত্রে সাতটি বিবৃতি দীর্ঘ। আমি বলব যে আপনার কার্যকারিতাটির একটি উদ্দেশ্য রয়েছে তা নিশ্চিত করা সেরা নির্দেশিকা

Comments

আপনি নিজের পদ্ধতিতে বয়লারপ্লেট কোডটি বিমূর্ত করতে পারবেন না?

— ইরজিয়াং

আমি পোস্ট করার পরে লক্ষ্য করেছি যে এটি সি # জাভা নয় তবে আমি এই জাতীয় জিনিসটি নিয়ে ভাবছি। stackoverflow.com/questions/321418/…

— জয়দি

@ জর্জং: পারো! এটি জাভাতে খুব কুৎসিত, যেহেতু আপনাকে প্রতিটি বেনাম একটি বেনাম শ্রেণিতে আবদ্ধ করতে হবে, তবে এখনও করার মতো মূল্য রয়েছে। সি # তে কুরুচিপূর্ণ নয়, এবং অবশ্যই করার মতো মূল্যবান।

— কেভিন cline 21

ব্যক্তিগতভাবে, আমি আরও পঠনযোগ্য হওয়ার জন্য স্টাট লাইন কোডের কয়েকটি অতিরিক্ত লাইন পেয়েছি। তবে সম্ভবত এটি আমিই।

— জয়দী

@ জায়েদী লিঙ্কযুক্ত প্রশ্নটি সাধারণ তবে অদ্ভুত অনুশীলন দেখায়: একটি ব্যতিক্রম মোড়ানো এবং লগিং। পরবর্তী স্তরে আপনিও একই কাজটি করতে পারেন ... এইভাবে লগের মধ্যে একক ব্যতিক্রম একাধিকবার উপস্থিত হয়। পদ্ধতিটি নিক্ষেপ করার বিষয়টি ঘোষণা করা ভাল এবং আপনি 3 টি লাইন সংরক্ষণ করেছেন। একটি সাহায্যকারী পদ্ধতি উভয় বন্ধের লিখুন psএবং rsএবং অন্য এক সেভ করুন। অথবা এমন একটি পদ্ধতি লিখুন List<Row> readDb(String sql, Object... args)যা পুরো কাজটি করে (শুধুমাত্র ফলাফলের জন্য মেমরির মানানসই কাজ করে, তবে খুব বেশি ডেটা আনার ফলে বোঝা যায় যে কোনওভাবেই ডিবিতে কাজটি করা উচিত)।

— মার্টিনাস

Answer 8

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

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

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

Answer 9

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

কৌশলটি এটি উল্লম্বভাবে বিভক্ত না করা (কেবল একটি পদ্ধতিতে এক পর্যায়ে চিমটি মেরে একটি নতুন শুরু করুন)। কৌশলটি ইউনিট পরীক্ষার মতো, শুরু থেকেই এই জাতীয় নিয়মটি মনে রাখা যাতে আপনি আসলে আরও ভাল ডিজাইন করেন, 3 বা 4 স্টেটমেন্ট মিড-মেথডটিকে অন্য পদ্ধতিতে ছাড়িয়ে যান কারণ কোনও পদ্ধতিতে কল থাকার চেয়ে আপনি কী করছেন তার বর্ণনা দেয় call আপনার কোডের মাঝখানে সেই 3 বা 4 টি স্টেটমেন্ট।

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

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

সারাংশ? যদি "আমি 7 টিরও বেশি স্টেটমেন্ট ব্যবহার করি" এর কোড গন্ধের সাথে "7 টিরও কম স্টেটমেন্ট ব্যবহার করুন" এর ডিজাইনের গন্ধটির সাথে তুলনা করা হয়, তবে আমি কোডের গন্ধটি দূর করব।

Answer 10

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

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

আমি কখনও বিশেষজ্ঞ হওয়ার দাবিও করি নি। তবে আমি এই পেশায় এখন প্রায় 15 বছর ধরে রয়েছি, প্রায় 4 বছরের সি ++ অভিজ্ঞতা এবং 11 বছরের সি # অভিজ্ঞতা। এটি মূলত শিল্প শক্তি সি ++ এর উপর ভিত্তি করে তৈরি হয়েছিল, তবে আমি তখন থেকেই সম্প্রদায়টির ইনপুট দিয়ে এটি পরিমার্জন করছি।

নির্বিশেষে, আমি যে বিষয়টি উত্থাপনের চেষ্টা করছিলাম তা হ'ল আপনার নিজের জন্য চিন্তা করা উচিত। আপনি যদি মনে করেন যে 7 টি বিবৃতি নির্দেশিকা কার্যকর নয়, কেবল এটি আরও দীর্ঘ করা। হেক, এমনকি আমি একবারে একবারে সেই নির্দেশিকাটি লঙ্ঘন করি। আমি কেবল এটি সচেতনভাবে লঙ্ঘন করেছি এবং ফলাফলগুলি স্বীকার করছি।

Comments

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

— কনরাড রুডলফ

Answer 11

প্রথমত: এটি একটি নির্দেশিকা, কোনও নিয়ম নয়। এটিকে নির্দেশিকা বলা হয়, সুতরাং দয়া করে এটির মতো আচরণ করুন। এটি বোঝায় যে আপনার নিজস্ব রায়ও প্রয়োজনীয় (বরাবরের মতো)

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

Answer 12

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

Comments

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

— luiscubal

আমি জানি, অনেক দেরি না হওয়া পর্যন্ত আমি ভেবে দেখিনি। তবে আমি এখনও আমার মস্তিষ্কের ফুসফুস দেখানোর জন্য আপনাকে +1 করব।

— ফ্যালকন 165o

Answer 13

আপনি মিশ্রণটিতে ব্যতিক্রম হ্যান্ডলিং যুক্ত করার সময় খুব মূর্খ।

"চেষ্টা করুন, ধরুন, অবশেষে" পরে আপনি পদ্ধতি অনুসারে চারটি স্টেটমেন্ট রেখে গেছেন!

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

Comments

আমি মনে করি এটি নিরাপদে try/ catch/ finallyসি সি # তে বিবৃতি নয়। একমা -৩৪৪ § ১২.৩.৩.১৫ এবং আশেপাশের বিভাগগুলি দেখুন। (সংক্ষেপে) " ফর্মটির একটি চেষ্টা-ধরা-শেষ অবধি : চেষ্টা করুন-ব্লক ধরা চেষ্টা করুন (...) ক্যাচ-ব্লক-এন অবশেষে অবরুদ্ধ করুন "

— একটি সিভিএন

ঠিক আছে, যেমনটি আমি আগেই বলেছি, এটি এমন সিদ্ধান্ত যা আপনাকে বার বার করতে হবে। তবে আপনার নির্দিষ্ট উদাহরণটি অবজেক্ট-ওরিয়েন্টেড ডিজাইন সঠিকভাবে না করার একটি উদাহরণ হতে পারে। আপনি নিজের স্ক্রিনটিকে একাধিক নিয়ন্ত্রণে ভাগ করতে চাইতে পারেন যা বৈধতা নিজেরাই করে।

— ডেনিস ডুমম

@ ডেনিস - সত্য, খুব দীর্ঘ সময় ধরে এইচটিএমএল ফর্মগুলি করছেন!

— জেমস অ্যান্ডারসন

@ জেমস এবং এই নির্দিষ্ট গাইডলাইনটির জন্যই এটি উদ্দেশ্য। আপনাকে বিকল্প, সম্ভাব্যতর উন্নত, সমাধান সম্পর্কে ভাবার চেষ্টা করা হচ্ছে।

— ডেনিস ডুমিন

Answer 14

প্রশ্নটি "নির্দেশিকাগুলি" দিয়ে "বিধিগুলি" বিভ্রান্ত করছে। বিধিগুলি মান্য করা বোঝায় - নির্দেশিকা হ'ল এমন উপদেশ যা আপনাকে কী করছে তা বিবেচনা করার জন্য এবং যদি এটি সত্যিই আরও ভাল উপায়ে করা যেতে পারে।

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

পূর্ববর্তী উত্তরদাতা দেখিয়েছেন যে নির্দেশিকাগুলির লেখকরা কখনই তাদের কৌতুকপূর্ণভাবে প্রয়োগ করার ইচ্ছা করেনি এবং তাদের নথিতে সেই প্রভাবের বিবৃতি অন্তর্ভুক্ত করেছিলেন।

Answer 15

আমি উপরের মতামত soe সঙ্গে একমত। আমার জন্য ar স্বেচ্ছাসেবী এবং এমন কিছু ভাষায় কার্যকর হতে পারে যেখানে রুবি, তবে সি #, জাভা, সি ++ এর মতো ভাষার ক্ষেত্রে আমি এই "7 লাইন" কনভেনশনকে সন্দেহ করি। আমি আপনাকে একটি উদাহরণ দিচ্ছি। আমার বর্তমান অ্যাপ্লিকেশনটিতে 22 টি পাঠ্য ক্ষেত্র রয়েছে এবং আমি সার্ভারের পাশের বৈধতা দিয়েছি। পদ্ধতিটিকে ভ্যালিডইনপুট () বলা হয় এবং আমার পছন্দটি চেকইমেইল ফর্ম্যাট () এর মতো জটিল কিছু বৈধ না করে না থাকলে একটি পদ্ধতিতে সমস্ত ক্ষেত্রই বৈধ হয়ে যায়। সুতরাং মূলত আমার বৈধতা ইনপুট পদ্ধতি কোডটি জটিল বৈধতার মাঝে মাঝে কল সহ 108 টি লাইন।

এখন ভাবুন যে আমি প্রতিটি ক্ষেত্রকে বৈধতা দেওয়ার জন্য 25 টি পদ্ধতি কল করেছি। যদি কোনও নতুন বিকাশকারী আসে তবে তাকে 25 পদ্ধতির মধ্য দিয়ে ঝাঁপিয়ে পড়তে মূল পদ্ধতির বাইরে যেতে হবে যা ফলস্বরূপ কয়েকজনকে কল করতে পারে। বড় প্রকল্পে তিনি হারিয়ে যেতে বাধ্য।

আমার কোডটি পরিষ্কার করার জন্য আমি যা করছি তা হ'ল পরিষ্কার মন্তব্য প্রদান করে যা মূলত এই 4 টি লাইন কী করছে -

বৈধতা ইনপুট (UserObj ব্যবহারকারী) {

// প্রথম নামটি বৈধ করুন ....... ......

// শেষ নামটি বৈধ করুন ...... ......

// ইমেল বৈধ করুন ..... // ইমেল ফর্ম্যাট নিয়মিত এক্সপ্রেসন চেক করতে ইমেল ফর্ম্যাট (); .... .....

এবং এইভাবে ..

Comments

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

— ডেনিস ডুমিন

Answer 16

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

কোডের লাইনগুলি জটিলতার একটি স্বেচ্ছাসেবী গণনা। এক্সটেনশন পদ্ধতিগুলির সাথে আমি কোড তৈরি করতে পারি

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

Comments

আবার একক পদ্ধতিতে বেশি কিছু করার একটি দুর্দান্ত উদাহরণ। প্রায় প্রতিটি পাল্টা-যুক্তিতে লোকেরা একক দায়িত্বের নীতি লঙ্ঘন করছে (কোনও পদ্ধতির প্রসঙ্গে)।

— ডেনিস ডুমিন

Answer 17

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

আমি বর্তমানে 550 লাইনের কোডের একটি পদ্ধতিতে প্রচুর পরিমাণে বিবৃতি দিয়ে দেখছি এবং যদি অবিরত থাকে এবং এতে বুনে ফিরে আসে। ফালতু. প্রোগ্রামার যদি কেবল তখনই চিন্তা করত যে সে কী করছে ...