দীর্ঘ ফাংশনের পক্ষে কমপক্ষে দুটি যুক্তি সম্পর্কে আমি ভাবতে পারি:
এর অর্থ প্রতিটি লাইনের চারপাশে আপনার প্রচুর প্রসঙ্গ রয়েছে। এটি আনুষ্ঠানিক করার একটি উপায়: আপনার কোডের নিয়ন্ত্রণ প্রবাহ গ্রাফটি আঁকুন। ফাংশন এন্ট্রি এবং ফাংশন প্রস্থানের মধ্যে একটি শীর্ষস্থান (~ = লাইন) এ, আপনি আগত সমস্ত প্রান্ত জানেন । ফাংশনটি দীর্ঘতর, আরও আরও অনেকগুলি উল্লম্ব রয়েছে।
অনেক ছোট ফাংশন মানে একটি বৃহত্তর এবং আরও জটিল কল গ্রাফ। একটি এলোমেলো ফাংশনে একটি এলোমেলো রেখাটি চয়ন করুন এবং "এই রেখাটি কোন প্রসঙ্গে (গুলি) কার্যকর করা হয়?" প্রশ্নের উত্তর দিন? এটি কল গ্রাফের চেয়ে বৃহত্তর এবং জটিলতর হয়ে ওঠে, কারণ আপনাকে সেই গ্রাফের আরও শীর্ষে দেখতে হবে।
দীর্ঘ ক্রিয়াকলাপের বিরুদ্ধে যুক্তিগুলিও রয়েছে — ইউনিট-টেস্টিবিলিটি মনে মনে ings একে অপরের মধ্যে বেছে নেওয়ার সময় আপনার অভিজ্ঞতা ব্যবহার করুন।
দ্রষ্টব্য: আমি বলছি না যে আপনার বস সঠিক, কেবল তার দৃষ্টিভঙ্গিটি পুরোপুরি মূল্য থেকে বঞ্চিত না হতে পারে।
আমার ধারণা আমার মতামতটি হ'ল ভাল অপটিমাইজেশন প্যারামিটারটি ফাংশনের দৈর্ঘ্য নয়। আমি মনে করি যে একটি দেশীয়রতা বিবেচনার জন্য আরও কার্যকর the নিম্নলিখিতটি সমস্ত কিছু সমান হ'ল, ব্যবসায়ের যুক্তি এবং বাস্তবায়ন উভয়েরই একটি উচ্চ-স্তরের বিবরণ কোডের বাইরে পড়তে পারা ভাল to (আপনি যদি কোডের প্রাসঙ্গিক বিটটি খুঁজে পান তবে সর্বদা নিম্ন-স্তরের বাস্তবায়ন বিশদটি পড়া যায়))
ডেভিড আরনোর উত্তর সম্পর্কে মন্তব্য :
ছোট ফাংশনগুলি লেখা একটি ব্যথা কারণ এটি কোডটি কী করছে তা দেখার জন্য আপনাকে প্রতিটি ছোট ফাংশনে যেতে বাধ্য করে।
যদি ফাংশনটি সুনামযুক্ত হয় তবে এটি কেস নয়। # অ্যাপ্লিকেশনআইএনপ্রডাকশনটি স্বতঃসিদ্ধ এবং কোডটি কী করে তা দেখার জন্য এটি পরীক্ষা করার প্রয়োজন হবে না। বাস্তবে বিপরীতটি সত্য: কোডটি পরীক্ষা করে ফাংশন নামটির চেয়ে অভিপ্রায়টি কম প্রকাশ পায় (যে কারণে আপনার বসকে মন্তব্যে অবলম্বন করতে হবে)।
নামটি প্রত্যাবর্তনের মানটির অর্থ কী তা স্পষ্ট করে তোলে তবে কোডটি কার্যকর করার প্রভাব সম্পর্কে (= কোড কী করে ) তা কিছুই বলে না । নামগুলি (কেবলমাত্র) উদ্দেশ্য সম্পর্কে তথ্য সরবরাহ করে , কোড আচরণ সম্পর্কে তথ্য সরবরাহ করে (যার মাধ্যমে উদ্দেশ্যটির অংশগুলি কখনও কখনও অনুমান করা যায়)।
কখনও কখনও আপনি একটি চান, কখনও কখনও অন্য চান, সুতরাং এই পর্যবেক্ষণটি একতরফা সর্বজনীন বৈধ সিদ্ধান্তের নিয়ম তৈরি করে না।
মূল লুপটি 300 লাইন বেশি হলেও, এটি পড়তে তত দ্রুত হয় তবে একটি বড় বড় লুপে সবকিছু রাখুন
এটির মাধ্যমে স্ক্যান করা দ্রুততর হতে পারে তবে কোডটি সত্যই "পড়ার" জন্য আপনাকে এটিকে আপনার মাথায় কার্যকরভাবে কার্যকর করতে সক্ষম হতে হবে। এটি ছোট ফাংশনগুলির সাথে সহজ এবং সত্যই, 100 মাইল লম্বা পদ্ধতিগুলির সাথে সত্যই শক্ত।
আমি সম্মত হই যে আপনি এটি আপনার মাথায় চালিত করতে হবে। অনেক ছোট ফাংশনে বনাম একটি বড় ফাংশনে আপনার যদি 500 লাইনের কার্যকারিতা থাকে তবে এটি কেন সহজ হয় তা আমার কাছে স্পষ্ট নয়।
ধরুন, সরল-রেখার উচ্চতর পার্শ্ব-প্রভাবকারী কোডের 500 টি লাইনের চূড়ান্ত ক্ষেত্রে, এবং আপনি যদি জানতে চান যে প্রভাব এ এর আগে বা পরে ঘটে থাকে তবে বড় ফাংশনের ক্ষেত্রে, দুটি লাইন সন্ধান করতে পৃষ্ঠা আপ / ডাউন ব্যবহার করুন এবং তারপরে তুলনা করুন লাইন সংখ্যা বহু-ছোট-কার্যকারী ক্ষেত্রে, আপনাকে অবশ্যই মনে রাখতে হবে কল ট্রিতে এর প্রভাবগুলি কোথায় ঘটে। এবং যদি আপনি ভুলে যান তবে আপনাকে এই গাছের কাঠামোটি পুনরায় আবিষ্কার করতে একটি অপ্রয়োজনীয় সময় ব্যয় করতে হবে।
সহায়ক ফাংশনগুলির কল ট্রিকে অনুসরণ করার সময়, আপনি কখন ব্যবসায় যুক্তি থেকে বাস্তবায়নের বিশদে চলে গিয়েছেন তা নির্ধারণের চ্যালেঞ্জের মুখোমুখি হন। আমি প্রমাণ ছাড়াই দাবি করি * কল গ্রাফটি যত সহজ, এই পার্থক্যটি করা আরও সহজ।
(*) কমপক্ষে আমি এ সম্পর্কে সত্যবাদী ;-)
আবারও, আমি মনে করি উভয় পদ্ধতির শক্তি এবং দুর্বলতা রয়েছে।
আপনার যদি কোডটির সদৃশ করতে হয় তবে কেবলমাত্র ছোট ফাংশন লিখুন
আমি একমত নই যেমন আপনার কোড উদাহরণটি দেখায়, ছোট, সুনামযুক্ত ফাংশনগুলি কোডের পঠনযোগ্যতা উন্নত করে এবং যখনই ব্যবহার করা উচিত [উদাহরণস্বরূপ] আপনি "কীভাবে", কোনও কার্যকারিতার কেবল "কী" তে আগ্রহী নন।
আপনি কীভাবে "কী" বা "কী" আগ্রহী সে উদ্দেশ্যটির একটি ক্রিয়া যা আপনি কোডটি পড়ছেন (উদাঃ একটি সাধারণ ধারণা বনাম কোনও বাগ সন্ধান করা)। প্রোগ্রামটি লেখার সময় আপনি যে উদ্দেশ্যে কোডটি পড়ছেন তা উপলভ্য নয় এবং আপনি সম্ভবত বিভিন্ন উদ্দেশ্যে কোডটি পড়বেন; বিভিন্ন সিদ্ধান্ত বিভিন্ন উদ্দেশ্যে অনুকূলিত করা হবে।
এটি বলেছিল, এটি সম্ভবত বসের দৃষ্টিভঙ্গির অংশ আমি সম্ভবত সবচেয়ে বেশি একমত নই।
মন্তব্যের নাম সহ কোনও ফাংশন লিখবেন না, উপরে একটি মন্তব্য সহ আপনার জটিল রেখার কোড (3-4 রেখা) রাখুন। এটির মতো আপনি ব্যর্থ কোডটি সরাসরি সংশোধন করতে পারেন
আমি সত্যই এটি গুরুতর বলে ধরে নিয়ে এর পিছনে যুক্তিটি বুঝতে পারি না। [...] মন্তব্যে একটি মৌলিক ত্রুটি রয়েছে: সেগুলি সংকলিত / ব্যাখ্যা করা হয় না এবং তাই ইউনিট পরীক্ষা করা যায় না। কোডটি সংশোধিত হয়ে যায় এবং মন্তব্যটি একা হয়ে যায় এবং কোনটি সঠিক তা আপনি জানেন না।
সংকলকগণ কেবলমাত্র সমতার জন্য নামগুলির তুলনা করেন, তারা আপনাকে কোনও বিভ্রান্তিমূলক নাম দেয় না। এছাড়াও, কারণ বেশ কয়েকটি কল সাইট নাম দিয়ে কোনও প্রদত্ত ফাংশন ডেকে আনতে পারে, কখনও কখনও নাম পরিবর্তন করা আরও কঠিন এবং ত্রুটি-প্রবণ হয়। মন্তব্যগুলিতে এই সমস্যা নেই। তবে এটি কিছুটা অনুমানমূলক; সত্যিই এটি নিষ্পত্তি করার জন্য, প্রোগ্রামারদের বিভ্রান্তিমূলক মন্তব্য বনাম বিভ্রান্তিমূলক নামগুলি আপডেট করার সম্ভাবনা বেশি কিনা সে সম্পর্কে আমাদের সম্ভবত একটি ডেটা দরকার হবে এবং আমার কাছে তা নেই।