দীর্ঘ পদ্ধতি কি সবসময় খারাপ? [বন্ধ]


64

তাই আগে কাছাকাছি খুঁজছি আমি দীর্ঘ পদ্ধতি খারাপ অনুশীলন সম্পর্কে কিছু মন্তব্য লক্ষ্য করেছি।

আমি নিশ্চিত নই যে আমি সর্বদা একমত যে দীর্ঘ পদ্ধতিগুলি খারাপ (এবং অন্যের মতামত চাই)।

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

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

variable_1 = 0
variable_2 = 0
for object in queryset :
     if object.condition_condition_a and variable_2 > 0 :
     variable 1+= 1
     .....
     ...    
     . 
      more conditions to alter the variables

return queryset, and context 

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

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

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

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

তাহলে কি এমন কোনও মামলা রয়েছে যে দীর্ঘ পদ্ধতিগুলি সবসময় খারাপ হয় না? লেখার পদ্ধতিগুলির জন্য কি সবসময় কোনও মামলা রয়েছে, যখন সেগুলি কেবল এক জায়গায় ব্যবহার করা হবে?

আপডেট: দেখে মনে হচ্ছে এক বছর আগে আমি এই প্রশ্নটি জিজ্ঞাসা করেছি।

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

আগে :

#comment 1 
bit of (uncomplicated) code 1a  
bit of code 2a

#comment 2 
bit of code 2a
bit of code 2b
bit of code 2c

#comment 3
bit of code 3

এখন:

method_call_1
method_call_2
method_call_3

def method_1 
    bit of (uncomplicated) code 1a  
    bit of code 2a

def method_2 
    bit of code 2a
    bit of code 2b
    bit of code 2c

def method_3
    bit of code 3

156
সমস্ত রহস্য খারাপ। সর্বদা.
জোচিম সৌর

30
আমি প্রায়শই "আপনি যদি এগুলিকে পুনরায় ব্যবহার করতে পারেন তবে अर्জ করার পদ্ধতিগুলি" তর্কটি দেখতে পাচ্ছেন (এটি বা অনুরূপ আকারে) তবে আমি এটি কিনি না: যদি পদ্ধতিটি একাধিক জিনিস করে থাকে তবে আপনার পঠনযোগ্যতার জন্য এটি থেকে পদ্ধতিগুলি বের করা উচিত / আপনার কোডের কেবলমাত্র একটি স্পট থেকে সেই নতুন পদ্ধতিগুলি কল করা থাকলেও রক্ষণাবেক্ষণযোগ্যতা ।
জোছিম সৌর

4
@ গ্যাनेट: বাহ, বিল্ড-স্টেপে কোনও প্রকার ম্যানুয়াল ইনলাইনিং (প্রিপ্রোসেসরের মাধ্যমে) এখানে কী আরও ভাল সমাধান হতে পারে না?
জোচিম সৌর

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

2
দীর্ঘ পদ্ধতি সর্বদা খারাপ হয় না; তবে এগুলি এমন কিছু যা আপনার সর্বদা দেখতে হবে এবং নিজেকে জিজ্ঞাসা করা উচিত "এটি কি খারাপ?"
কারসন 63000

উত্তর:


80

না, দীর্ঘ পদ্ধতি সর্বদা খারাপ হয় না।

কোড কমপ্লিট বইয়ে এটি পরিমাপ করা হয়েছে যে দীর্ঘ পদ্ধতিগুলি কখনও কখনও লেখার জন্য দ্রুত এবং সহজ হয় এবং রক্ষণাবেক্ষণের সমস্যা তৈরি করে না।

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

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

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

প্রকৃতপক্ষে, আমি দীর্ঘ ক্রিয়াকলাপগুলিতে এই জাতীয় মেট্রিকগুলি পরীক্ষা না করার পরামর্শ দিই, তবে প্রতিটি ফাংশনটিতে স্বয়ংক্রিয় সরঞ্জামগুলি (যেমন জাভা জন্য চেকস্টাইল) দিয়ে তাদের সম্পর্কে সতর্কতা অন্তর্ভুক্ত করার পরামর্শ দিচ্ছি।


41
+1: "না, দীর্ঘ পদ্ধতিগুলি সর্বদা খারাপ হয় না" তবে সেগুলি প্রায় সর্বদা খারাপ
বাইনারি ওয়ারিয়ার

67
দীর্ঘ পদ্ধতির সংস্থাগুলি একটি ধ্রুপদী কোড গন্ধ : এটি নিজের মধ্যে কোনও সমস্যা নয়, তবে এটি সম্ভবত একটি সমস্যা রয়েছে এমন ইঙ্গিত ।
জোচিম সৌর

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

11
আমি মন্তব্যগুলি কমাতে পদ্ধতির নামগুলি ব্যবহার করি। যা মাঝে মাঝে "getSelectedNodeWithChildren" এর মতো জিনিসগুলিতে নিয়ে যায়, তবে আমার সহকর্মী আমাকে বলতে থাকেন যে আমার কোডটি সুন্দরভাবে পাঠযোগ্য। আমি সংক্ষিপ্ত বিবরণ এড়াতে চেষ্টা করি, তারা লিখতে খুব ভাল, তবে পড়তে এত সুন্দর নয়।
কে ..

4
@ da_b0uncer এটিও আমি অনুসরণ করি এমন একটি নীতি। কোডটি লেখার চেয়ে পড়তে পারা শক্ত, সুতরাং কোডকে আরও বেশি পঠনযোগ্য করে তোলার জন্য লেখার সময় অতিরিক্ত পরিশ্রম ফিরিয়ে দেয় না।
ডেডালনিক্স

55

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

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

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

পুনরায় ব্যবহারযোগ্যতা: দীর্ঘ পদ্ধতির কম সংহতি থাকে they তারা প্রায়শই একাধিক কাজ করে। নিম্ন সংহতি পুনরায় ব্যবহারের শত্রু; আপনি যদি একাধিক কার্যকে একটি পদ্ধতির সাথে একত্রিত করেন তবে এটি আগের চেয়ে কম জায়গায় পুনরায় ব্যবহৃত হবে।

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

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

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


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

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

1
@Wwbily_col বিটিডাব্লু, আপনি যদি একটি লিখিত পাঠ্যের সন্ধান করছেন যা ছোট পদ্ধতিগুলির যুক্তি দিয়ে চলেছে, ক্লিন কোডের প্রথম কয়েকটি অধ্যায় পড়ুন , যা ব্যাখ্যাটির বেশ ভাল কাজ করে।
ড্যানিয়েল বি

5
@wobbily_col আপনি বলছেন যে অনেক পদ্ধতি সহ কোড বোঝার জন্য খুব বেশি লাফিয়ে পড়া বিভ্রান্তিকর, আমি মনে করি যে এখানে অনুপস্থিত বিন্দু নামকরণের গুরুত্বের উপর। যদি কোনও পদ্ধতির নামকরণ করা হয় তবে এটি কী করছে তা সন্ধান করার জন্য আপনাকে এটিকে তাকাতে হবে না, কলিং পদ্ধতিটি যে পদ্ধতিগুলি কল করছে তার কোনও অন্তর্নিহিত জ্ঞান ছাড়াই সম্পূর্ণ বোঝা উচিত, উদাহরণস্বরূপ আপনি কখনও ব্যবহার করেছেন someVar.toString()এবং অনুভব করেছেন এটি কী করছে তা জানতে আপনার স্ট্রিংয়ের কোডটি দেখতে হবে? ভাল পদ্ধতি নামকরণের কারণে আপনি ঠিক এটি অতীতে পড়েছেন।
জিমি হোফা

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

28

দীর্ঘ পদ্ধতি সর্বদা খারাপ, তবে বিকল্পগুলির চেয়ে মাঝে মাঝে ভাল are


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

9

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

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


7

দীর্ঘ পদ্ধতি সর্বদা খারাপ হয় না। এগুলি সাধারণত একটি চিহ্ন যে কোনও সমস্যা হতে পারে।

যে সিস্টেমে আমি কাজ করছি তাতে আমাদের অর্ধ ডজন বা তার বেশি পদ্ধতি রয়েছে যেগুলি 10,000 লাইনের বেশি। একটি বর্তমানে 54,830 লাইন দীর্ঘ। এবং এটা ঠিক আছে।

এই হাস্যকরভাবে দীর্ঘ ফাংশনগুলি খুব সাধারণ এবং স্বয়ংক্রিয়ভাবে তৈরি। সেই বড় 54,830 লাইনের দীর্ঘ দৈত্যটিতে 1 জানুয়ারী 1962 থেকে 10 জানুয়ারী, 2012 (আমাদের শেষ প্রকাশ) দৈনিক মেরু গতির ডেটা রয়েছে। আমরা এমন একটি প্রক্রিয়াও প্রকাশ করি যার মাধ্যমে আমাদের ব্যবহারকারীরা সেই অটো-জেনারেটেড ফাইলটি আপডেট করতে পারে। সেই উত্স ফাইলে http://data.iers.org/products/214/14443/orig/eopc04_08_IAU2000.62- এখন থেকে পোলার গতির ডেটা রয়েছে , সি ++ এ স্বয়ংক্রিয় অনুবাদ।

উড়ে যাওয়ার সময় সেই ওয়েবসাইটটি পড়া নিরাপদ ইনস্টলেশনটিতে সম্ভব নয়। বাইরের বিশ্বের সাথে কোনও সংযোগ নেই। স্থানীয় কপি হিসাবে ওয়েব সাইটটি ডাউনলোড করা এবং সি ++ এ পার্স করা কোনও বিকল্প নয়; পার্সিং ধীর গতির এবং এটি দ্রুত হওয়া দরকার। ডাউনলোড করা, সি ++ এ স্বয়ংক্রিয় অনুবাদ করা এবং সংকলন: এখন আপনার কাছে এমন কিছু আছে যা দ্রুত। (কেবল এটি অপ্টিমাইজড সংকলন করবেন না It's একটি অপ্টিমাইজ করা সংকলক অত্যন্ত সহজ সরল লাইন কোডের 50,000 লাইন সংকলন করতে কতক্ষণ সময় লাগে তা অবাক করে দেয় one একটি ফাইল অপ্টিমাইজড ফাইলটি সংকলন করতে আমার কম্পিউটারে আধ ঘন্টা সময় লাগে And অপ্টিমাইজ করার মতো কিছুই নেই It's এটি সরল সরলরেখার কোড, একের পর এক এসাইনমেন্ট স্টেটমেন্ট)


6
"একের পর এক অ্যাসাইনমেন্ট স্টেটমেন্ট" ... আমি এটিকে "ডেটা ফাইল" বলব। এটি কোড কেন?
জোচিম সৌর

3
@ জোচিমসৌয়ার - কারণ মন্টে কার্লো সেটআপে রান সময়ে বড় ডেটা ফাইলকে পার্স করা একটি খারাপ ধারণা। একটি খুব, খুব খারাপ ধারণা।
ডেভিড হামেন

4
@ ডেভিডহ্যামেন: তারপরে এটি আরম্ভের সময় করুন, ঠিক যেমন আপনি নিজের লিঙ্কার / লোডারকে করতে বাধ্য করছেন। অথবা সি কোডের পরিবর্তে একটি হেডার ফাইলে ডেটা ফাইলকে সি কাঠামো হিসাবে লিখুন। অন্ততপক্ষে লোডার ডেটা ব্লক হিসাবে লোড করবে।
জাভিয়ার

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

7
+1 আকর্ষণীয় গল্প। উত্পন্ন কোডটি অবশ্যই উত্সের কোড নয় তাই কোনও যুক্তি দিতে পারে যে এটি নিয়মটি 'ব্রেক' করে না। কেউ ধরে নিচ্ছে কোড জেনারেটর নিজেই ছোট ছোট পদ্ধতিগুলি রেখেছিল
জে কে।

7

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

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

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


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

"আপনার মাথার সবচেয়ে বাহ্যিক পদ্ধতি" রাখার জন্য "রাখার জন্য" + এটি একটি চিহ্ন যা আপনি এটি সবচেয়ে অনুকূল উপায়ে
মাইকেল শ

4

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


34
সর্বদা কমপক্ষে দুটি প্রোগ্রামার জড়িত থাকে: "আপনি" এবং "আপনি, এখন থেকে তিন সপ্তাহ"।
জোচিম সৌর

3

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

অবিকল, আপনার পদ্ধতিটি কেবলমাত্র 1 টি কার্য সম্পাদন করে ফোকাস করা উচিত।

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

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


"একটি ফাংশন ওয়ান থিং করা উচিত" নামে পরিচিত।
প্রভুদেব

3

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

রুটিনগুলির দৈর্ঘ্য সম্পর্কে কোড কমপ্লিট 2 এ একটি দুর্দান্ত সংক্ষিপ্ত আলোচনা রয়েছে।

তাত্ত্বিক সর্বোত্তম 497 সর্বাধিক দৈর্ঘ্য প্রায়শই প্রোগ্রাম তালিকার এক বা দুটি পৃষ্ঠাগুলি, 66 থেকে 132 লাইন হিসাবে বর্ণনা করা হয়। আধুনিক প্রোগ্রামগুলিতে কয়েকটি দীর্ঘ রুটিনের সাথে খুব স্বল্প রুটিনগুলির ভলিউম মিশ্রিত থাকে।

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

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


2

অন্য একটি ভোট যে এটি প্রায় সর্বদা ভুল। যদিও আমি এটির দুটি সঠিক ক্ষেত্রে খুঁজে পাই যেখানে এটির যথাযথ উত্তর, যদিও:

1) এমন একটি পদ্ধতি যা মূলত কেবলমাত্র অন্যান্য পদ্ধতির একটি গোছা কল করে এবং কোনও বাস্তব কাজ নিজেই করে না। আপনার একটি প্রক্রিয়া রয়েছে যা সম্পন্ন করতে 50 টি পদক্ষেপ নেয়, আপনি এটিতে 50 টি কল দিয়ে একটি পদ্ধতি পান get এটিকে ভেঙে দেওয়ার চেষ্টা করে সাধারণত লাভ করার মতো কিছুই নেই।

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

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


1
50 টি ধাপের প্রক্রিয়াটি সম্ভবত বেশ কয়েকটি বালতিতে সংক্ষিপ্ত আকারে নেওয়া যায়। পদক্ষেপ 1 - 9 হ'ল প্যারামিটার চেক তাই প্যারামিটার চেকিং নামে একটি নতুন পদ্ধতি তৈরি করুন। (আমি নিশ্চিত যে এমন কয়েকটি উদাহরণ রয়েছে যেখানে এটি সম্ভব নয় one আমি এটি দেখার আগ্রহী হব)।
ষাট ফুটারসুডে

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

& ষাট ফুটারসুডুড: আপনি যে কোডটি কখনও দেখেননি এবং কীভাবে এটি উন্নত করবেন তা আপনি কীভাবে জানেন তা অবাক করা।
gnasher729

2

আপনি যে উদাহরণটি দিয়েছিলেন তা আমি সম্বোধন করতে চেয়েছিলাম:

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

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

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

আমি আপনার মতামত একই বৈশিষ্ট্য আছে সন্দেহ। আমার ক্ষেত্রে, আমি জানি এটি সমস্যার কারণ এবং আমি পরিবর্তন করার জন্য কাজ করছি। যদি আপনি সম্মত না হন যে এটি সমস্যার সৃষ্টি করে, তবে আপনার এটি ঠিক করার দরকার নেই।


2

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

function nextSlide() {
  var content = getNextSlideContent();
  hideCurrentSlide();
  var newSlide = createSlide(content);
  setNextSlide(newSlide);
  showNextSlide();
}

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

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

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

   if (hasMoreRecords()) { ... }

এর চেয়ে অবশ্যই বেশি পঠনযোগ্য

if (file.isOpen() && i < recordLimit && currentRecord != null) { ... } 

রাইট?

আমি নিখুঁত বিবৃতিগুলি খারাপ সম্পর্কে সম্মত এবং এও সম্মত যে সাধারণত একটি দীর্ঘ পদ্ধতি খারাপ।


1

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

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


0

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

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


কোড কমাতে সাহায্য কি ?
অব্নার শাহর-কাশতান

@ আভেনারশাহার-কাশতান, সম্ভবত তার অর্থ হ'ল "সদৃশ" :-)
পিটার তারেক

0

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

আমি বলতে চাইছি যে আপনার নমুনাটি রিফ্যাক্টর করার আসল কাজটি এর থেকে:

varaible_1 = 0
variable_2 = 0
for object in queryset :
     if object.condition_condition_a and variable_2 > 0 :
     variable 1+= 1
     .....
     ...    
     . 
      more conditions to alter the variables

return queryset, and context 

প্রতি

Status status = new Status();
status.variable1 = 0;
status.variable2 = 0;
for object in queryset :
     if object.condition_condition_a and status.variable2 > 0 :
     status.variable1 += 1
     .....
     ...    
     . 
      more conditions to alter the variables (status)

return queryset, and context 

এবং তারপর

class Status {
    variable1 = 0;
    variable2 = 0;

    void update(object) {
        if object.condition_condition_a and variable2 > 0 {
            variable1 += 1
        }
    }
};

Status status = new Status();
for object in queryset :
     status.update(object);
     .....
     ...    
     . 
      more conditions to alter the variables (status)

return queryset, and context 

আপনি এখন কেবল একটি খুব ছোট পদ্ধতি না হয়ে আরও অনেক বেশি ব্যবহারযোগ্য এবং বোধগম্য হওয়ার পথে on


0

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

foreach(var x in y)
{
    //do ALL the things
    //....
}

এবং লুপটির মূল অংশটি খুব স্থানীয়ভাবে তৈরি হয় না (যেমন, আপনি এটি 4 টি পরামিতির চেয়ে কম পাঠাতে পারেন), তবে সম্ভবত এটিতে রূপান্তর করা ভাল:

foreach(var x in y)
{
    DoAllTheThings(x);
}
...
void DoAllTheThings(object x)
{
    //do ALL the things
    //....
}

ঘুরেফিরে, এটি কোনও ফাংশনের দৈর্ঘ্যকে হ্রাস করতে পারে। এছাড়াও, ফাংশনে নকল কোডটি সন্ধান করার বিষয়টি নিশ্চিত করুন এবং এটিকে একটি পৃথক ফাংশনে স্থানান্তরিত করুন

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


0

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

দ্বিতীয়ত, যখন এটি ফাংশন / পদ্ধতিতে আসে:

void setDataValueAndCheckForRange(Data *data) {/*code*/} 

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

void setDataValueAndCheckForRange(Data *data){ /*code */}
void addDataValuesAndCheckForRange(Data *result, Data *d1, Data *d2){ /*code*/}
void subDataValuesAndCheckForRange(Data *result, Data *d1, Data *d2){ /*code*/}
void mulDataValuesAndCheckForRange(Data *result, Data *d1, Data *d2){ /*code*/}

এটিতে রিফ্যাক্টর করতে হবে:

bool isWithinRange(Data *d){ /*code*/ }
void setDataValue(Data *d) {/*code*/ if(isWithinRange(d)){/*continue*/}else{/*warn/abort*/} 
void addDataValue(Data *d, Data *d1, Data *d2) {/*code*/ if(isWithinRange(d)){/*continue*/}else{/*warn/abort*/} 
void subDataValue(Data *d, Data *d1, Data *d2) {/*code*/ if(isWithinRange(d)){/*continue*/}else{/*warn/abort*/} 
void mulDataValue(Data *d, Data *d1, Data *d2) {/*code*/ if(isWithinRange(d)){/*continue*/}else{/*warn/abort*/} 

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

মূল্য: মাউন্টেন পৃথিবীর ক্ষুদ্র দানা দিয়ে তৈরি। জলের ছোট ছোট ফোঁটা দিয়ে সমুদ্র গঠিত ... (- শিবানন্দ)


0

দীর্ঘ পদ্ধতিগুলি অপরিহার্য ভাষাগুলিতে "খারাপ" দিকে ঝুঁকছে যা বিবৃতি, পার্শ্ব-প্রতিক্রিয়া এবং মিউটেবিলিটির পক্ষে থাকে, কারণ এই বৈশিষ্ট্যগুলি জটিলতা বৃদ্ধি করে এবং এর ফলে বাগগুলি বৃদ্ধি পায়।

ক্রিয়ামূলক প্রোগ্রামিং ভাষাগুলিতে, যা প্রকাশ, বিশুদ্ধতা এবং অপরিবর্তনীয়তার পক্ষে, উদ্বেগের কম কারণ নেই।

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


কার্যকরী ভাষায়, যদিও দীর্ঘ পদ্ধতিগুলি খুব কম ব্যবহৃত হয়।
ব্রুস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.