আপনার জন্য একটি পদ্ধতির আদর্শ দৈর্ঘ্য কত? [বন্ধ]

Question

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

ইন ক্লিন কোড: এজাইল সফটওয়্যার কারিগরি একটি হ্যান্ডবুক , রবার্ট মার্টিন বলেছেন:

ফাংশনগুলির প্রথম নিয়মটি হ'ল সেগুলি ছোট হওয়া উচিত। ফাংশনগুলির দ্বিতীয় নিয়মটি হ'ল সেগুলি তার চেয়ে ছোট হওয়া উচিত। ফাংশনগুলি 100 লাইন দীর্ঘ হওয়া উচিত নয়। ফাংশনগুলি খুব কমই 20 লাইন দীর্ঘ হওয়া উচিত।

এবং তিনি জাভা কোড থেকে একটি উদাহরণ দিয়েছেন যা তিনি কেন্ট বেক থেকে দেখেন:

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

এটি দুর্দান্ত শোনায় তবে অন্যদিকে কোড কমপ্লিটে স্টিভ ম্যাককনেল খুব আলাদা কিছু বলেছেন:

রুটিনটি 100-200 লাইন পর্যন্ত জৈবিকভাবে বেড়ে ওঠার অনুমতি দেওয়া উচিত, দশকের দশক প্রমাণ থেকে জানা যায় যে এর দৈর্ঘ্যের রুটিনগুলি আর ত্রুটির প্রবণতা না করে এর পরে খাটো রুটিনগুলি প্রবণ করে।

এবং তিনি একটি সমীক্ষায় একটি রেফারেন্স দেন যা বলে যে রুটিনগুলি lines৫ টি লাইন বা দীর্ঘতর বিকাশ করার জন্য সস্তা।

সুতরাং বিষয়টি সম্পর্কে মতবিরোধগুলি ঘুরিয়ে দেওয়ার সময়, আপনার জন্য কি কার্যকরী সেরা অনুশীলন রয়েছে?

Comments

ফাংশনগুলি বোঝা সহজ হওয়া উচিত। দৈর্ঘ্যটি পরিস্থিতিতে থেকে অনুসরণ করে অনুসরণ করা উচিত।

— হেন্ক হলটারম্যান

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

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

এবং, আপনি যদি আপনার ফাংশনগুলির জটিলতা সীমাবদ্ধ করতে চান তবে আপনার চক্রবৃত্তীয় জটিলতা তাদের দৈর্ঘ্য নয়, পরিমাপ করা উচিত । switch100 টি caseশর্তযুক্ত একটি বিবৃতি ifএকে অপরের মধ্যে নেস্টেড 10 টি স্তরের বক্তব্যের চেয়ে বেশি রক্ষণাবেক্ষণযোগ্য ।

২০০৮ সালের বব মার্টিনের দৃষ্টিভঙ্গি, ১৯৯৩ সালের স্টিভ ম্যাক কনেলিজ "" ভাল কোড "কী তা সম্পর্কে তাদের বিভিন্ন দর্শন রয়েছে এবং আইএমএইচও বব মার্টিন কোডের মানের একটি উচ্চ স্তরের অর্জনের চেষ্টা করেছেন।

— ডক ব্রাউন

Answer 1

ফাংশন সাধারণত সংক্ষিপ্ত হওয়া উচিত, জাভা বা সি # তে কোডিং করার সময় 5-15 লাইনের মধ্যে আমার ব্যক্তিগত "থাম্বের নিয়ম"। এটি বেশ কয়েকটি কারণে ভাল আকার:

• এটি স্ক্রোল ছাড়াই আপনার স্ক্রিনে সহজেই ফিট করে
• এটি আপনার মাথায় ধারণ করতে পারেন এমন ধারণাগত আকার সম্পর্কে
• এটি তার নিজের ক্ষেত্রে কোনও ক্রিয়াকলাপের প্রয়োজন যথেষ্ট অর্থবহ (এককভাবে, যুক্তির অর্থপূর্ণ অংশ)
• 5 লাইনের চেয়ে কম ফাংশন হ'ল এমন একটি ইঙ্গিত যা আপনি সম্ভবত কোডটি খুব বেশি ভেঙে ফেলছেন (যা আপনাকে ফাংশনগুলির মধ্যে নেভিগেট করার প্রয়োজন হলে পড়তে / বুঝতে অসুবিধা হয়)। হয় বা আপনি আপনার বিশেষ কেস / ত্রুটি পরিচালনা পরিচালনা ভুলে যাচ্ছেন!

তবে আমি মনে করি না যে এটি একটি নিখুঁত নিয়ম নির্ধারণ করা সহায়ক, কারণ নিয়ম থেকে বিচ্ছিন্ন হওয়ার জন্য সর্বদা বৈধ ব্যতিক্রম / কারণ থাকবে:

• কোনও এক-লাইন অ্যাকসেসর ফাংশন যা কোনও প্রকারের কাস্ট সম্পাদন করে তা কিছু পরিস্থিতিতে পরিষ্কারভাবে গ্রহণযোগ্য।
• কিছু খুব সংক্ষিপ্ত তবে দরকারী ফাংশন রয়েছে (যেমন ব্যবহারকারী অজানা দ্বারা বর্ণিত সোয়াপ) যা পরিষ্কারভাবে 5 টিরও কম লাইনের প্রয়োজন। বড় কথা নয়, কয়েকটি 3 লাইন ফাংশন আপনার কোড বেসের কোনও ক্ষতি করে না।
• একটি 100-লাইনের ফাংশন যা একটি একক বৃহত সুইচ বিবৃতিটি গ্রহণযোগ্য হতে পারে যদি এটি চূড়ান্তভাবে হয় তবে কী করা হচ্ছে। এই কোডটি ধারণাগতভাবে খুব সহজ হতে পারে এমনকি যদি এটির বিভিন্ন ক্ষেত্রে বর্ণনা করার জন্য প্রচুর লাইন প্রয়োজন হয়। কখনও কখনও পরামর্শ দেওয়া হয় যে এটি পৃথক শ্রেণিতে সংশোধন করা উচিত এবং উত্তরাধিকার / বহুমুখিতা ব্যবহার করে প্রয়োগ করা উচিত তবে আইএমএইচও এটি ওওপিকে অনেক দূরে নিয়ে যাচ্ছে - আমি বরং 40 টি নতুন ক্লাসের চেয়ে একটি বড় 40-ওয়ে স্যুইচ স্টেটমেন্ট চাই, কেবলমাত্র এটির সাথে ডিল করার জন্য এগুলি তৈরি করতে 40-উপায় স্যুইচ বিবৃতিতে।
• একটি জটিল ক্রিয়াকলাপে অনেকগুলি স্টেটের ভেরিয়েবল থাকতে পারে যা পরামিতি হিসাবে বিভিন্ন ফাংশনের মধ্যে পাস করা হলে খুব অগোছালো হয়ে উঠবে। এই ক্ষেত্রে আপনি যুক্তিযুক্তভাবে যুক্তি দিতে পারেন যে আপনি কোডকে একটি বৃহত ফাংশনে রেখে দিলে কোডটি অনুসরণ করা সহজ এবং সহজ (যদিও মার্ক যথাযথভাবে উল্লেখ করেছেন এটি উভয় যুক্তিকেই আবদ্ধ করতে কোনও শ্রেণিতে পরিণত হওয়ার প্রার্থী হতে পারে although এবং রাষ্ট্র))
• কখনও কখনও ছোট বা বৃহত্তর ফাংশনগুলির পারফরম্যান্স সুবিধা থাকে (সম্ভবত ইনলাইনিং বা জেআইটি কারণে ফ্র্যাঙ্কের উল্লেখ হিসাবে)। এটি অত্যন্ত বাস্তবায়ন নির্ভর, কিন্তু এটি একটি পার্থক্য করতে পারে - নিশ্চিত করুন যে আপনি বেনমার্ক!

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

Comments

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

— লুক পুপলেট

"সাধারণ জ্ঞান ব্যবহার করুন" সর্বাধিক গুরুত্বপূর্ণ পরামর্শ

— সাইমন

একজনকে সচেতন হওয়া উচিত যে ডিবাগিংয়ের সময় ব্রেকপয়েন্টগুলিতে স্ট্যাকের গভীরতার কারণে এই urশ্বর্যবাদী "রাভিওলি কোড" এর অভিযোগের ফলাফল পাবে।

— ফ্র্যাঙ্ক হিলেমান

@ ফ্র্যাঙ্কহিল্যান কোড লেখার সময় আমি স্প্যাগেটির উপর দিয়ে কোনও দিন রাভিওলি নেব

@ সোনমান: এই পছন্দগুলি পারস্পরিক একচেটিয়া নয় ... স্প্যাগেটি ছাড়াই সংক্ষিপ্ত স্তরের গভীরতা আদর্শ। গভীর স্ট্যাকের গভীরতা, পাশে স্প্যাগেটি?

— ফ্রাঙ্ক হিলিমান

Answer 2

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

সুতরাং, যদিও এলওসি খারাপ কোডের সরাসরি সূচক নাও হতে পারে, তবে অবশ্যই এটি একটি শালীন অপ্রত্যক্ষ সূচক যে নির্দিষ্ট ফাংশন আরও ভালভাবে লেখা যেতে পারে।

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

Comments

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

— Cori

"aকমত্যে আসুন যে 10 টির মধ্যে 9 টি এসআরপি ভেঙে দেয়" - আমি একমত নই, আমি নিশ্চিত যে এই ফাংশনগুলির মধ্যে 10 এর মধ্যে 10 এটি ভেঙে ফেলবে ;-)

— ডক ব্রাউন

কোড পর্যালোচনা চলাকালীন পতাকা উত্থাপনের জন্য +1: অন্য কথায়, একটি কঠোর এবং দ্রুত নিয়ম নয়, তবে একটি গ্রুপ হিসাবে এই কোডটি আলোচনা করা যাক।

Answer 3

আমি এমন একটি প্রকল্পে পা রেখেছি যার কোডিং গাইডলাইন সম্পর্কে কোনও যত্ন নেই। আমি যখন কোডটি সন্ধান করি তখন আমি মাঝে মাঝে 6000 এর বেশি কোডের লাইন এবং 10 টিরও কম পদ্ধতির ক্লাস পাই। আপনার যখন বাগগুলি ঠিক করতে হয় তখন এটি একটি হররর দৃশ্য।

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

Comments

আমি দেখতে পাচ্ছি না কেন 6000 লাইনের ফাংশনটি সংক্ষিপ্তটির চেয়ে ডিবাগ করা আরও শক্ত ... যদি না এতে অন্যান্য সমস্যাগুলিও হয় (যেমন, পুনরাবৃত্তি)

— কলমারিয়াস

এটির ডিবাগিংয়ের সাথে কোনও সম্পর্ক নেই .. এর জটিলতা এবং রক্ষণাবেক্ষণ সম্পর্কে। আপনি কীভাবে অন্য একটি দ্বারা করা 6000 লাইন পদ্ধতি প্রসারিত বা পরিবর্তন করবেন?

— স্মোকফুট

@ কালমারিয়াসের পার্থক্যটি সাধারণতঃ 6000 লাইন ফাংশনগুলিতে স্থানীয় ভেরিয়েবলগুলি থাকে যা খুব দূরে (দৃষ্টিভঙ্গি) হিসাবে ঘোষিত হয়েছিল, প্রোগ্রামারটির পক্ষে কোড সম্পর্কে উচ্চ আত্মবিশ্বাসের প্রয়োজনীয় মানসিক প্রসঙ্গটি তৈরি করা কঠিন করে তোলে। কোনও ভেরিয়েবল কীভাবে কোনও প্রাথমিক পর্যায়ে আরম্ভ এবং বিল্ট আপ করা হয় তা সম্পর্কে আপনি নিশ্চিত থাকতে পারেন? আপনি কি নিশ্চিত যে আপনার ভেরিয়েবলটি 3879 লাইনে সেট করার পরে কিছুই ভ্রান্ত হবে না? অন্যদিকে, 15 লাইন পদ্ধতি সহ, আপনি নিশ্চিত হতে পারেন।

— ড্যানিয়েল বি

@ ক্যালমারিয়াস রাজি হয়েছে, তবে এই দুটি বক্তব্যই 6000 এলওসি ফাংশনের বিরুদ্ধে যুক্তি are

— ড্যানিয়েল বি

Line০০ লাইনের পদ্ধতিতে স্থানীয় ভেরিয়েবল মূলত বিশ্বব্যাপী পরিবর্তনশীল।

— এমকে

Answer 4

এটি লাইন সংখ্যা সম্পর্কে নয়, এটি এসআরপি সম্পর্কে। এই নীতি অনুসারে, আপনার পদ্ধতিতে একটি এবং কেবল একটি জিনিস করা উচিত।

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

আপনি যদি কেবল এসআরপি অনুসরণ করেন তবে আপনার বেশিরভাগ পদ্ধতি ছোট এবং স্পষ্ট অভিপ্রায় অনুসারে হবে।

"এই পদ্ধতিটি> 20 টি লাইন তাই এটি ভুল" বলা সঠিক নয়। এটি একটি ইঙ্গিত হতে পারে যে এই পদ্ধতিতে কিছু ভুল হতে পারে , আর নেই।

আপনার কোনও পদ্ধতিতে 400 লাইনের স্যুইচ থাকতে পারে (প্রায়শই টেলিকম হয়) এবং এটি এখনও একক দায়িত্ব এবং এটি পুরোপুরি ঠিক।

Comments

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

— মার্টিজন

"এসআরপি" এর অর্থ কী?

— থমথম

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

— ক্রিস্টিয়ান ডুসকে

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

— মারিও টি ল্যাঞ্জা

হ্যাঁ তবে কী একক দায়িত্ব। এটি আপনার মাথায় তৈরি একটি ধারণা। যদি আপনার একক দায়বদ্ধতার জন্য 400 লাইন প্রয়োজন হয় তবে আপনার একক দায়বদ্ধতার ধারণাটি সম্ভবত অন্যরকম আমার

— Xitcod13

Answer 5

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

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

Answer 6

আমি মনে করি এখানে একটি সমস্যা হ'ল কোনও ফাংশনের দৈর্ঘ্য তার জটিলতা সম্পর্কে কিছুই বলে না। কোনও কিছু পরিমাপের জন্য এলওসি (কোডের লাইন) একটি খারাপ উপকরণ are

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

উদাহরণস্বরূপ ইনকামিং ডেটার জন্য কোনও হ্যান্ডলারের একটি বড় স্যুইচ স্টেটমেন্ট এবং তারপরে ক্ষেত্রে সহজ কোড থাকতে পারে। আমার কাছে এমন কোড রয়েছে - একটি ফিড থেকে আগত ডেটা পরিচালনা করা। 70 (!) সংখ্যায় কোডেড হ্যান্ডলারগুলি। এখন, কেউ "কনস্ট্যান্ট ব্যবহার করুন" বলবেন - হ্যাঁ, এপিআই বাদে তাদের সরবরাহ করে না এবং আমি এখানে "উত্স" এর কাছাকাছি থাকতে চাই। পদ্ধতি? অবশ্যই - দুঃখের সাথে তারা সবাই একই 2 বিশাল কাঠামোর ডেটা নিয়ে কাজ করে। এগুলি বিভক্ত করার কোনও সুবিধা নেই সম্ভবত আরও পদ্ধতি (পাঠযোগ্যতা) রয়েছে except কোডটি অভ্যন্তরীণভাবে জটিল নয় - ক্ষেত্রের উপর নির্ভর করে একটি স্যুইচ। তারপরে প্রতিটি ক্ষেত্রে একটি ব্লক থাকে যা ডেটার এক্স উপাদানগুলিকে পার্স করে এবং সেগুলি প্রকাশ করে। কোনও রক্ষণাবেক্ষণ দুঃস্বপ্ন। এখানে একটি পুনরাবৃত্তি রয়েছে "যদি শর্ত থাকে যে কোনও ক্ষেত্রের ডেটা রয়েছে কিনা তা নির্ধারণ করে (পিফিল্ড = পিফিল্ডস [এক্স], যদি পিফিল্ড-> ইসসেট () b ব্লেবলা}) - প্রতিটি ক্ষেত্রে একই রকম ..

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

সুতরাং, দুঃখিত, এলওসি দিয়ে শুরু করা ভাল পরিমাপ নয়। যদি কিছু থাকে তবে জটিলতা / সিদ্ধান্ত পয়েন্টগুলি ব্যবহার করা উচিত।

Comments

এলওসি হ'ল একটি অঞ্চল যেখানে তারা একটি প্রাসঙ্গিক পরিমাপ সরবরাহ করে তার জন্য ব্যবহার করার একটি দুর্দান্ত সরঞ্জাম - খুব বড় প্রকল্প যেখানে এ জাতীয় প্রকল্পটি সম্পন্ন হতে কতটা সময় নিতে পারে তার অনুমান দিতে সহায়তা করতে ব্যবহার করা যেতে পারে। এর বাইরেও লোকেরা তাদের সম্পর্কে খুব বেশি চিন্তাভাবনা করে।

— rjzii

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

— টমটম

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

— rjzii

ফাংশনটি সম্পাদন করার জন্য প্রয়োজনীয় সমস্ত কোডটি +1 করতে হবে এটি কেবল একটি জিনিস এবং একটি জিনিস করা উচিত - তবে যদি এটির জন্য 1000 লাইন কোড লাগে তবে তা তাই।

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

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

Answer 7

আমি শুধু আরও একটি উদ্ধৃতি নিক্ষেপ করব।

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

- হ্যারল্ড আবেলসন

এটি অত্যন্ত অসম্ভব যে ফাংশনগুলি 100-200 এ বৃদ্ধি করে এই নিয়মটি অনুসরণ করে

Comments

যখন সেগুলিতে একটি স্যুইচ থাকে Ex

— কলমারিয়াস

অথবা একটি ডাটাবেস কোয়েরি যে resultset মধ্যে সারি প্রতি ক্ষেত্র কয়েক ডজন ফেরৎ ... ফলাফল উপর ভিত্তি করে একটি বস্তু গঠন

— jwenting

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

— মেটালমাইকস্টার

Answer 8

আমি এই ক্রেজিট র‌্যাকেটে, এক উপায় না অন্যভাবে, 1970 সাল থেকে been

এই মুহুর্তে, আমি দুটি মুহূর্তের মধ্যেই ব্যতিক্রম পাব তার সাথে, আমি কখনই একটি ভালভাবে ডিজাইন করা "রুটিন" (পদ্ধতি, পদ্ধতি, ফাংশন, সাবরুটিন, যাই হোক না কেন) দেখতে পেয়েছি যা একাধিক মুদ্রিত পৃষ্ঠার হতে হবে ( প্রায় 60 লাইন) দীর্ঘ। তাদের বেশিরভাগ অংশটি 10-20 লাইনের ক্রম অনুসারে বেশ কিছুটা সংক্ষিপ্ত ছিল।

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

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

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

Comments

আমি এই উত্তরটি থেকে পেয়েছি "আমার লন ছেড়ে যাও" এর জন্য +1। এছাড়াও, ওওপি এর আগে থেকেই ব্যক্তিগত অভিজ্ঞতা থেকে ভাষাগুলি ব্যাপক ছিল।

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

— জন আর স্ট্রোহম

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

— মেটালমাইকস্টার

Answer 9

যদি আমি দীর্ঘ পদ্ধতিটি খুঁজে পাই - আমি বাজি ধরতে পারি যে এই পদ্ধতিটি সঠিকভাবে ইউনিট-পরীক্ষিত নয় বা বেশিরভাগ সময় এটির ইউনিট পরীক্ষা নেই। আপনি যদি টিডিডি করা শুরু করেন তবে আপনি কখনও 25 টি পৃথক দায়িত্ব এবং 5 নেস্টেড লুপের সাথে 100-লাইন পদ্ধতি তৈরি করতে পারবেন না। পরীক্ষাগুলি আপনাকে ক্রমাগত আপনার গণ্ডগোলকে রিফ্যাক্টর করতে বাধ্য করে এবং মামার বব ক্লিন কোডটি লিখে দেয়।

Answer 10

পদ্ধতির দৈর্ঘ্য সম্পর্কে কোনও নিখুঁত নিয়ম নেই তবে নিম্নলিখিত বিধিগুলি কার্যকর হয়েছে:

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

Comments

পার্শ্ব প্রতিক্রিয়া সম্পর্কে কী - কোনও ফাইলে লেখা, স্থিতি পুনরায় সেট করা ইত্যাদি?

— ভোরাক

Answer 11

লেখকরা কি "ফাংশন" এবং "রুটিন" দ্বারা একই জিনিসটি বোঝায়? সাধারণত যখন আমি "ফাংশন" বলি তখন আমার অর্থ এমন একটি সাবরুটিন / অপারেশন যা একটি মান এবং "পদ্ধতি" দেয় না এমনটির জন্য (এবং যার কলটি একক বিবৃতিতে পরিণত হয়) দেয়। বাস্তব বিশ্বে এটি এসই জুড়ে কোনও সাধারণ পার্থক্য নয় তবে আমি এটি ব্যবহারকারীর পাঠ্যে দেখেছি।

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

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

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

সুতরাং আমি ভাবব যে কোন স্টাইলটি বাগ-ভরা দুঃস্বপ্ন হওয়ার কম সম্ভাবনা রয়েছে আপনি আপনার কোডটির বাকী অংশগুলির জন্য কোন কনভেনশনগুলিতে মেনে চলেন তার উপর নির্ভর করে। :)

Answer 12

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

তদনুসারে, এটি আপনার দলের কাজের স্বাভাবিক প্রোগ্রামিং পরিবেশের উপর নির্ভর করে (স্ক্রিন রেজোলিউশন, সম্পাদক, ফন্টের আকার ইত্যাদি ...)। 80 এর দশকে এটি 25 লাইন এবং 80 কলাম ছিল। এখন, আমার সম্পাদকটিতে আমি প্রায় 50 টি লাইন প্রদর্শন করি। আমি মাঝে মাঝে দুটি ফাইল প্রদর্শনের জন্য আমার স্ক্রিনটি দুটি বিভক্ত করার পরে আমি প্রদর্শিত কলামগুলির সংখ্যা পরিবর্তন হয় নি।

সংক্ষেপে, এটি আপনার সহকর্মীদের সেটআপের উপর নির্ভর করে।

Comments

এটি কি সেই সময়ের চেয়ে ২৪ টি লাইন ছিল না? আমি 3270 বা 9750 টার্মিনালের কথা ভাবছি, যেখানে 25 তম স্থিতি রেখা ছিল। এবং টার্মিনাল অনুকরণগুলি এর অনুসরণ করে।

— অট--

কিছু সিস্টেম / সম্পাদকদের শুরু থেকে 40 বা 50 টি লাইন ছিল। এই দিনগুলিতে 150 লাইনগুলি অস্বাভাবিক নয় এবং 200+ করণীয়, সুতরাং এটি আসলে কোনও ভাল মেট্রিক নয়।

— এম

আমি আমার পর্দা প্রতিকৃতি নির্দেশে ব্যবহার করি, আমি একবারে 200 লাইনের কোড দেখতে পাচ্ছি।

— কলমারিয়াস

আর যদি আমি কোন লাইন ব্রেক ব্যবহার করবেন না আমার লাইন ভেঙ্গে আমি একটি একক লাইন একটি 5000 লাইন পদ্ধতি ... কোড করতে পারেন

— jwenting

Answer 13

আমি মনে করি টমটমের উত্তরটি এ সম্পর্কে আমার কেমন অনুভূত হয় তার কাছাকাছি এসেছিল।

আরও অনেক বেশি আমি নিজেকে লাইনের পরিবর্তে সাইক্লোমেটিক জটিলতায় যেতে দেখি।

আমি সাধারণত প্রতি পদ্ধতিতে একাধিক নিয়ন্ত্রণ কাঠামোর জন্য লক্ষ্য রাখি না, তবে বহু লিম্পের ব্যতীত এটি বহু-মাত্রিক অ্যারে পরিচালনা করতে লাগে takes

আমি মাঝে মাঝে নিজেকে স্যুইচ কেসগুলিতে ওয়ান-লাইন আইএফ লাগিয়ে দেখতে পাই কারণ কোনও কারণে এগুলি এমন ক্ষেত্রে দেখা দেয় যেখানে এটি বিভক্ত হওয়ার পরিবর্তে সাহায্য না করে বাধা দেয়।

মনে রাখবেন যে আমি এই সীমাটির বিপরীতে গার্ড যুক্তি গণনা করি না।

Comments

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

— জন আর স্ট্রোহম

@ জনআর.স্ট্রোহম আমি প্রতি পদ্ধতি অনুসারে কথা বলছি, সামগ্রিকভাবে নয়। অবশ্যই, বড় ছবিতে এটি অত্যন্ত সংযুক্ত - প্রশ্নটি কীভাবে সেই কোডটি পদ্ধতিতে বিভক্ত করা যায়। ১০ টি লাইনের ১০ টি পদ্ধতি বা ১০ টি লাইনের 100 টি পদ্ধতিতে এখনও একই সামগ্রিক এসএলওসি এবং জটিলতা থাকবে তবে পূর্বেরটি কাজ করা আরও কঠিন হতে চলেছে।

— লরেন পেচটেল

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

— জন আর স্ট্রোহম

Answer 14

ওওপিতে সমস্ত জিনিস আপত্তি করে এবং এই বৈশিষ্ট্যগুলি রয়েছে:

1. পলিমরফিজ্ম
2. বিমূর্তন
3. উত্তরাধিকার

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

1. ভাল পাঠযোগ্য
2. ভাল বজায় রাখুন
3. স্থির বাগ আরও ভাল
4. আরও ভাল পরিবর্তন