একটি একক রেফারেন্স খারাপ শৈলী সঙ্গে ব্যক্তিগত পদ্ধতি?

139

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

এ বিষয়ে কি কোন sensক্যমত্য আছে? দীর্ঘ পাবলিক পদ্ধতি থাকা বা প্রতিটি টুকরো পুনরায় ব্যবহারযোগ্য না করা সত্ত্বেও সেগুলি ছোট ছোট করে টুকরো টুকরো করা কি ভাল?

coding-style readability

— Jordak
সূত্র

14

এর সম্ভাব্য সদৃশটি লম্বা ফাংশন এবং পদ্ধতিগুলি ছোটগুলিতে বিভক্ত করা ঠিক আছে যদিও তাদের অন্য কিছু দ্বারা ডাকা হবে না?

— gnat

7

সমস্ত উত্তর মতামত ভিত্তিক হয়। মূল লেখকরা সবসময় তাদের রাভিওলি কোডটি আরও পঠনযোগ্য বলে মনে করেন; পরবর্তী সম্পাদকগণ এটিকে রাভিওলি বলে।

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

5

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

— কেট

1

আমি মনে করি এটি আপনার দলের উপর নির্ভর করে এবং কোডের কোন লাইন রয়েছে।

— আশাকরি 18

1

স্ট্রেটস-এর পুরো কাঠামোটি কি একক-ব্যবহারের গেটর / সেটার পদ্ধতিগুলির ভিত্তিতে নয়, সেগুলি সবই একক-ব্যবহারের পদ্ধতি?

— Zibbobz

203

না, এটি কোনও খারাপ স্টাইল নয়। আসলে এটি খুব ভাল স্টাইল।

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

খুব বেশি করে এমন একটি ফাংশন বিবেচনা করুন। এটি একশ লাইনের দীর্ঘ এবং এর সম্পর্কে বিতর্ক করা অসম্ভব।

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

আপনি যখন কোনও বড় সমস্যাটিকে ছোট সমস্যায় পরিণত করেন তখনও যদি এই ছোট সমস্যাগুলি (ফাংশনগুলি) কেবল একবার ব্যবহার / সমাধান করা হয় তবে আপনি বেশ কয়েকটি সুবিধা পান:

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

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

7

বিমূর্ততা এবং ভাল নামগুলির ধারাবাহিক স্তর বজায় রাখতে ভুলবেন না যে পদ্ধতিগুলির মধ্যে উঁকি দেওয়া নিশ্চিত করে যে আপনাকে অবাক করে না। কোনও পুরো বস্তু সেখানে লুকিয়ে থাকলে অবাক হবেন না।

— candied_orange

14

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

— সুপারক্যাট

7

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

— ম্যাথিউ গুইনডন

7

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

— ম্যাথিউ গুইন্ডন

6

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

— ডিউক্লিং

36

এটি সম্ভবত একটি দুর্দান্ত ধারণা!

আপনার কোডবেজে গড় ফাংশনটির দৈর্ঘ্য হ্রাস করার জন্য আমি ক্রমের দীর্ঘ লিনিয়ার ক্রমগুলি পৃথক ফাংশনে বিভক্ত করার বিষয়টি গ্রহণ করি না :

function step1(){
  // ...
  step2(zarb, foo, biz);
}

function step2(zarb, foo, biz){
  // ...
  step3(zarb, foo, biz, gleep);
}

function step3(zarb, foo, biz, gleep){
  // ...
}

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

তবে , আপনি যদি এক বা একাধিক লাইন বিশুদ্ধ ফাংশনটিতে নিষ্ক্রিয় করতে সক্ষম হন যা একক, পরিষ্কার উদ্দেশ্যে কাজ করে ( এমনকি কেবল একবার বলা হয়ে থাকে ) তবে আপনি পাঠযোগ্যতার উন্নতি করেছেন:

function foo(){
  f = getFrambulation();
  g = deglorbFramb(f);
  r = reglorbulate(g);
}

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

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

তারপরে আপনি যখন আরও কার্যকারিতা যুক্ত করতে কয়েক সপ্তাহ পরে ফিরে আসেন এবং আপনি দেখতে পান যে আপনি সেই ফাংশনগুলির মধ্যে একটি পুনরায় ব্যবহার করতে পারেন , তবে ওহ, পরমানন্দিত আনন্দ! কি বিস্ময়কর আলোকিত আনন্দ!

— DaveGauer
সূত্র

2

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

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

34

@ ফ্র্যাঙ্কহিল্যান ন্যায্য বলতে আমি কোনও বিকাশকারীকে তার পূর্বসূরির কোডটির প্রশংসা করতে দেখিনি।

— টি। সার

4

@ টিএসআর আগের বিকাশকারীই সমস্ত সমস্যার উত্স!

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

18

@ টিএসআর আমি আগের বিকাশকারী যখন ছিলাম তখনও আমি পূর্ববর্তী বিকাশকারীকে প্রশংসাও করি নি।

— IllusiveBrian

3

foo = compose(reglorbulate, deglorbFramb, getFrambulation);

— পচানোর

19

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

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

তাদের অভ্যন্তরীণ সংহতি এবং সংযোগের উপর ভিত্তি করে কার্যগুলি পচন করুন, নিরঙ্কুশ দৈর্ঘ্যের নয়।

— dlasalle
সূত্র

6

পঠনযোগ্যতা উপেক্ষা করুন, আসুন বাগের প্রতিবেদনের দিকটি দেখুন: যদি ব্যবহারকারী রিপোর্ট করেন যে কোনও বাগটি ঘটেছিল MainMethod(সহজেই পাওয়া সহজ হয়, সাধারণত প্রতীকগুলি অন্তর্ভুক্ত থাকে এবং আপনার একটি প্রতীক ডিरेফারেশন ফাইল থাকা উচিত) যা 2 কে লাইন (রেখার সংখ্যাগুলি কখনই এতে অন্তর্ভুক্ত থাকে না) বাগ রিপোর্টগুলি) এবং এটি এমন একটি এনআরই যা lines লাইনের 1 ক-এ ঘটতে পারে, ভাল করে যদি আমি এটির দিকে তাকিয়ে থাকি তবে আমাকে ধিক্কার জানানো হবে। তবে যদি তারা আমাকে বলে যে এটি ঘটেছিল SomeSubMethodAএবং এটি 8 টি লাইন এবং ব্যতিক্রম একটি এনআরই ছিল, তবে আমি সম্ভবত এটি যথেষ্ট সহজ খুঁজে পেতে এবং ঠিক করব।

— 410_

2

আইএমএইচও, জটিলতা ভাঙার মাধ্যম হিসাবে নির্ভুলভাবে কোডের ব্লকগুলি বের করার মান, প্রায়শই এর মধ্যে জটিলতার পার্থক্যের সাথে সম্পর্কিত হতে পারে:

কোডটি কী করে তার একটি সম্পূর্ণ এবং নির্ভুল মানব-ভাষা বর্ণনা, কীভাবে এটি কোণার কেসগুলি পরিচালনা করে এবং
কোড নিজেই।

কোডটি বর্ণনার চেয়ে অনেক জটিল হলে, ফাংশন কলের সাথে ইন-লাইন কোডটি প্রতিস্থাপন করা পার্শ্ববর্তী কোডটি বুঝতে সহজ করে তুলতে পারে। অন্যদিকে, কিছু ধারণা কম্পিউটারের ভাষায় মানুষের ভাষার চেয়ে বেশি সহজেই প্রকাশ করা যায় read আমি বিবেচনা করব w=x+y+z;, উদাহরণস্বরূপ, এর চেয়ে বেশি পাঠযোগ্য w=addThreeNumbersAssumingSumOfFirstTwoDoesntOverflow(x,y,z);।

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

— supercat
সূত্র

2

আপনার ফাংশনের নাম বিভ্রান্তিকর। ডাব্লু = x + y + z এর মধ্যে এমন কোনও কিছুই নেই যা কোনও প্রকার ওভারফ্লো নিয়ন্ত্রণকে ইঙ্গিত করে, অন্যদিকে পদ্ধতিটির নামটি অন্যথায় বোঝায়। আপনার ফাংশনের আরও ভাল নাম হবে "অ্যাডএল (এক্স, ওয়াই, জেড)", উদাহরণস্বরূপ, এমনকি "সাম (x, y, z)"।

— টি। সার

6

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

— টি। সার

1

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

— টি। সার

1

@ তাতার: নামটি নিয়ে আমি কিছুটা আগ্রহী ছিলাম, তবে মূল কথাটি হ'ল (গড়ের দিকে যাওয়া সত্ত্বেও এটি আরও ভাল উদাহরণ) প্রসঙ্গত "(x + y + z + 1) / 3" দেখেন এমন একজন প্রোগ্রামার হবেন যে কেউ সংজ্ঞা বা কল সাইটের দিকে তাকিয়ে আছেন তার চেয়ে কলিং কোডটি দেওয়া গড় হিসাবে গণ্য করার উপযুক্ত উপায় কিনা তা আরও ভালভাবে স্থাপন করা উচিত int average3(int n1, int n2, int n3)। "গড়" ফাংশনটি বিভক্ত করার অর্থ হ'ল যে কেউ এটি প্রয়োজনীয়তার জন্য উপযুক্ত কিনা তা দেখতে চেয়েছিলেন তাকে দুটি জায়গায় দেখতে হবে।

— সুপারক্যাট

1

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

— টি। সার

2

এটি ভারসাম্যপূর্ণ চ্যালেঞ্জ।

আরও ভাল হয়

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

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

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

পরবর্তী রক্ষণাবেক্ষণেও সহায়তা করা হয়, কারণ অতিরিক্ত নামকরণ কোডটি স্ব-ডকুমেন্টিং করতে সহায়তা করে ।

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

যতক্ষণ না এটি খুব সূক্ষ্ম হয়

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

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

— জিরকা হানিকা
সূত্র

1

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

তবে মাঝে মাঝে আমার কাছে একটি বড় পাবলিক পদ্ধতি থাকে যা ছোট ছোট ধাপে বিভক্ত হয়ে যায়

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

কেন ব্যক্তিগত পদ্ধতিগুলিতে পচা হয় না? এখানে কয়েকটি কারণ রয়েছে:

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

তবে আমি উদ্বিগ্ন যে এই পদ্ধতিটি যে কেউ পড়তে বাধ্য করে বিভিন্ন ব্যক্তিগত পদ্ধতিতে ঝাঁপিয়ে পড়তে পঠনযোগ্যতার ক্ষতি করে

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

— স্যামুয়েল
সূত্র

1

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

— উইলসি

1

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

— স্যামুয়েল

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

— চিরকাল 21