একটি ফাংশন খুব ছোট হতে পারে?


125

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

function conditionMet(){
   return x == condition;
}

অথবা

function runCallback(callback){
   if($.isFunction(callback))
     callback();
}

এই অলস না একটি খারাপ অভ্যাস? আমি কেবলই জিজ্ঞাসা করি কারণ এটির ফলে সংখ্যার ফাংশন সংখ্যক যুক্তিযুক্ত ক্ষুদ্র ক্ষুদ্র অংশের জন্য কল করে।


3
না, খুব ছোট নয়। সি # তে আমি সম্পত্তি হিসাবে 'শর্ত পূরণ' করবো যা মার্জিত, এবং ব্যবহার বিবেচনা করবে Assert.AreEqual<int>(expected, actual, message, arg1, arg2, arg3, ...);। দ্বিতীয়টি যেমন আছে ঠিক আছে। আমি সম্ভাব্যভাবে একটি bচ্ছিক বুল পতাকা অন্তর্ভুক্ত করব যা একটি ব্যতিক্রম / ইত্যাদি নিক্ষেপ করবে কিনা তা নির্দেশ করবে। যদি কলব্যাক কোনও ফাংশন না হয়।
চাকরি

38
হ্যাঁ, শুধুমাত্র এক ক্ষেত্রে: ফাংশন myFunction () {}
স্পুকস

5
def yes(): return 'yes'
ডায়েটবুদ্ধ

3
@Spooks - আমি বিভাজন চুল এখানে আছি কিন্তু খালি ফাংশন অন্তত অ্যাডাপ্টারের শ্রেণীর জন্য বৈধ মধ্যে MouseMotionAdapter যেমন download.oracle.com/javase/6/docs/api/java/awt/event/... । অবশ্যই ভাষার সীমাবদ্ধতাগুলি ঘিরে কাজ করার এটি একটি উপায়।
আলেক্সি ইয়ার্তিয়াহো

3
@ ডায়েটবুদ্ধ: প্রয়োজনীয়তা সবেমাত্র পরিবর্তিত হয়েছে - এখন পরের সপ্তাহে এটি একটি ডেমো জন্য দুটি ভাষা সমর্থন করতে হবে। "ডিএফ হ্যাঁ ()" লিখেছেন এমন লোকটি "ডিএফ হ্যাঁ": "(ইজফ্রান্স ()? 'ওউই': 'হ্যাঁ') এ পরিবর্তন করার আগে তার খুব আনন্দ পেয়েছিল"
অ্যান্ড্রু শেফার্ড

উত্তর:


167

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

1) আপনার কোড পঠনযোগ্যতা দশগুণ বৃদ্ধি করে।

2) পাঠযোগ্যতার কারণে আপনার কোডটির প্রক্রিয়াটি নির্ণয় করা এত সহজ easy

3) DRY - নিজেকে পুনরাবৃত্তি করবেন না - আপনি এটি খুব ভালভাবে মেনে চলছেন!

4) পরীক্ষামূলক। ক্ষুদ্র ফাংশনগুলি প্রায় 200 বারের মতো আমরা দেখতে পাই সেই 200 লাইন পদ্ধতিগুলির চেয়ে পরীক্ষা করা এক মিলিয়ন গুণ সহজ।

ওহ এবং পারফরম্যান্সের দিক দিয়ে "ফাংশন হপিং" নিয়ে চিন্তা করবেন না। "রিলিজ" তৈরি করে এবং সংকলক অপটিমাইজেশন এটি খুব সুন্দরভাবে আমাদের যত্ন করে এবং সিস্টেম ডিজাইনের অন্য কোথাও 99% সময় পারফরম্যান্স হয়।

এ কি অলস? - খুব বিপরীত!

এটা কি খারাপ অভ্যাস? - একেবারে না. ট্যারি বল বা "গড অবজেক্টস" যা ওহ খুব সাধারণ, তার চেয়ে বেশি পদ্ধতি তৈরি করার পক্ষে এটি উত্তম।

আমার সহকর্মী ভাল কাজটি চালিয়ে যান;)


40
আপনি প্রশ্নের উত্তর দিচ্ছেন না, আপনি কেবল এমন বিধি প্রচার করছেন যাঁর আরও চরম প্রয়োগগুলি এখানে প্রশ্নবিদ্ধ।

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

4
+5 ... ওহ কেবল +1 করতে পারে, ওহ ভাল! এবং মেশমানকে সমর্থন করার জন্য, আমি রবার্ট সি মার্টিন ক্লিন কোড দ্বারা নিম্নলিখিত বইয়ের পরামর্শ দিই । আমি এখন প্রোগ্রাম করার পদ্ধতিটি এই বইটি সত্যিই পরিবর্তন করছে।
এরিক-কার্ল

10
খুব পছন্দসই উত্তর, তবে আমি এর বেশিরভাগের সাথে একমত নই: ১) প্রতিটি ফাংশনের জন্য প্রয়োজনীয় সমস্ত প্লাম্বিংয়ের কারণে অত্যন্ত ছোট ফাংশনগুলি সামগ্রিকভাবে আরও কোডের ফলাফল করে code এটি পাঠযোগ্যতা হ্রাস করতে পারে, বিশেষত সত্যিকারের একটি বড় প্রকল্পের জন্য। এছাড়াও, ভাষা নির্ভর। 2) পুরোপুরি 1 পয়েন্টের উপর নির্ভর করে এবং সুতরাং প্রশ্নের সাথে কোনও সম্পর্ক নেই। 3) কি? রানক্যালব্যাক চারবার "কলব্যাক" পুনরাবৃত্তি করে এবং তিনবার একই ফাংশনটি চালানোর জন্য একই চলকটিকে বোঝায়। 4) 200+ লাইন পদ্ধতি অবশ্যই পরীক্ষামূলক নয়, তবে এটি থেকে এক লাইনে দীর্ঘ পথ রয়েছে।
l0b0

10
-১: এখানে সবচেয়ে ভীতিজনক বিষয় হ'ল এই উত্তরে দেওয়া ভোটের সংখ্যা।
লুকা

64

আমি বলব যে একটি রিফ্যাক্টর পদ্ধতি খুব ছোট যদি হয়:

  • এটি একটি আদিম অপারেশনটিকে নকল করে, এটিকে কোনও পদ্ধতি তৈরি করা ছাড়া অন্য কোনও উদ্দেশ্যে:

উদা:

boolean isNotValue() {
   return !isValue();
}

বা ...

  • কোডটি কেবল একবার ব্যবহার করা হয় এবং এর উদ্দেশ্যটি এক নজরে বোঝা সহজ।

উদা:

void showDialog() {
    Dialog singleUseDialog = new ModalDialog();
    configureDialog(singleUseDialog);
    singleUseDialog.show();
}

void configureDialog(Dialog singleUseDialog) {
    singleUseDialog.setDimensions(400, 300);
}

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


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

2
"IsNotValue ()" পদ্ধতিটি খারাপভাবে নামকরণ করা হয়েছে এবং প্রকৃত ডোমেন প্রশ্নটির নাম দেওয়ার জন্য এটি পুনরুদ্ধার করা উচিত।

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

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

3
সম্ভবত এটি নীটপিক করছে, তবে আমি যুক্তি দিয়ে বলব যে আপনার উদাহরণগুলিতে সমস্যাটি খুব বেশি সংক্ষিপ্ত নয়, তবে তারা বর্ণনামূলক মান যুক্ত করে না।
কেপলা

59

একটি ফাংশন খুব ছোট হতে পারে? সাধারণভাবে না।

আসলে এটি নিশ্চিত করার একমাত্র উপায়:

  1. আপনি আপনার নকশায় সমস্ত ক্লাস খুঁজে পেয়েছেন
  2. আপনার ফাংশনগুলি কেবল একটি কাজ করছে।

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

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

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

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

ক্লিনকডার্স.কম-এ ক্লিন কোডের তৃতীয় পর্ব এ সম্পর্কে আরও অনেক কিছু রয়েছে


5
চাচা বব! আপনি এখানে বোর্ডে দেখতে দুর্দান্ত। প্রত্যাশিত হিসাবে, দুর্দান্ত পরামর্শ। আমি এর আগে কখনও "ড্রপ হওয়া অবধি" শব্দটি শোনেনি এবং নিশ্চিতভাবে সোমবার অফিসের চারপাশে এই শব্দটি ব্যবহার করা হবে;)।
মার্টিন ব্লোর

1
আপনি কি আপনার পয়েন্ট # 1 তে বিস্তারিত বলতে ইচ্ছুক? উদাহরণস্বরূপ যে দুর্দান্ত ব্যাখ্যা করা হবে।
ড্যানিয়েল কাপলান

53

বাহ, এই উত্তরগুলির বেশিরভাগটি খুব বেশি সহায়ক নয়।

কারও পরিচয় এটির সংজ্ঞা হিসাবে লিখতে হবে না । এটি হ'ল, যদি ফাংশনের নামটি কেবল ইংরেজীতে লেখা ফাংশনের কোড ব্লক হয় তবে এটি কোনও ফাংশন হিসাবে লিখবেন না।

আপনার ফাংশন conditionMetএবং এই অন্যান্য ফাংশনটি বিবেচনা করুন , addOne(আমার মরিচা জাভাস্ক্রিপ্টের জন্য আমাকে ক্ষমা করুন):

function conditionMet() { return x == condition; }

function addOne(x) { return x + 1; }

conditionMetএকটি সঠিক ধারণা সংজ্ঞা; addOneএকটি টোটোলজিconditionMetভাল কারণ আপনি জানেন না conditionMetকেবল "কন্ডিশন মিট" বলার মাধ্যমে কী কী প্রবিষ্ট হয়, তবে আপনি addOneযদি ইংরেজীতে পড়েন তবে নির্বোধ কেন তা আপনি দেখতে পারেন :

"For the condition to be met is for x to equal condition" <-- explanatory! meaningful! useful!

"To add one to x is to take x and add one." <-- wtf!

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

(এবং একই কারণে, কোডের প্রতিটি লাইনের জন্য মন্তব্য লিখবেন না !)


আরও জটিল কিছু ভাষা নির্মাণ অপরিচিত বা পড়ার পক্ষে কঠিন হতে পারে, এটি এটিকে একটি দরকারী কৌশল হিসাবে তৈরি করে।

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

1
আমি হাস্কেল স্ট্যান্ডার্ড লাইব্রেরি থেকে জিনিসগুলির পরিচয় ফাংশন সম্পর্কে কথা বলছি - আমি মনে করি না যে আপনি আরও "
টোটোলজিকাল

1
@ মিসিংনো বাহ, এটি প্রতারণা করছে: ডি
রে মিয়াসাকা

5
আপনি যদি তাদের বিষয়বস্তুর পরিবর্তে তাদের কার্যক্রমে কার্যাবলির নাম দেন তবে তারা অবিলম্বে নির্বোধ হওয়া বন্ধ করে দেয়। সুতরাং আপনার উদাহরণগুলি উদাহরণস্বরূপ হতে পারে function nametoolong() { return name.size > 15; }বা function successorIndex(x) { return x + 1; } তাই আপনার ফাংশনগুলির সাথে সমস্যাটি আসলে তাদের নামটি খারাপ is
হ্যান্স-পিটার স্টার

14

আমি বলব যে আপনি যদি মনে করেন কোনও কোড যুক্ত করার মাধ্যমে যদি কিছু কোডের অভিপ্রায় উন্নত করা যায় তবে সেই মন্তব্যটি যুক্ত করার পরিবর্তে কোডটিকে নিজস্ব পদ্ধতিতে বের করুন। কোডটি কত ছোট ছিল তা বিবেচ্য নয়।

সুতরাং উদাহরণস্বরূপ যদি আপনার কোডটি দেখতে দেখতে যাচ্ছিল:

if x == 1 { ... } // is pixel on?

পরিবর্তে এটি দেখতে এটি করুন:

if pixelOn() { ... }

সঙ্গে

function pixelOn() { return x == 1; }

বা অন্য কথায়, এটি পদ্ধতির দৈর্ঘ্য সম্পর্কে নয়, স্ব-ডকুমেন্টিং কোড সম্পর্কে।


5
আমার সম্মানিত সহকর্মী উল্লেখ করেছেন যে আপনিও লিখতে পারেন if x == PIXEL_ON। ধ্রুবকটি ব্যবহার করা কোনও পদ্ধতি ব্যবহারের মতো বর্ণনামূলক হতে পারে এবং এটি একটি সামান্য উদ্বেগজনক।
টম অ্যান্ডারসন

7

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


4
সুতরাং পরে এটিকে ফ্যাক্টর করার ক্ষেত্রে কী ভুল, যখন আপনি কেবলমাত্র পরিবর্তিত ওজনের যখন এখনকার পরিবর্তে আপনার প্রয়োজনের প্রমাণ করতে পারেন?
dsimcha

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

হ্যাঁ, এবং সে কারণেই আপনি আপনার কোডটিতে 75% + ওভারহেড রাখতে চান? 3 লাইন হিসাবে লিখিত সিঞ্জার লাইনারটি আসলে 300%।
কোডার

5

আমি যে সমস্ত পোস্ট দেখেছি তার সাথে আমি একমত। এটি ভাল স্টাইল।

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

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

এর মতো কোডটিতে উচ্চ সংহতি এবং কম সংশ্লেষ থাকে যা ভাল কোডিং অনুশীলন।

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


ইনলাইনিং উল্লেখের জন্য +1, কর্মক্ষমতা এবং সংক্ষিপ্ত ফাংশনগুলিতে প্রধান বিবেচ্য ইমো।
গ্রেট ক্লোবোন

4

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

এবং আপনার প্রথম উদাহরণটি গ্লোবালগুলির ব্যবহার সম্পর্কে ইঙ্গিত দেয় (যা কোডের অন্যান্য সমস্যাগুলি সম্পর্কে কথা বলতে পারে বা নাও পারে), আমি এটি আরও রিফেক্টর করব এবং সেই দুটি ভেরিয়েবলকে পরামিতি হিসাবে তৈরি করব:

function conditionMet(x, condition){
   return x == condition;
}
....
conditionMet(1,(3-2));
conditionMet("abc","abc");

দ্য conditionMetউদাহরণস্বরূপ পারে যদি শর্ত দীর্ঘ এবং পুনরাবৃত্তিমূলক যেমন ছিল উপযোগী হতে:

function conditionMet(x, someObject){
   return x == ((someObject.valA + someObject.valB - 15.4) / /*...whole bunch of other stuff...*/);
}

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

7
এই conditionMetফাংশনটি কেবল একটি ভার্বোস ==অপারেটর। এটি সম্ভবত কার্যকর নয়।

1
আমি অবশ্যই গ্লোবাল ব্যবহার করি না। @ মেশমান, ঠিক যেখানে উদাহরণটি এসেছে ... ক্লাসের একটি পদ্ধতি।
মার্ক ব্রাউন

1
@ মার্ক ব্রাউন: @ মেশমান: ঠিক আছে, আমি অনুমান করি কোডের উদাহরণটি নিশ্চিতভাবে জানার জন্য খুব অস্পষ্ট ছিল ...
হতাশায়

আমি এখানে গন্ধ conditionMet (x, relation condition) {পাচ্ছি, যেখানে আপনি এক্স, '==' এবং সম্পর্কটি পাস করেন। তারপরে আপনার '<', '>', '<=', '! =' ইত্যাদির জন্য কোডটি পুনরাবৃত্তি করার দরকার নেই। অন্যদিকে - বেশিরভাগ ভাষায় অপারেটরগুলি (x == শর্ত) ঠিক তেমনটি করে এই কনস্ট্রাক্টগুলি তৈরি করে। পারমাণবিক বিবৃতিগুলির কাজগুলি এক ধাপ অনেক দূরে।
ব্যবহারকারী অজানা

3

এই বিবেচনা:

একটি সাধারণ সংঘর্ষ সনাক্তকরণ ফাংশন:

bool collide(OBJ a, OBJ b)
{
    return(pow(a.x - b.x, 2) + pow(a.y - b.y, 2) <= pow(a.radius + b.radius, 2));
}

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


আমরা যদি এখানে সি এর সাথে লেনদেন করি, আমরা কেবল অপব্যবহার করতে পারি #define;)
কোল জনসন

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

2

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


আমি কোডের লাইনে এটি গণনা করব না, তবে এক্সপ্রেশনে। "(x == শর্ত)" পারমাণবিক, সুতরাং আমি এটিকে কেবল একটি পদ্ধতি / ফাংশনে রেখে দেব, যদি এটি একাধিকবার ব্যবহৃত হয় এবং পরিবর্তিত হতে পারে function isAdult () = { age >= 18; }তবে এর মতো তবে অবশ্যই না isAtLeast18
ব্যবহারকারী অজানা

2

আমি বলব যে তারা খুব ছোট, তবে এটি আমার বিষয়গত মতামত।

কারণ:

  • যদি কেবল একবার বা দুবার ব্যবহার করা হয় তবে কোনও ফাংশন তৈরি করার কোনও কারণ নেই। Defs যাও স্তন্যপান স্তন্যপান। বিশেষত আশ্চর্যজনকভাবে দ্রুত ভিএস এবং সি ++ কোড সহ।
  • ক্লাস ওভারভিউ। আপনার যখন হাজার হাজার ছোট ছোট ফাংশন থাকে, তা আমাকে ক্রুদ্ধ করে। আমি শ্রেণীর সংজ্ঞা দেখতে এবং এটি কীভাবে তা দ্রুত দেখতে পাই তা উপভোগ করি যখন এটি সেটএক্সটোইন, সেটওয়োটোভেেক্টর 3, মাল্টিপ্লাই নাম্বারস, + 100 সেটার / গেটারগুলি নয়।
  • বেশিরভাগ প্রকল্পে এই সহায়কগুলি এক আকরিক দুটি রিফ্যাক্টরিং পর্যায়ের পরে মৃত ওজন হয়ে যায় এবং তারপরে আপনি অপ্রচলিত কোড থেকে পরিত্রাণ পেতে "সমস্ত অনুসন্ধান করুন" -> মুছুন, সাধারণত এটির + 25% +।

লম্বা ফাংশনগুলি খারাপ তবে ফাংশনগুলি যা 3 টি লাইনের চেয়ে কম হয় এবং কেবল 1 টি কাজ করে তা সমানভাবে খারাপ আইএমএইচও হয়।

সুতরাং আমি যদি বলি যে কেবল ছোট ফাংশনটি লিখুন এটি:

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

আমি বাজি রেখেছি যে পরবর্তী বিকাশকারী (সিনিয়র) আপনার সমস্ত সেটএক্সটোইন ফাংশন মনে রাখার চেয়ে বেশি ভাল কাজ করবে। সুতরাং তারা খুব শীঘ্রই যে কোনও উপায়ে মরা ওজনে পরিণত হবে।


1

উদাহরণটি আমার পছন্দ নয়। 1, ith জেনেরিক নাম কারণ।

conditionMetজেনেরিক বলে মনে হচ্ছে না, তাই এটি একটি নির্দিষ্ট শর্তের জন্য দাঁড়িয়ে? মত

isAdult () = { 
  age >= 18 
}

এটা ঠিক আছে। এটি একটি অর্থপূর্ণ পার্থক্য, যখন

isAtLeast18 () { age >= 18; } 

আমার জন্য ভাল হবে না।

হতে পারে এটি প্রায়শই ব্যবহৃত হয় এবং পরবর্তী পরিবর্তনের জন্য এটি হতে পারে:

getPreferredIcecream () { return List ("banana", "choclate", "vanilla", "walnut") }

খুব ভাল। এটি একাধিকবার ব্যবহার করার পরে, আপনাকে কেবল একটি স্থান পরিবর্তন করতে হবে, যদি আপনার করতে হয় - সম্ভবত হুইপযুক্ত ক্রিম আগামীকালই সম্ভব হয়ে উঠবে।

isXYZ (Foo foo) { foo.x > 15 && foo.y < foo.x * 2 }

পারমাণবিক নয়, এবং আপনাকে একটি দুর্দান্ত পরীক্ষার সুযোগ দেওয়া উচিত।

আপনার যদি কোনও ফাংশন পাস করার দরকার হয় তবে অবশ্যই আপনার যা পছন্দ করুন তা পাস করুন এবং অন্যথায় নির্বোধ দেখাচ্ছে ফাংশনগুলি লিখুন।

তবে সাধারণভাবে আমি খুব বেশি ফাংশন দেখতে পাচ্ছি যা খুব দীর্ঘ, যেগুলি খুব ছোট functions

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

function lessThan (a, b) {
  if (a < b) return true else return false; 
}

যদি আপনি দেখতে পান যে এটি একই রকম

return (a < b); 

আপনার কোন সমস্যা হবে না

localLessThan = (a < b); 

পরিবর্তে

localLessThan = lessThan (a, b); 

0

কোনও কোডের মতো কোড নেই!

এটিকে সহজ রাখুন এবং জিনিসগুলিকে জটিল করবেন না।

এটি অলস হচ্ছে না, এটি আপনার কাজ করছে!


0

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

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

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

function int CalculateSomething() {
  int Result = -1;

   // more code, maybe, maybe not

  return Result;
}

0

খুব ছোট কখনও সমস্যা হয় না is সংক্ষিপ্ত ফাংশনগুলির জন্য কয়েকটি কারণ হ'ল:

পুনর্ব্যাবহার্যোগ্যতা

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

Maintainability

আপনি এমন কিছু বিবৃতি ব্যবহার করতে পারেন যা আপনি ভাবেন ভবিষ্যতে পরিবর্তন হতে পারে। যেমন আপনি এখন একটি কলামে একটি চিহ্ন দেখান, তবে পরে এটি অন্য কোনও কিছুতে (বা এমনকি একটি বীপ) পরিবর্তিত হতে পারে।

একরূপতা

আপনি উদাহরণস্বরূপ মুখোমুখি প্যাটার্নটি ব্যবহার করছেন এবং একটি ফাংশনটি কেবলমাত্র কাজটি যুক্তি পরিবর্তন না করেই অন্যকে ফাংশনটি পাস করছে।


0

আপনার একটি কোডের অধ্যায় একটি নাম দিন, এটা একটি দেবার জন্য মূলত হয় নাম । এটি বেশ কয়েকটি কারণে হতে পারে, তবে গুরুত্বপূর্ণ বিষয়টি যদি আপনি এটির কোনও অর্থপূর্ণ নাম দিতে পারেন যা আপনার প্রোগ্রামকে যুক্ত করে। "AddOneToCounter" এর মতো নাম কিছু যোগ করবে না, তবেconditionMet() করবে।

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


0

না, তবে এটি খুব ক্লান্ত হতে পারে।

মনে রাখবেন: কোড একবার লেখা হয়, তবে অনেকবার পড়ে read

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


-1

হ্যাঁ প্রিয়, ফাংশনটি ছোট এবং ছোট হতে পারে এবং এটি ভাল বা খারাপ তা আপনার ব্যবহার করা ভাষা / ফ্রেমওয়ার্কের উপর নির্ভর করে।

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

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

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

data => initScroll(data)

ES 2017 জাভাস্ক্রিপ্ট এবং টাইপসক্রিপ্ট একটি বেনাম ফাংশন

getMarketSegments() {
 this.marketService.getAllSegments(this.project.id)
  .subscribe(data => this.segments = data, error => console.log(error.toString()));
}

উপরের কোডে আপনি দেখতে পারেন 3 ফাংশন ঘোষণা এবং 2 ফাংশন কল এটি টাইপস্ক্রিপ্ট সহ কৌনিক 4 এ একটি সাধারণ সার্ভিস কল। আপনি এটিকে আপনার প্রয়োজনীয়তা হিসাবে ভাবতে পারেন

([] 0)
([x] 1)
([x y] 2)

উপরোক্ত ক্লোজার ল্যাঙ্গুয়েজে 3 বেনামে ফাংশন রয়েছে

(def hello (fn [] "Hello world"))

উপরেরটি ক্লোজারে একটি কার্যকরী ঘোষণা

হ্যাঁ ফাংশনগুলি যতটা ছোট হতে পারে তবে এটির মতো ভাল বা খারাপ তা আপনার মতো ফাংশন থাকলে:

incrementNumber(numb) { return ++numb; }

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

অন্য উদাহরণ নিতে দিন

insertInArray(array, newKey) {
 if (!array.includes(newKey)) {
   array.push(newKey);
 }
}

কৌণিক এইচটিএমএল টেম্পলেটগুলির অভ্যন্তরে অ্যারে খেললে উপরের উদাহরণটি আবশ্যক। তাই কখনও কখনও আপনাকে ছোট ফাংশন তৈরি করতে হবে


-2

আমি এই সময়ে দেওয়া প্রায় উত্তরের সাথে একমত নই।

সাম্প্রতিককালে আমি এমন এক সহকর্মীর সন্ধান পেয়েছি যা সমস্ত ক্লাসের সদস্যদের নীচের মত লিখে থাকে:

 void setProperty(int value){ mValue=value; }
 int getProperty() const { return (mValue); }

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

সম্ভবত প্রোগ্রামার সামগ্রিক যুক্তি মিস করে, ভবিষ্যতের পরিবর্তনগুলি সম্পর্কে এবং কোডটি পুনরায় ব্যবহারের বিষয়ে ভয় করে।

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

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


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

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

2
getters এবং সেটারগুলি ভয়াবহ, তাদের বৈধ ব্যবহার সত্ত্বেও। যদি এগুলি ব্যবহার করা প্রয়োজন হয় তবে আমি এটিকে ভাষার ব্যর্থতা বলে মনে করি।
কারসন মায়ার্স

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

@ মিথ্যা কি? আমি কখনও বলিনি যে ডিনোমিনেটরগুলি পরীক্ষা করতে কোনও বাহ্যিক শ্রেণি ব্যবহার করা উচিত। আমি বলছি যে কোনও বহিরাগত শ্রেণি দুর্ঘটনাক্রমে 0 এর জন্য একটি বিভাজন স্থাপন করে। সেটারগুলিতে বৈধতা যাচাইয়ের উদ্দেশ্য হ'ল গ্রাহক কোডের যে কোনও বাগ আগে খুঁজে পেতে উত্সাহ দেওয়া। একটি আইএসডিভিজিবল () ফাংশন সরবরাহ করা যা বলা যেতে পারে বা নাও বলা শেষ পর্যন্ত কাজ করে না। এবং ঠিক কীভাবে গেটার্স / সেটটারগুলির প্রয়োজনীয়তা নির্দেশ করে যে উচ্চ সংযুক্তি রয়েছে?
রে মিয়াসাকা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.