কোন কার্যের সর্বোচ্চ দৈর্ঘ্য হিসাবে প্রমাণিত কী? [বন্ধ]

44

ফাংশনের দৈর্ঘ্য কোনও প্রোগ্রামারের উত্পাদনশীলতাকে প্রভাবিত করে? যদি তা হয় তবে উত্পাদনশীলতা হ্রাস এড়ানোর জন্য একটি ভাল সর্বোচ্চ সংখ্যক লাইন কী?

যেহেতু এটি একটি উচ্চ মতামতযুক্ত বিষয় দয়া করে কিছু ডেটা দিয়ে দাবির ব্যাক আপ করুন।

programming-practices coding-standards

— পিটার মর্টেনসেন
সূত্র

6

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

— ক্যাফগিকে

4

কোডটি পর্যালোচনা করার পরে আপনার পিয়ার আপনাকে জানায়।

— gnat

13

সর্বাধিক দৈর্ঘ্য 17 হওয়া উচিত

— থমাসএক্স

1

SOLID এ এস।

— ক্রিস ক্রাউস

1

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

— কোডসইনচওস

46

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

এই বিষয়ে, আমি মডিউলগুলি লিখেছি যা দীর্ঘ ছিল তবে তারা সাধারণত বড় সীমাবদ্ধ রাষ্ট্র মেশিনগুলি বড় স্যুইচ-স্টেটমেন্ট হিসাবে লেখা হত।

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

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

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

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

3

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

— শোগ 9

1

@জনাব. সিআরটি: ব্লক-ভিত্তিক FORTH বাস্তবায়নগুলি forced modulariization এর দৈর্ঘ্য সীমা। বেশিরভাগ FORTH- এর ইন্টারেক্টিভ প্রকৃতি ছোট মডিউলগুলিকে উত্সাহিত করে এবং সেই মডিউলগুলির দ্রুত পরীক্ষার মাধ্যমে সহায়তা করে। ডিজিএইচ, একটি ফাইল-ভিত্তিক ফরথ, মডিউলাইজেশনকে জোর করল না এবং আমি দেখেছি যে ডিজে নিয়ে খেলছেন ছেলেরা এটির সাথে চিরকালীন মডিউলগুলির সাথে প্রচুর রান-স্ট্রিম অফ প্রোগ্রামার-চেতনা লিখতে পারে। তাই আমার দৃiction়প্রত্যয় (এটির মূল্যের জন্য, লিজ বরং আমার সাথে একমত নয় She তিনি মনে করেন এটি মূলত ইন্টারঅ্যাকটিভিটি যা ফোরথকে উত্পাদনশীলতা

— বাড়ায়

2

+1 আমাকে "কম্পিউটার প্রোগ্রামিংয়ের সাইকোলজি" বইয়ের

— স্যামুয়েল

30

সত্যিকারের আকারটি কী?

আপনি যে ভাষাটি ব্যবহার করেন তার উপর নির্ভর করে তবে সাধারণভাবে (এবং আমার ব্যক্তিগত স্বাদের জন্য):

আদর্শভাবে , 25 লাইনের কম।
গ্রহণযোগ্যভাবে , কম 35 লাইন।

যদি এটি আরও বেশি হয় তবে এটি আমার পরে ফিরে এসে আবার কাজ করার দরকার।

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

(সাম্প্রতিককালে আমার দলটি আমাদের কোডবেসে একটি প্রোগ্রাম চালিয়েছিল: আমরা ১৯ 197 টি পদ্ধতিতে একটি ক্লাস পেয়েছি এবং অন্যটিতে কেবল ৩ টি পদ্ধতি রয়েছে তবে তার মধ্যে একটি 600০০ লাইনের ছিল। কিউট গেম: 2 টির খারাপের কী খারাপ?)

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

সবকিছু যতটা সম্ভব সহজ করা উচিত, তবে সহজ নয়। - এ আইনস্টাইন

সংযোজন করার মতো আর কিছুই না থাকায় পরিপূর্ণতা পরিশেষে প্রাপ্ত হয় না, তবে যখন আর কিছুই কেড়ে নিতে থাকে না। - এ। ডি সেন্ট এক্সুপুরি

মন্তব্য শৈলীতে সংযোজন

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

মন্তব্য বলে "কেন?" ,
কোড বলছেন "কিভাবে?" ।

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

আরও তথ্যের জন্য, অনুগ্রহ করে স্টাইল এবং মন্তব্য কোডের প্রস্তাবনা সম্পর্কে আমার উত্তর পড়ুন

— রিভস হেইলেম
সূত্র

@ হাইলেম আমি অনুমান করি এটি ফ্রেডি বনাম জেসন :-) এর প্রোগ্রামার সংস্করণ

— গৌরব

আমি সম্মত, তবে আমি এটি যুক্ত করব এটি একটি পর্দার পৃষ্ঠার আকারের হওয়া উচিত। যদি আপনার এক স্ক্রিন পৃষ্ঠায় 72 লাইন থাকে তবে ফাংশনটি 72 টি লাইনের বেশি হওয়া উচিত নয়।

— ডিসপ্লে নাম

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

— haylem

1

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

— কনফিগারকারী

1

যখন ফাংশনটি উদাঃ Map(x => x.Property1); Map(x => x.Property2); Map(x => x.Property3);এটি এক ধরণের স্পষ্ট যে এটি সমস্ত একই। (উল্লেখ্য এই মাত্র একটি উদাহরণ; ফাংশন এই ধরনের সময় থেকে পপ আপ করে সময়)

— Configurator

12

আমার মতে, প্রতিটি ফাংশন যতটা সম্ভব ছোট হওয়া উচিত। প্রতিটি ফাংশনটিতে কেবল একটি কাজ করা উচিত এবং এটি ভালভাবে করা উচিত। এটি প্রকৃতপক্ষে সর্বাধিক দৈর্ঘ্যের প্রশ্নের উত্তর দেয় না, তবে কার্যকারিতার দৈর্ঘ্যের বিষয়ে আমার অনুভূতি আরও বেশি।

চাচা বব এর শব্দটি ব্যবহার করতে, "যতক্ষণ না আপনি আর কোনও কিছু বের করতে পারবেন না ততক্ষণ এক্সট্রাক্ট করুন you যতক্ষণ না আপনি নামবেন" "

— জেসন
সূত্র

2

আপনি যতটা সম্ভব ছোট হিসাবে কী বোঝাতে চান? প্রতিটি ফাংশনটিতে কেবল দুটি লাইন থাকবে যতটা সম্ভব ছোট হওয়া সম্ভব নয়: একটির একটি অপারেশন করা, এবং অন্যটি যা একটি ফাংশনকে বাকী কাজ করতে বলে?

— Kelmikra

চাচা বব আবার। নিজের জন্য চিন্তা কর. চাচাদের কথা শুনবেন না। তারা আপনাকে পথভ্রষ্ট করে।

— gnasher729

10

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

— হুয়াং এফ লে
সূত্র

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

— স্যামুয়েল

10

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

— Mnementh
সূত্র

এবং আপনার পদ্ধতির একটি ভাল নাম রাখার জন্য কেবল একটি জিনিস করা উচিত ... না 'এবং', 'বা' বা এমন কোনও কিছু যা এই পদ্ধতির নাম 50 অক্ষর দীর্ঘ করে দেয়।

— স্যামুয়েল

10

যতক্ষণ এটি করা দরকার তাই করা দরকার, তবে আর নেই।

— পল নাথান
সূত্র

যেমন তারা সি তে বলে, "সি তে কোনও সমস্যা নেই যা আপনি সেই পয়েন্টারে অন্য পয়েন্টার যুক্ত করে সমাধান করতে পারেন নি।" আপনি তার নীচে অন্য ফাংশনটি সর্বদা যুক্ত করতে পারতেন, তাঁর প্রশ্নটি আপনার এপিফনিতে হবে "এটি কোথায় শেষ?"

— প্রদর্শিত নাম

1

আমি আসলে এটিকে উল্টিয়ে বলব এবং "যত ছোট হওয়া দরকার তত ছোট হবে", তবে যথেষ্ট কাছাকাছি থাকার জন্য আপনি আমার +1 পান :)

— বেন হিউজ

6

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

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

বাস্তবে ভাল পদ্ধতি ডিজাইনের অংশটি কার্যকরীভাবে সমন্বিত পদ্ধতি তৈরি করে (মূলত তারা একটি কাজ করে)। পদ্ধতিগুলির দৈর্ঘ্য কোনও বিষয় নয়। যদি কোনও ফাংশন একটি ভাল সংজ্ঞায়িত জিনিস করে এবং এটি একটি ভাল পদ্ধতি থেকে 1000 টি লাইন। যদি কোনও ফাংশন 3 বা 4 জিনিস করে এবং কেবল 15 লাইন হয় তবে এটি একটি খারাপ পদ্ধতি ...

— cervo
সূত্র

আমি ছোট পদ্ধতি পছন্দ করি।

— মার্কি

আপনি যা বলেছেন তা আমি পছন্দ করি কারণ একটি পদ্ধতিতে 10 টির বেশি লাইন থাকা উচিত নয় বলে আমার দৃষ্টিভঙ্গিতে একটি ইউটোপিয়া। ঠিক আছে, প্রতিবার যখন আপনি কোনও পদ্ধতি লিখেন তখন এটি মনে রাখা ভাল তবে এটি 1 + 1 = 2 এর মতো গাণিতিক নিয়ম হওয়া উচিত নয় আপনি যদি কেআইএসএস, ডিআরআই, ইয়াগনি, ইত্যাদি মত নীতিগুলি সম্মান করেন এবং আপনার পদ্ধতিগুলি হ'ল পূর্ণ বিবরণ দিয়ে কিছু বিশদ ব্যাখ্যা করে না কারণ খুব দীর্ঘ, পদ্ধতিতে কোডের 100 টি লাইন থাকতে পারে এবং এটি বুঝতে এবং বজায় রাখতে সম্পূর্ণ পরিষ্কার হতে পারে clean তবে এটি অভ্যাসের চেয়ে বেশি ব্যতিক্রম হওয়া উচিত। আমি মনে করি কারখানা পদ্ধতিতে স্যুইচ কেস ব্যতিক্রমের একটি ভাল উদাহরণ।

— স্যামুয়েল

5

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

যুক্তিসঙ্গত ফন্টের সাথে আমার মনিটরে ফিট করার পক্ষে যথেষ্ট সংক্ষিপ্ত।
যদি এটি # 1 এর চেয়ে বেশি দীর্ঘ হতে হয় তবে যুক্তিসঙ্গত ফন্টে কোনও টুকরো কাগজে মুদ্রণের জন্য যথেষ্ট সংক্ষিপ্ত।
যদি এটি # 2 এর চেয়ে বেশি দীর্ঘ হতে হয় তবে কোনও কাগজের টুকরোতে 2-আপ মুদ্রণের জন্য যথেষ্ট সংক্ষিপ্ত।

আমি এর চেয়ে দীর্ঘকালীন ফাংশনগুলিতে খুব কমই লিখি। এগুলির বেশিরভাগ হ'ল জায়ান্ট সি / সি ++ স্যুইচ স্টেটমেন্ট।

— বব মারফি
সূত্র

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

— স্যামুয়েল

5

আমার জন্য, একটি ফাংশন এটি হওয়া যে কোনও দৈর্ঘ্য। আমি কোডটি পুনরায় ব্যবহার করব যখন বেশিরভাগ সময় আমি এটি ভাগ করি।

মূলত, আমি প্রধান 'উচ্চ সংহতি, কম সংশ্লেষ' এর সাথে লেগে থাকব এবং দৈর্ঘ্যের কোনও বাধা নেই।

— রস
সূত্র

5

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

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

আমি এসকিউএল সঞ্চিত পদ্ধতি দেখেছি যা 1000 লাইনের বেশি চলে run সঞ্চিত পদ্ধতির লাইনের সংখ্যাও 50 এরও কম? আমি জানি না, তবে এটি কোড পড়ার চেষ্টা করে, নরক। আপনাকে কেবল উপরে ও নিচে স্ক্রোলিংই রাখতে হবে না, আপনার কোডের কয়েকটি লাইনের একটি নাম দেওয়া দরকার যেমন "এটি কার্যকর করে তোলে", "ডাটাবেসে এই আপডেটগুলি" ইত্যাদি - - প্রোগ্রামারটি এমন একটি কাজ করা উচিত ছিল।

— নারায়ণ
সূত্র

শুধুমাত্র প্রথম অনুচ্ছেদের জন্য +1। আপনি যা কাজ করছেন তার সাথে সম্পর্কিত সমস্ত কিছুই।

— প্রদর্শিত নাম

এবং এটি কীভাবে 50 ফাংশনে বিভক্ত করা সহায়তা করে? যখন ফাংশনগুলি যোগাযোগ করতে হয়, তাই আপনি 500 লাইনের সাথে শেষ করবেন না হাজার?

— gnasher729

5

থেকে Cyclomatic জটিলতা (উইকিপিডিয়া):

উত্স কোডের একটি বিভাগের চক্রবৃত্তীয় জটিলতা হ'ল উত্স কোডের মাধ্যমে লিনিয়ারে স্বতন্ত্র পাথের সংখ্যা গণনা।

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

— কোডআর্ট
সূত্র

সাইক্লোমেটিক জটিলতা কাঁচা এসএলওসি-র সাথে খুব দৃ corre়ভাবে সম্পর্কযুক্ত হওয়ার জন্য কোনও বড় পাবলিক রিপোজিটরির রিয়েল কোডে দেখানো হয়েছে, সংকলিত উদাহরণ নয়। এটি এটিকে মূলত মূল্যহীন করে তোলে, কারণ গাড়ীর রিটার্ন গণনা করা আরও সহজ। (হ্যাঁ, এসএলওসি খেলা সম্ভব। এখানে সত্যবাদী হোন: আপনার নিয়োগকর্তায় এসএলওসি মেট্রিকগুলি গেমিং করছে এমন কাউকে কতক্ষণ বেতন-চেক আঁকতে দেওয়া হবে?)

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

4

সাধারণত, আমি আমার পদ্ধতিগুলি / ফাংশনগুলি 1680x1050 মনিটরের স্ক্রিনে যা ফিট করে তা রাখার চেষ্টা করি। যদি এটি মাপসই না হয় তবে টাস্কটি পার্সেল করার জন্য সহায়ক পদ্ধতি / ফাংশন ব্যবহার করুন।

এটি পর্দা এবং কাগজ উভয়ই পঠনযোগ্যতা সাহায্য করে।

— জেসন
সূত্র

আমি একই জিনিসটি করি তবে আপনি কোন ফন্টের ধরণ এবং আকার ব্যবহার করছেন তা নির্দিষ্ট করে তোলা দরকার। আমার জন্য, আমি স্কট হ্যানসেলম্যানের পরামর্শ অনুসারে 14 আকারের "কনসোলস" পছন্দ করি। hanselman.com/blog/… এত বড় ফন্টের সাথে কাজ করা প্রথমবারের মতো কঠিন তবে আপনাকে সর্বদা স্মরণ করা সর্বোত্তম অনুশীলন যে আপনার পদ্ধতিটি যতটা সম্ভব ছোট হওয়া উচিত।

— স্যামুয়েল

4

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

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

— dsimcha
সূত্র

ফাংশনগুলি একটি নির্দিষ্ট বিমূর্ততা স্তরে "একটি জিনিস" করে এবং আপনি কেবলমাত্র তার একটি বিমূর্ত স্তর সম্পর্কে উদ্বেগ প্রকাশ করেন। এটাই আসল ব্যাপার. যদি আপনি এটি উপলব্ধি করতে না পারেন তবে আমি মনে করি না আপনি বিমূর্ততা বুঝতে পেরেছেন।

— জোড়ান পাভলভিক

4

সঠিকভাবে অনুকূলিত করার জন্য যথেষ্ট সংক্ষিপ্ত

সঠিকভাবে একটি জিনিস করার পদ্ধতিগুলি এত ছোট হওয়া উচিত। এর কারণটি সহজ: সুতরাং আপনার কোডটি যথাযথভাবে অনুকূলিত করা যায়।

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

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

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

— ক্রিস স্মিথ
সূত্র

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

— স্যামুয়েল

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

— gnasher729

3

এটি কোডে কী রয়েছে তার উপর নির্ভর করে।

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

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

— লরেন পেচটেল
সূত্র

2

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

— LennyProgrammers
সূত্র

1

আমার সাধারণ নিয়মটি হ'ল কোনও ফাংশনটি স্ক্রিনে ফিট করা উচিত। আমি কেবল তিনটি ক্ষেত্রেই এটির লঙ্ঘন করতে দেখা গেছে:

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

2) কার্য সম্পাদন করার জন্য একটি গোটা পদক্ষেপের কাজ করে এবং যেখানে পদক্ষেপগুলিতে একটি ভাল মহকুমার অভাব রয়েছে। আপনি এমন একটি ফাংশন শেষ করবেন যা কেবল ক্রিয়াকলাপে অন্যান্য ক্রিয়াকলাপগুলির একটি দীর্ঘ তালিকাকে কল করে।

3) # 2 এর মতো তবে পৃথক পদক্ষেপগুলি এত ছোট যেখানে তারা পৃথকভাবে ডাকা না হয়ে কেবল ইনলাইনড।

— লরেন পেচটেল
সূত্র

1

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

পদ্ধতির জন্য, এক্স 30 এ সেট করা হয়েছে এবং এটি বেশ শক্ত।

— পিটার মর্টেনসেন
সূত্র