যখন একটি ফাংশন খুব দীর্ঘ হয়? [বন্ধ]

130

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

7 বছর আগে বন্ধ ছিল ।

35 লাইন, 55 লাইন, 100 লাইন, 300 লাইন? আপনি এটি ভেঙে শুরু করা উচিত? আমি জিজ্ঞাসা করছি কারণ আমার 60০ টি লাইন (মন্তব্য সহ) সহ একটি ফাংশন রয়েছে এবং এটি বিচ্ছিন্ন করার বিষয়ে ভাবছিলাম।

long_function(){ ... }

মধ্যে:

small_function_1(){...}
small_function_2(){...}
small_function_3(){...}

ফাংশনগুলি দীর্ঘক্ষণের বাইরে ব্যবহার করা যাচ্ছে না, ছোট ফাংশন করা মানে আরও বেশি ফাংশন কল ইত্যাদি function

আপনি কখন ছোট কোনও ফাংশনকে আলাদা করবেন? কেন?

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

উত্তরের জন্য সবাইকে ধন্যবাদ , তালিকাটি সম্পাদনা করুন এবং সঠিক উত্তরের জন্য ভোট দিন আমি এটিটি বেছে নেব;)

আমি এই ধারণাগুলি মাথায় রেখে এখনই রিফ্যাক্টর করছি :)

function refactoring coding-style

— রিভস , 2 জন ব্যবহারকারী 100% ব্যবহারকারী 588163
সূত্র

আপনার প্রশ্নে একটি টাইপ রয়েছে, আমার মনে হয় আপনি "কখন একটি ফাংশন খুব দীর্ঘ হয়?" বলে বোঝাতে চেয়েছিলেন।

— টম

1

আপনি কোডের লাইনের শর্তাবলী পোস্ট করে প্রশ্নটির ভুল ব্যবহার করছেন। নির্ধারক কারণগুলি কোডের লাইনে পরিমাপ করা হয় না।

— dkretz

এই প্রশ্নটি কোড এবং ভাষার উপর নির্ভর করে জটিল হয়ে উঠতে পারে। সম্ভবত আপনি এটি পোস্ট করতে পারেন।

— রায় তায়েক

যদি এটি একক দায়িত্বের নীতি মেনে চলে - তবে এটি করুন। আমি সাধারণত একটি শিরোনাম তৈরি করার বা প্রতি 20 লাইনের কোডের প্রয়োজন বোধ করি যা এটিকে বিমূর্ত করে তুলে এই অধ্যায়টির শিরোনাম না করে এই অংশটিকে একটি অর্থবহ নাম দিয়ে একটি ফাংশনটির নাম দেয়।

— ইয়াভেগেনি আফানসিয়েভ

আপনার জন্য একটি পদ্ধতির আদর্শ দৈর্ঘ্য কত?

— ফুক্লভ

75

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

এটি "কিছু করা" এখনও বেশ কয়েকটি লাইন হতে পারে, সুতরাং আমি নিশ্চিত নই যে বেশিরভাগ লাইনই ব্যবহার করার জন্য সঠিক মেট্রিক হবে :)

সম্পাদনা: এটি গত এক সপ্তাহে কাজের আশেপাশে আমি প্রেরিত কোডের একক লাইন (কোনও বিষয় প্রমাণ করার জন্য .. এটি আমার অভ্যাস করার বিষয় নয় :)) - আমি অবশ্যই আমার পদ্ধতিতে এই খারাপ ছেলেদের 50-60 চাই না : ডি

return level4 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3) && (r.Level4 == (int)level4)).ToList() : level3 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3)).ToList() : level2 != null ? GetResources().Where(r => (r.Level2 == (int)level2)).ToList() : GetAllResourceList();

— স্টিভেন রবিনস
সূত্র

1

LOL আচ্ছা আমি আমার পদ্ধতির সমস্ত সাদা স্থান সরিয়ে ফেলতে পারতাম এবং এটি কেবল একটি দীর্ঘ লাইন হবে এবং দীর্ঘ ফাংশন নয়। একটি কাজ করা, সম্ভবত

@ মোভ্যাক্স যে কোড স্নিপেটটি আমি পোস্ট করেছি তা একটি একক বিবৃতি, যদিও কেবল একটি লাইনে প্রচুর লাইনই নেই .. সেখানে কোনও আধা-কলোন নেই :) আমি আরও প্রতিশ্রুতিবদ্ধ হওয়ার জন্য প্রতিবার গেটআরসোর্সগুলি () প্রসারিত করতে পারতাম: পি

— স্টিভেন রবিনস

হ্যাঁ তা বোধগম্য হয়। কেন কেবল আপনার পুরো উত্স ফাইলটি এনে এক লাইনে রাখবেন না। আমি বলতে চাইছি আপনি সত্যিই একটি ওয়েব 2.0 "নিনজা" হতে পারেন :)

— ববিশ্যাফটো

আমার মনে আছে পুরানো ম্যাগাজিনগুলিতে (আমি বিবিসি মাইক্রো পুরানো কথা বলছি) তাদের "10 লাইনের প্রোগ্রাম" থাকত যেগুলি প্রতিটি লাইনে সবিস্তারে বেশ কয়েকটি বিবৃতি দেয়, বিবিসি যে সর্বোচ্চ দৈর্ঘ্য পরিচালনা করতে পারে তা অবধি .. তারা সর্বদা একটি সঠিক ব্যথা ছিল টাইপ করতে: ডি

— স্টিভেন রব্বিনস

6

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

— এমটিএনপল

214

এখানে লাল-পতাকাগুলির একটি তালিকা রয়েছে (কোনও নির্দিষ্ট ক্রমে নয়) যেটি বোঝাতে পারে যে কোনও ফাংশন খুব দীর্ঘ:

গভীরভাবে নেস্টেড কন্ট্রোল স্ট্রাকচার : যেমন-লুপগুলি 3 স্তরের গভীর বা এমনকি মাত্র 2 স্তর নীচে নেস্টেড ইফ-স্টেটমেন্টগুলির সাথে জটিল শর্ত রয়েছে with
অনেকগুলি রাষ্ট্র-সংজ্ঞায়িত পরামিতি : রাষ্ট্র-সংজ্ঞায়িত পরামিতি দ্বারা , আমি একটি ফাংশন প্যারামিটার বলতে বুঝি যা ফাংশনটির মাধ্যমে কোনও নির্দিষ্ট মৃত্যুদন্ডের গ্যারান্টি দেয়। এই ধরণের পরামিতিগুলির অনেকগুলি পান এবং আপনার কার্যকর করার পথে একটি বিস্ফোরণ ঘটে (এটি সাধারণত # 1 এর সাথে ঘটে)।
যুক্তি যা অন্যান্য পদ্ধতিতে সদৃশ হয় : দুর্বল কোডটি পুনরায় ব্যবহার করা একতরফা পদ্ধতিগত কোডে একটি বিশাল অবদানকারী। এ জাতীয় প্রচুর যুক্তিযুক্ত অনুলিপি খুব সূক্ষ্ম হতে পারে, তবে একবার পুনঃ-কৌণিক প্রমাণিত হলে শেষ ফলাফলটি আরও বেশি মার্জিত ডিজাইন হতে পারে।
অতিরিক্ত আন্তঃ-শ্রেণীর মিলন : সঠিক এনক্যাপসুলেশনের এই অভাবের ফলে ফাংশনগুলি অন্যান্য শ্রেণীর অন্তরঙ্গ বৈশিষ্ট্যগুলির সাথে সম্পর্কিত, ফলে এগুলি আরও দীর্ঘায়িত করে।
অপ্রয়োজনীয় ওভারহেড : মন্তব্যগুলি যা প্রাইভেট নেস্টেড ক্লাস ভেরিয়েবলের জন্য সুস্পষ্ট, গভীরভাবে নেস্টেড ক্লাসগুলি, অতিশয় জল প্রাপ্ত এবং সেটটারগুলি নির্দেশ করে এবং অস্বাভাবিকভাবে দীর্ঘ ফাংশন / ভেরিয়েবল নামগুলি সমস্ত সম্পর্কিত ফাংশনগুলির মধ্যে সিনট্যাক্টিক গোলমাল তৈরি করতে পারে যা শেষ পর্যন্ত তাদের দৈর্ঘ্য বাড়িয়ে তুলবে।
আপনার বিশাল বিকাশকারী-গ্রেড প্রদর্শনটি এটি প্রদর্শন করার পক্ষে যথেষ্ট বড় নয় : আসলে, আজকের ডিসপ্লেগুলি এতটাই বড় যে তার উচ্চতার কাছাকাছি যে কোনও কাজ সম্ভবত খুব দীর্ঘ way তবে, এটি বড় হলে এটি একটি ধূমপান বন্দুক যা কিছু ভুল।
আপনি অবিলম্বে ফাংশনের উদ্দেশ্য নির্ধারণ করতে পারবে না : উপরন্তু, আপনি একবার আসলে কি তার উদ্দেশ্য নির্ধারণ, যদি আপনি একটি একক বাক্যে এই উদ্দেশ্যে সংক্ষেপ করতে পারবেন না বা একটি অসাধারণ মাথা ব্যাথা আছে এরকম, এই একটি সুরুক হওয়া উচিত।

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

— রায়ান দেলুচি
সূত্র

1

চমৎকার পোস্ট! খুব নির্বিচারবাদী

— চক কনওয়ে

2

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

— রায়ান ডেলুচি

2

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

— পেড্রো রোলো

3

@ পেড্রোমোর্টেলোলো আমি অবশ্যই এই বিষয়ে একমত তদুপরি, বৃহত্তর শ্রেণিতে আরও বেশি পরিবর্তনীয়-রাষ্ট্র হওয়ার সম্ভাবনা রয়েছে: যা এমন কোডের দিকে নিয়ে যায় যা বজায় রাখা খুব কঠিন।

— রায়ান দেলুচি

1

সর্বোত্তম উত্তর. আর একটি ভাল ক্লু হ'ল: কোডের মতামতগুলি দেখতে কেমন? কারোর কোডটি পেরিয়ে যাওয়ার মতো লাইনের সাথে আমি কতবার হোঁচট খেয়েছি // fetch Foo's credentials where Bar is "uncomplete"। এটি প্রায় অবশ্যই সেখানে একটি ফাংশন নাম এবং decoupled করা উচিত। সম্ভবত এরকম কিছুতে রিফ্যাক্টর হতে চায়: Foo.fetchCredentialWhereBarUncomplete()

— জে এডওয়ার্ডস

28

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

— jmucchiello
সূত্র

18

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

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

— জেরেমি রুটেন
সূত্র

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

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

— void.pointer

16

আমি সম্মত একটি ফাংশন শুধুমাত্র একটি কাজ করা উচিত, কিন্তু কোন স্তরের এক জিনিস এটি।

যদি আপনার 60 লাইনগুলি কোনও জিনিস সম্পাদন করে (আপনার প্রোগ্রামের দৃষ্টিকোণ থেকে) এবং সেই 60 টি লাইন তৈরি করে দেওয়া টুকরা অন্য কোনও কিছুই ব্যবহার না করে তবে 60 লাইন ঠিক আছে।

এটিকে ভেঙে ফেলার কোনও সত্যিকারের সুবিধা নেই, যদি না আপনি এটিকে নিজেরাই দাঁড়িয়ে থাকা কংক্রিটের টুকরো টুকরো টুকরো করে ফেলতে পারেন। ব্যবহারের জন্য মেট্রিকটি কার্যকারিতা এবং কোডের লাইন নয়।

আমি অনেকগুলি প্রোগ্রামে কাজ করেছি যেখানে লেখকরা কেবলমাত্র একটি জিনিসকে চরম স্তরে নিয়ে গিয়েছিলেন এবং এটির কাজটি শেষ হয়েছিল এটি হ'ল কোনও ফাংশন / পদ্ধতিতে কোনও গ্রেনেড নিয়ে গিয়েছিল এবং এটি কয়েক ডজন সংযুক্ত সংযোগে টুকরো টুকরো করে ফেলেছে যা কঠিন অনুসরণ করতে.

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

আমি বিশ্বাস করি যে মূল বিষয়টি হ'ল দীর্ঘ ক্রিয়ায় পুনঃব্যবহারযোগ্যতা সন্ধান করা এবং সেই অংশগুলি বাইরে টান। আপনি যা যা রেখে গেছেন তা হ'ল 10, 20 বা 60 লাইন দীর্ঘ।

— bruceatk
সূত্র

2

+1 "ব্যবহারের জন্য মেট্রিকটি কার্যকারিতা এবং কোডের লাইন নয়"

— কোডি পিয়ার্সাল

আর একটি গুরুত্বপূর্ণ মেট্রিক হ'ল ব্লক নেস্টিংয়ের স্তরের সংখ্যা। সর্বনিম্ন রাখুন। ছোট অংশে কোনও ক্রিয়াকলাপ ভাঙা প্রায়শই সহায়তা করে। অন্যান্য জিনিসগুলিও সহায়তা করতে পারে যেমন একাধিক রিটার্ন।

— ব্যবহারকারী 2367418

10

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

আমি কেন একটি ফাংশন ব্রেকআপ করতে পারি:

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

— রেভস , 2 জন ব্যবহারকারী 94% ডাজোরড
সূত্র

3

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

2

আপনি এই সাথীর সাথে কেবল অর্ডার অফ আউট। 60 লাইন সর্বদা খুব বেশি হবে। আমি বলব যে আপনি যদি 10 লাইনে বন্ধ করে থাকেন তবে আপনি সম্ভবত সীমাটির খুব কাছাকাছি রয়েছেন।

— উইলকোডেজাভফুফুড

তবে অন্য একটি ফাংশন এখনও এই ফাংশনগুলিকে কল করছে এবং মূলত একই DoThisAndThisAndAlsoThisফাংশন তবে আপনাকে প্রচুর বিমূর্ততার সাথে এখনও নামকরণ করতে হবে

— টিমো হুভিনেন

6

আমার ব্যক্তিগত তাত্পর্যপূর্ণতাটি হ'ল এটি যদি খুব দীর্ঘ হয় তবে আমি যদি স্ক্রলিং ব্যতীত পুরো জিনিসটি দেখতে না পাই।

— Ferruccio
সূত্র

4

... ফন্টের আকার 5 এ সেট করার সময়?

— এরিকশাফার

5

আপনার পর্দার আকারের আকার প্রায় (তাই একটি বড় পিভট ওয়াইডস্ক্রিন পান এবং এটি ঘুরুন) ... :-)

কৌতুক একদিকে, ফাংশন প্রতি একটি যৌক্তিক জিনিস।

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

/ জোহান

— জোহান
সূত্র

ইউনিট পরীক্ষার বিষয়ে ভালো কথা :)

5

থাম্বের বিধি: যদি কোনও ফাংশনটিতে এমন কিছু কোড ব্লক থাকে যা কিছু করে, যা কিছুটা কোডের কিছু অংশ থেকে আলাদা হয়, এটি আলাদা আলাদা ফাংশনে রাখুন। উদাহরণ:

function build_address_list_for_zip($zip) {

    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

অধিক সুন্দর:

function fetch_addresses_for_zip($zip) {
    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }
    return $addresses;
}

function build_address_list_for_zip($zip) {

    $addresses = fetch_addresses_for_zip($zip);

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

এই পদ্ধতির দুটি সুবিধা রয়েছে:

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

[অন্যদিকে (আমি অস্বীকার করব আমি এটিকে আপনাকে এমনকি নির্যাতনের মধ্যেও বলেছিলাম): আপনি যদি পিএইচপি অপ্টিমাইজেশান সম্পর্কে অনেক কিছু পড়েন তবে ফাংশন সংখ্যাটি যতটা সম্ভব ছোট রাখার ধারণা আপনি পেতে পারেন, কারণ ফাংশন কলটি খুব, পিএইচপি খুব ব্যয়বহুল। আমি কখনই কোনও বেঞ্চমার্ক করি নি সে সম্পর্কে আমি জানি না did যদি আপনি আবেদনটি খুব "পারফরম্যান্স সংবেদনশীল" হন তবে আপনি সম্ভবত আপনার প্রশ্নের উত্তর অনুসরণ না করাই ভাল; ;)]

— EricSchaefer
সূত্র

ধন্যবাদ সুন্দর উদাহরণ :) আমি পিএইচপি তে ফাংশন মানদণ্ডের জন্য গুগল করব

5

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

এখন ভাবুন আপনার কোডটির কোনও কার্য / পদ্ধতি নেই; এটি গ্রাফ আকারে কোডের এক মাত্র বিশাল স্প্রোল।

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

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

এই উত্তরটি একটি সমীকরণ দ্বারা দেওয়া হয়েছে। R যদি সিস্টেমের এমপিই হ্রাস করে এমন পদ্ধতির সংখ্যা হয় এবং এন সিস্টেমে ব্লকের সংখ্যা হয় তবে সমীকরণটি হ'ল: r = sqrt (n)

এবং এটি দেখানো যেতে পারে যে এটি পদ্ধতি অনুসারে ব্লকগুলির সংখ্যা দেয়, এছাড়াও, sqrt (n)।

— এড কিরওয়ান
সূত্র

4

মনে রাখবেন যে আপনি পুনরায় ফ্যাক্টরিংয়ের প্রয়োজনে পুনঃ-ফ্যাক্টরিং শেষ করতে পারেন, কোডটি সম্ভবত প্রথম স্থানের চেয়ে আরও অঠনীয় করে তুলবে।

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

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

— রেভ সল্টমিস্টার
সূত্র

2

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

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

আপনি কি নিশ্চিত যে সেখানে কোনও টুকরা নেই যা অন্য কোথাও কার্যকর হবে? এটি কোন ধরণের কাজ?

— জেফ্রি হ্যান্টিন
সূত্র

ফাংশনটি url / post / 2009/01/01 থেকে url / post / 2009/01/01 এর পোস্ট পোস্টের মত পোস্টের উপর ভিত্তি করে url এর উপর ভিত্তি করে একটি টেম্পলেট থেকে একটি ক্যাশে ফাইল তৈরি করে

2

আমার মতে উত্তরটি হ'ল: যখন এটি খুব বেশি কাজ করে। আপনার ফাংশনটি কেবল ফাংশনটির নাম থেকেই আপনি যে ক্রিয়াটি প্রত্যাশা করছেন তা করা উচিত perform আরেকটি বিষয় বিবেচনা করার বিষয় হ'ল আপনি যদি নিজের কার্যাবলীর কিছু অংশ অন্যদের মধ্যে পুনরায় ব্যবহার করতে চান; এই ক্ষেত্রে এটি বিভক্ত করতে দরকারী হতে পারে।

— Pierpaolo
সূত্র

2

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

— ওলাফ কক
সূত্র

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

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

— ওলাফ কক

আমি কেবল এই উত্তরটি পেরিয়ে এসেছি: stackoverflow.com/questions/406760/… উল্লেখ করে যে "কোডের বেশিরভাগ মন্তব্য আসলে কোড নকলের একটি ক্ষতিকারক রূপ"। এছাড়াও - মন্তব্য দীর্ঘ লাইন।

— ওলাফ কক

1

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

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

আমি জানি না যে এর কোনও সঠিক বা ভুল উত্তর আছে (উদাহরণস্বরূপ, আপনি আপনার সর্বাধিক হিসাবে 67 লাইনে স্থির থাকতে পারেন, তবে এমন সময় আসতে পারে যখন আরও কিছু যুক্ত করার বোধ হয়)।

— অ্যান্ড্রু হেজেস
সূত্র

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

1

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

আমি একমত নই যে কোনও পদ্ধতিতে আপনার ডিসপ্লেতে একটিতে ফিট করা উচিত তবে আপনি যদি কোনও পৃষ্ঠার চেয়ে বেশি স্ক্রোল করে নিচ্ছেন তবে পদ্ধতিটি দীর্ঘ।

আরও আলোচনার জন্য অবজেক্ট-ওরিয়েন্টেড সফ্টওয়্যারটির অনুকূল শ্রেণীর আকার দেখুন ।

— আয়ান হিকম্যান
সূত্র

লিঙ্কটি পড়ার জন্য ধন্যবাদ, :)

1

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

সংক্ষেপে, যদিও ফাংশনটি 500 লাইন ছিল, স্বতন্ত্রভাবে পরিচালিত অঞ্চলগুলি গড় 5 লাইন।

— জশুয়া
সূত্র

1

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

যদি আপনার পরীক্ষাটি পর্যাপ্তভাবে নিবদ্ধ থাকে তবে পরীক্ষার পাস করার জন্য এটি আপনাকে একটি ছোট ফোকাস ফাংশন লিখতে পরিচালিত করবে।

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

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

— lexicalscope
সূত্র

1

যদি এর তিনটির বেশি শাখা থাকে, তবে এর অর্থ সাধারণত কোনও কার্য বা পদ্ধতি পৃথক পৃথক পৃথক পদ্ধতিতে শাখা যুক্তি যুক্ত করতে হবে।

লুপের জন্য প্রতিটি, যদি বিবৃতি ইত্যাদি থাকে তবে কলিং পদ্ধতিতে একটি শাখা হিসাবে দেখা যায় না।

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

যদি কোনও ফাংশন / পদ্ধতিতে কেবল তিনটি শাখা থাকে তবে এটি সেই মেট্রিকটিতে একটি তিনটি পাবে যা খুব ভাল।

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

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

— মার্টিন54
সূত্র

0

আমি সন্দেহ করি আপনি এটিতে প্রচুর উত্তর পাবেন।

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

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

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

— Phil.Wheeler
সূত্র

0

অভিমানী যে আপনি করছেন এক জিনিস, দৈর্ঘ্যের উপর নির্ভর করবে:

তুমি কি করছ
আপনি কোন ভাষা ব্যবহার করছেন
কোডটিতে আপনাকে কত স্তরের বিমূর্ততা মোকাবেলা করতে হবে

60 লাইন খুব দীর্ঘ হতে পারে বা এটি ঠিক ঠিক হতে পারে। আমি সন্দেহ করি যদিও এটি অনেক দীর্ঘ হতে পারে।

— রে রে
সূত্র

আমি পিএইচপি-তে কিছু ক্যাচিং করছি, হ্যাঁ সম্ভবত 60 টি লাইন খুব বেশি, রিফ্যাক্টরিং ...

0

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

— gkrogers
সূত্র

0

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

— মার্ক বোস্টলম্যান
সূত্র

0

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

— sokket
সূত্র