দু'বার পুনরাবৃত্তি করা দরকার এমন কোনও কিছুর জন্য একটি ফাংশন লিখতে কি সর্বদা সেরা অনুশীলন?

Question

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

দুটি লাইনের চেয়ে বেশি কোড দরকার এমন কোডের জন্য আমি একটি ফাংশন লিখব। তবে যখন এই জাতীয় বিষয়গুলির মুখোমুখি হন:

print "Hi, Tom"
print "Hi, Mary"

আমি লিখতে দ্বিধা করছি:

def greeting(name):
    print "Hi, " + name

greeting('Tom')
greeting('Mary')

দ্বিতীয়টি খুব বেশি মনে হয়, তাই না?

---

তবে আমাদের যদি কী হয়:

for name in vip_list:
    print name
for name in guest_list:
    print name

এবং এখানে বিকল্প:

def print_name(name_list):
    for name in name_list:
        print name

print_name(vip_list)
print_name(guest_list)

বিষয়গুলি জটিল হয়ে ওঠে, না? এখনই সিদ্ধান্ত নেওয়া শক্ত।

এ সম্পর্কে আপনার মতামত কী?

Comments

আমি চিকিত্সা alwaysএবং neverলাল পতাকা হিসাবে। একটা জিনিস "প্রসঙ্গ" বলা, কোথায় alwaysএবং neverবিধি, এমনকি সাধারণভাবে ভাল হলে, না যে উপযুক্ত হতে পারে। রহস্যজনক ব্যবসায়ের ক্ষেত্রে সফ্টওয়্যার বিকাশকারীদের থেকে সাবধান থাকুন। ;)

— async

আপনার শেষ উদাহরণে আপনি কি করতে পারেন: from itertools import chain; for name in chain(vip_list, guest_list): print(name)।

— বাকুরিউ

@ user16547 আমরা সেই 'সিথওয়্যার বিকাশকারী' বলি!

— ব্রায়ান

টিম পিটারসের দ্বারা পাইথনের জেন থেকে:Special cases aren't special enough to break the rules. Although practicality beats purity.

— জেনন

এছাড়াও আপনি "স্যাঁতসেঁতে কোড" বা "শুকনো কোড" চান কিনা তা বিবেচনা করুন স্ট্যাকওভারফ্লো.com

— ইয়ান

Answer 1

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

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

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

Comments

রবার্ট হার্ভির উত্তরে আমি এই বিষয়টি মিস করি।

— ডক ব্রাউন

প্রকৃতপক্ষে. আমি প্রায়শই জটিল ফাংশনগুলিকে ইনলাইনড সাববুটিনগুলিতে বিভক্ত করি - কোনও পারফ হিট না, তবে পরিষ্কার। নামবিহীন স্কোপগুলিও ভাল।

— imallett

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

— জোশুয়া টেলর

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

— Svish

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

— ডেভিড হামেন

Answer 2

সদৃশটি দুর্ঘটনার পরিবর্তে ইচ্ছাকৃত হলে ।

অথবা, অন্য কোনও উপায় রাখুন:

আপনি যদি ভবিষ্যতে তাদের সহ-বিকাশের আশা করেন তবেই ।

---

কারণটা এখানে:

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

চলতি নিয়ম:

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

Comments

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

— yoniLavi

এটি রুবি, তবে অ্যাভিডি গ্রিম থেকে কমনসিডেন্টাল ডুপ্লিকেশন সম্পর্কে এই স্ক্রিনকাস্ট এখনও প্রশ্নের সাথে সম্পর্কিত: youtube.com/watch?v=E4FluFOC1zM

— ডিজিএম

Answer 3

না, এটি সর্বদা সেরা অনুশীলন নয়।

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

তাহলে কেন কোড পৃথক পদ্ধতিতে রিফ্যাক্টর হয়? পরিমিতি উন্নতি করতে। একটি পৃথক পদ্ধতির পিছনে উল্লেখযোগ্য কার্যকারিতা সংগ্রহ এবং এটি একটি অর্থবহ নাম দেওয়ার জন্য। যদি আপনি এটি সম্পাদন না করে থাকেন তবে আপনার সেই পৃথক পদ্ধতির দরকার নেই।

Comments

কোড পাঠযোগ্যতা সবচেয়ে গুরুত্বপূর্ণ।

— টম রবিনসন

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

— ডক ব্রাউন

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

— জন গল্প

Why take the performance hit of a function call when you don't get any significant benefit by doing so?কোন পারফরম্যান্স হিট? সাধারণ ক্ষেত্রে ছোট ফাংশনগুলি ইনলাইনড হয়ে যায় এবং ওভারহেড বড় ফাংশনগুলির জন্য নগণ্য। সিপথন সম্ভবত ইনলাইন করে না, তবে কেউ এটিকে পারফরম্যান্সের জন্য ব্যবহার করে না। আমিও line by line code...কিছুটা প্রশ্ন করি । আপনি যদি আপনার মস্তিস্কে নির্বাহের অনুকরণ করার চেষ্টা করেন তবে এটি আরও সহজ। তবে একটি ডিবাগার আরও ভাল কাজ করবে এবং লুপটি কার্যকর করে তার কিছু প্রমাণ করার চেষ্টা করা যেমন সমস্তটির উপর পুনরাবৃত্তি করে পূর্ণসংখ্যা সম্পর্কে একটি বিবৃতি প্রমাণ করার চেষ্টা করার মতো।

— ডোভাল

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

— জন গল্প

Answer 4

আপনার বিশেষ উদাহরণে কোনও ফাংশন তৈরির বিষয়টি ওভারকিল মনে হতে পারে; পরিবর্তে আমি এই প্রশ্নটি জিজ্ঞাসা করব: ভবিষ্যতে কি এই বিশেষ অভিবাদনটি পরিবর্তন হতে পারে? তা কেমন করে?

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

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

এগুলি শেষ পর্যন্ত সম্ভাব্য প্রয়োজনীয়তা এবং আপনার ভবিষ্যতের স্ব-কাজটি সহজ করার জন্য জিনিসগুলি আগে থেকেই পরিকল্পনা করার বিষয়ে।

Comments

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

— লরেন পেচটেল

Answer 5

যা আমি কল করে ন্যায্যতা প্রতিপাদন করা হবে - ব্যক্তিগতভাবে আমি তিন শাসন গ্রহণ করেছে YAGNI । আমি যদি একবার সেই কোডটি লিখি তবে আমার কিছু করার প্রয়োজন হয়, দুবার আমি কেবল অনুলিপি / পেস্ট করতে পারি (হ্যাঁ আমি কেবল অনুলিপি / পেস্ট করতে স্বীকার করেছি!) কারণ আমার আবার এটি দরকার নেই, তবে যদি আমার একই জিনিস করার দরকার হয় জিনিস আবার তারপর আমি refactor এবং এটি এর নিজস্ব পদ্ধতি মধ্যে যে খণ্ড বের করব, আমি নিজেকে প্রদর্শিত করেছি,, আমি হবে এটা আবার প্রয়োজন।

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

Comments

সি

— pimlottc

Answer 6

এটি খুব কমই পরিষ্কার-কাট, তাই আপনার বিকল্পগুলি ওজন করতে হবে:

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

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

যাইহোক, পাইথনে এটি পুনরায় ব্যবহার করা মোটামুটি হালকা-ওজন, যুক্তির পুনরাবৃত্তি না করে। আইএমও, আরও অনেক অন্যান্য ভাষার চেয়ে (অন্তত .তিহাসিকভাবে)।

সুতরাং, স্থানীয় যুক্তি থেকে একটি তালিকা তৈরি করে উদাহরণস্বরূপ, স্থানীয়ভাবে কেবল যুক্তি পুনরায় ব্যবহার বিবেচনা করুন:

def foo():
    for name_list in (vip_list, guest_list): # can be list of tuples, for many args
        for name in name_list:
            print name

আপনি কয়েকটি টিপলস টিপল ব্যবহার করতে পারেন এবং এটির জন্য সরাসরি লুপে বিভক্ত করতে পারেন, যদি আপনার বেশ কয়েকটি যুক্তি প্রয়োজন হয়:

def foo2():
    for header, name_list in (('vips': vip_list), ('people': guest_list)): 
        print header + ": "
        for name in name_list:
            print name

বা একটি স্থানীয় ফাংশন তৈরি করুন (সম্ভবত আপনার দ্বিতীয় উদাহরণটি হ'ল), যা যুক্তিটিকে পুনরায় ব্যবহার স্পষ্ট করে তোলে তবে স্পষ্টভাবে দেখায় যে মুদ্রণ_নাম () ফাংশনের বাইরে ব্যবহার করা হয়নি:

def foo():
    def print_name(name_list):
        for name in name_list:
            print name

    print_name(vip_list)
    print_name(guest_list)

ফাংশনগুলি অগ্রাধিকারযোগ্য বিশেষত যখন আপনার মাঝখানে যুক্তিটি বাতিল করতে হবে (অর্থাত্ রিটার্ন ব্যবহার করুন), কারণ বিরতি বা ব্যতিক্রমগুলি অযথা জিনিসকে বিশৃঙ্খলা করতে পারে।

হয় একই যুক্তি, আইএমও পুনরাবৃত্তি করার চেয়ে উচ্চতর, এবং কেবলমাত্র একজন কলার (দুইবার হলেও) ব্যবহৃত বৈশ্বিক / শ্রেণির ফাংশন ঘোষণার চেয়ে কম বিশৃঙ্খলা।

Comments

এই উত্তরটি দেখার আগে আমি নতুন ফাংশনের সুযোগ সম্পর্কে একই মন্তব্য পোস্ট করেছি। আমি খুশি যে প্রশ্নের উত্তরটির একটি উত্তর রয়েছে glad

— জোশুয়া টেলর

+1 - এটি সম্ভবত ওপি খুঁজছেন এমন উত্তর নয়, তবে কমপক্ষে তিনি যে ধরণের প্রশ্ন জিজ্ঞাসা করেছেন সে সম্পর্কে, আমি মনে করি এটিই সবচেয়ে বুদ্ধিমান প্রতিক্রিয়া। এটি এমন এক ধরণের জিনিস যা সম্ভবত আপনার জন্য ভাষাতে বেকড হয়ে যাবে।

— প্যাট্রিক কলিন্স

@ পেট্রিককোলিনস: ভোটের জন্য ধন্যবাদ! :) উত্তরটি আরও সম্পূর্ণ করার জন্য আমি কিছু বিবেচনা যুক্ত করেছি।

— ম্যাক 20'15

Answer 7

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

সুতরাং আপনার উদাহরণে: আপনি যদি ধরে নেন যে আপনার কাছে একটি প্রমিত শুভেচ্ছা আছে এবং আপনি এটি নিশ্চিত করতে চান যে এটি সমস্ত লোকের জন্য একই, তবে লিখুন

def std_greeting(name):
    print "Hi, " + name

for name in ["Tom", "Mary"]:
    std_greeting(name)   # even the function call should be written only once

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

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

print "Hi, Tom"
print "Hello, Mary"

আপনার দ্বিতীয় অংশের জন্য, ফাংশনগুলিতে "প্যাকেজ" কতটা সম্ভবত সিদ্ধান্ত নেওয়া দুটি কারণের উপর নির্ভর করে:

• পঠনযোগ্যতার জন্য ব্লকগুলি ছোট রাখুন
• ব্লকগুলিকে যথেষ্ট বড় রাখুন যাতে পরিবর্তনগুলি কেবল কয়েকটি ব্লকের মধ্যে ঘটে। কলিং প্যাটার্নটি ট্র্যাক করা খুব বেশি ক্লাস্টার করার দরকার নেই।

আদর্শভাবে, যখন কোনও পরিবর্তন ঘটে তখন আপনি ভাববেন "আমাকে নিম্নলিখিত ব্লকের বেশিরভাগ পরিবর্তন করতে হবে" এবং " বড় ব্লকের ভিতরে আমাকে কোথাও কোড পরিবর্তন করতে হবে " না।

Comments

আপনার লুপটি বিবেচনা করে কেবল একটি বোকা নীট - যদি পুনরাবৃত্তি করার জন্য যদি সত্যিই কেবল কয়েক মুঠো হার্ড-কোডড নাম থাকা দরকার হয় এবং আমরা তাদের পরিবর্তনের প্রত্যাশা করি না, তবে আমি যুক্তি দিয়ে বলছি যে এটি ব্যবহার না করা কিছুটা সুগঠিত তালিকা। for name in "Tom", "Mary": std_greeting(name)

— yoniLavi

ঠিক আছে, কেউ বলতে পারেন যে হার্ড-কোডেড তালিকাটি কোডের মাঝখানে উপস্থিত হবে না এবং যাইহোক এটি একটি পরিবর্তনশীল হবে :) তবে ঠিক, আমি আসলে ভুলে গেছি যে আপনি সেখানে বন্ধনীগুলি এড়িয়ে যেতে পারেন।

— গেরেনুক

Answer 8

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

1. উভয় অভিবাদনকে একইভাবে পরিবর্তন করা প্রয়োজন, [যেমন Bonjour, Tomএবং তার সাথে Bonjour, Mary]।

2. এটির জন্য একটি অভিবাদন পরিবর্তন করা প্রয়োজন তবে অন্যটিকে যেমন [যেমন Hi, Tomএবং Guten Tag, Mary] রেখেছেন তেমনি রেখে যান ।

3. উভয় অভিবাদনকে আলাদাভাবে পরিবর্তন করা প্রয়োজন [যেমন Hello, Tomএবং Howdy, Mary]।

4. অভিবাদন কখনও পরিবর্তন করার প্রয়োজন হয় না।

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

নিশ্চিত হওয়া, ভবিষ্যতের ভবিষ্যদ্বাণী করা সবসময় সম্ভব নয়, তবে কারও যদি বিশ্বাস করার কারণ থাকে যে উভয় অভিবাদনকে একসাথে পরিবর্তন করা দরকার তবে এটি সাধারণ কোড (বা নামযুক্ত ধ্রুবক) ব্যবহারের পক্ষে হয়ে উঠবে factor ; কারও যদি বিশ্বাস করার কারণ থাকে যে এটির সম্ভাবনা বেশি হয় যে একজন বা উভয়ই পরিবর্তিত হতে পারে যাতে তারা ভিন্ন হয়, এটি সাধারণ কোড ব্যবহার করার চেষ্টা করার বিরুদ্ধে একটি কারণ হতে পারে।

Comments

আমি এই উত্তরটি পছন্দ করি কারণ (কমপক্ষে এই সাধারণ উদাহরণের জন্য), আপনি প্রায় কোনও গেমের তত্ত্বের মাধ্যমে পছন্দটি গণনা করতে পারেন।

— রাবারডাক

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

— সুপারক্যাট

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

— সুপারক্যাট

আমি পুরোপুরি একমত. আমি কেবল প্রচলিত বুদ্ধি এটিকে DRY করতে কীভাবে বলছি তা আঁকিয়ে ছিলাম, তবে পরিসংখ্যানগত দিক থেকে , সম্ভবত পুনরাবৃত্তি কোডটি পুনরায় কোডের পুনরাবৃত্তি না হওয়ার সম্ভাবনা বেশি। আপনি মূলত 2 থেকে 1 টি প্রতিক্রিয়া পেয়েছেন।

— রাবারডাক

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

— সুপারক্যাট

Answer 9

আমি মনে করি আপনার কাছে একটি পদ্ধতি তৈরির কারণ থাকতে হবে। একটি পদ্ধতি তৈরির বিভিন্ন কারণ রয়েছে। যেগুলি আমি সবচেয়ে গুরুত্বপূর্ণ বলে মনে করি সেগুলি হ'ল:

1. বিমূর্তন
2. modularity এর
3. কোড নেভিগেশন
4. ধারাবাহিকতা আপডেট করুন
5. পুনরাবৃত্তির
6. পরীক্ষামূলক

বিমূর্তন

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

modularity

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

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

কোড নেভিগেশন

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

ধারাবাহিকতা আপডেট করুন

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

নোট করুন যে আপনার প্রোগ্রামের কার্যকারিতা এবং বিমূর্ততার উপর ভিত্তি করে পদ্ধতিগুলি সংগঠিত করা উচিত। এই মুহুর্তে কোডের দুটি বিট একই হতে পারে কিনা তার ভিত্তিতে নয়।

recursion

পুনরাবৃত্তি ব্যবহার করে আপনার পদ্ধতি তৈরি করা দরকার

পরীক্ষামূলক

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

উপসংহার

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

Answer 10

আপনার দেওয়া কেসের কোনওটিই রিফ্যাক্টরিংয়ের মতো মনে হচ্ছে না।

উভয় ক্ষেত্রেই, আপনি একটি অপারেশন করছেন যা স্পষ্টভাবে এবং সংক্ষিপ্তভাবে প্রকাশিত হয়েছে, এবং অসামঞ্জস্যপূর্ণ পরিবর্তন হওয়ার কোনও আশঙ্কা নেই।

আমি আপনাকে সর্বদা কোড বিচ্ছিন্ন করার উপায়গুলির সন্ধান করার পরামর্শ দিচ্ছি যেখানে:

1. একটি শনাক্তযোগ্য, অর্থপূর্ণ কাজ রয়েছে যা আপনি আলাদা করতে পারবেন এবং

2. উভয় ক্ষেত্রেই

   ক। কাজটি প্রকাশ করা জটিল (আপনার কাছে উপলব্ধ ফাংশনগুলি বিবেচনায় নেওয়া) বা

   B ইংরেজী বর্ণমালার দ্বিতীয় অক্ষর. টাস্কটি একাধিকবার সম্পাদিত হয়েছে এবং এটি উভয় জায়গায় একইভাবে পরিবর্তিত হয়েছে তা নিশ্চিত করার জন্য আপনার একটি উপায় প্রয়োজন,

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

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

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

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

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

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

Answer 11

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

def doIt(smth,smthElse)
    for x in getDataFromSomething(smth,smthElse):
        if not check(x,smth):
            continue
        process(x,smthElse)
        store(x) 

যদিও এই ফাংশন কলগুলি অন্য কোথাও ব্যবহার করা হয় না, তবে যদি 3 টি ফাংশন যথেষ্ট দীর্ঘ এবং নেস্ট লুপ থাকে তবে পাঠযোগ্যতার মধ্যে উল্লেখযোগ্য লাভ রয়েছে etc.

Answer 12

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

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

Answer 13

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

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

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

অনেক দিন আগের একটি উদাহরণ যা আপনার উদাহরণের সাথে কিছুটা মিল। লোকেরা ভাবেন জাভা জিইউআই সৃষ্টি শক্ত is অবশ্যই আপনি যদি এটি কোড করেন তবে:

Menu m=new Menu("File");
MenuItem save=new MenuItem("Save")
save.addAction(saveAction); // I forget the syntax, but you get the idea
m.add(save);
MenuItem load=new MenuItem("Load")
load.addAction(loadAction)

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

আপনি অবশ্যই এর মতো কোড করতে পারবেন না তাই আপনার পিছনে ফিরে সমস্যাটি দেখার দরকার আছে repeated পুনরাবৃত্ত কোডটি আসলে কী করছে? এটি কিছু স্ট্রিং এবং তাদের সম্পর্ক (একটি গাছ) নির্দিষ্ট করে এবং সেই গাছের পাতাগুলিকে ক্রিয়াতে যুক্ত করে। সুতরাং আপনি যা বলতে চান তা হ'ল:

class Menu {
    @MenuItem("File|Load")
    public void fileLoad(){...}
    @MenuItem("File|Save")
    public void fileSave(){...}
    @MenuItem("Edit|Copy")
    public void editCopy(){...}...

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

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

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

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

সুতরাং আমার বিষয়গুলি হ'ল:

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

Answer 14

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

Answer 15

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

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

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

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

Comments

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

— চুটিয়ে

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

— ing

আমি ইনলাইনিংয়ের 3 নেতিবাচক বিষয় উল্লেখ করেছি যেখানে আমি কেবল এটি "আলাদা হওয়া উচিত" দাবি করি না not আমি যা বলছি তা হ'ল আপনি যদি নাম নিয়ে আসতে না পারেন তবে আপনার ইনলাইনটি সম্ভবত খুব বেশি করছে। এছাড়াও আমি মনে করি আপনি একবারে ছোট ব্যবহারের পদ্ধতি সম্পর্কে এখানে একটি বড় পয়েন্ট মিস করছেন। ছোট নামকরণের পদ্ধতি বিদ্যমান তাই আপনাকে কোডটি কী করার চেষ্টা করছে তা জানতে হবে না (আইডিই জাম্প দেওয়ার দরকার নেই)। উদাহরণস্বরূপ এমনকি `if (দিন == 0 || দিন == 6)` বনাম `যদি (isWekend (দিন)) the এর সরল বিবৃতি পড়া এবং মানসিকভাবে মানচিত্রের পক্ষে সহজ হয়ে যায়। এখন আপনার যদি সেই বক্তব্যটি পুনরাবৃত্তি করতে হয় তবে এটি isWeekendকোনও মস্তিষ্কে পরিণত হয়।

— প্লিজ

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

— এসডেনহ্যাম

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

— প্লেনি