দীর্ঘ অভ্যন্তরীণ কাঠামো যদি তাদের অভ্যন্তরীণ কাঠামো গ্রহণযোগ্য হয়?

23

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

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

— dsimcha
সূত্র

5

আমি নিয়মিত 400+ লাইন ফাংশন / পদ্ধতি লিখি। গ্যাটা সেই 500 কেস সুইচ স্টেটমেন্টটি কোথাও রেখে দিয়েছে :)

— কলম রজার্স

7

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

— মিথ্যা রায়ান

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

— আদিত্য পি

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

— কাজ

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

— ক্রেগ গিডনি

21

সর্বদা নিয়মটি মনে রাখবেন, একটি ফাংশন একটি কাজ করে এবং তা ভাল করে! যদি আপনি এটি করতে পারেন তবে নেস্টেড ফাংশনগুলি এড়িয়ে চলুন।

এটি পাঠযোগ্যতা এবং পরীক্ষায় বাধা দেয়।

— ব্রায়ান হ্যারিংটন
সূত্র

9

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

— dsimcha

1

@ ডিডিমচা: কোন নিয়ম ভুলভাবে প্রয়োগ করা যায় না এবং সমস্যার কারণ হতে পারে? যখন কেউ "নিয়ম" / প্লিটটিউডস প্রয়োগ করছেন যেখানে তারা দরকারী যেখানে পয়েন্ট করছেন, কেবল অন্যটি বের করুন: সমস্ত সাধারণীকরণ মিথ্যা false

2

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

— dsimcha

2

"হ্যাঁ, বিধিটি ভুলভাবে প্রয়োগ করা হয়েছে, তবে নিয়মটি খুব বেশি প্রয়োগ করা হচ্ছে!" : পি

1

আমার ফাংশনটি একটি কাজ করে এবং এটি খুব ভালভাবে এটি করে: যথা, 27 স্ক্রিনফুল দখল করে। :)

— কাজ

12

কেউ কেউ যুক্তি দেখিয়েছেন যে সংক্ষিপ্ত ফাংশনগুলি দীর্ঘ ফাংশনের চেয়ে ত্রুটি-প্রবণতা হতে পারে ।

কার্ড এবং গ্লাস (1990) নির্দেশ করে যে নকশার জটিলতায় সত্যই দুটি দিক জড়িত: প্রতিটি উপাদানগুলির মধ্যে জটিলতা এবং উপাদানগুলির মধ্যে সম্পর্কের জটিলতা।

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

আমি মনে করি মূল অবকাশটি হ'ল আপনি যখন কোডের একটি ব্লক বিভক্ত করেন, তখন আপনি অন্যর জন্য এক ধরণের জটিলতার বাণিজ্য করছেন। মাঝখানে সম্ভবত একটি মিষ্টি স্পট আছে।

— জোনাথন ট্রান
সূত্র

আপনি কি "ক্লিন কোড" পড়েছেন? এটি দৈর্ঘ্যে এ নিয়ে আলোচনা করে। amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/…

— মার্টিন উইকম্যান

9

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

আমি জানি যে আমি পৃষ্ঠাটি উপরে / নিচে চাপ দেওয়ার সাথে সাথে কোডের একটি আলাদা বিভাগে চলে আসছি, আমি কেবল পূর্ববর্তী পৃষ্ঠা থেকে 7 +/- 2 জিনিস মনে করতে পারি। এবং দুর্ভাগ্যক্রমে, নতুন কোডটি পড়ার সময় সেগুলির কয়েকটি অবস্থান ব্যবহার করা হচ্ছে be

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

— jsternberg
সূত্র

3

আপনাকে কেবল এটি একটি ম্যাট্রিক্স প্রিন্টারে মুদ্রণ করতে হবে - দেখুন, একবারে 10 মিটার কোড :)

বা উচ্চতর রেজোলিউশন সহ একটি মনিটর পান

— frogstarr78

এবং এটি উল্লম্ব অভিযোজনে ব্যবহার করুন।

— কলমারিয়াস

4

সাধারণ বাহ্যিক ফাংশনের চেয়ে নেস্টেড ফাংশনগুলি কেন ব্যবহার করবেন?

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

DoThing(int x){
    x += ;1
    int y = FirstThing(x);
    x = SecondThing(x, y);
    while(spoo > fleem){
        x = ThirdThing(x+y);
    }
}

FirstThing(int x){...}
SecondThing(int x, int y){...}
ThirdThing(int z){...}

— Fishtoaster
সূত্র

2

দুটি সম্ভাব্য কারণ: নেমস্পেসকে বিশৃঙ্খলা করা এবং আমি যাকে "লেক্সিকাল প্রক্সিমিটি" বলব। এগুলি আপনার ভাষার উপর নির্ভর করে ভাল বা খারাপ কারণ হতে পারে।

— ফ্র্যাঙ্ক শিয়েরার

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

— কাজ

3

এই মুহূর্তে আমার কাছে বইটি আমার কাছে নেই (উদ্ধৃতি হিসাবে), তবে কোড অনুসারে ফাংশন দৈর্ঘ্যের জন্য "সুইটস্পট" তার গবেষণা অনুসারে কোডের 25-50 লাইনের কাছাকাছি ছিল।

অনেক সময় লম্বা ফাংশন করা ঠিক আছে:

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

দীর্ঘ সময় ধরে কাজ করা ঠিক নয় এমন সময়গুলি:

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

মূল কথাটি হ'ল রক্ষণাবেক্ষণযোগ্যতা আপনার তালিকার সর্বোচ্চ অগ্রাধিকারের একটি হওয়া উচিত। যদি অন্য কোনও দেব আপনার কোডটি না দেখে এবং কোডটি 5 সেকেন্ডেরও কম সময়ে কী করছে তার একটি "सार" পেতে পারে না তবে আপনার কোডটি এটি কী করছে তা বলার জন্য পর্যাপ্ত "মেটাডেটা" সরবরাহ করে না। অন্যান্য ডেভসগুলিকে 100+ কোডের লাইন পড়ার পরিবর্তে আপনার নির্বাচিত আইডিইতে অবজেক্ট ব্রাউজারটি দেখে আপনার ক্লাসটি কী করছে তা বলতে সক্ষম হওয়া উচিত।

ছোট ফাংশনগুলির নিম্নলিখিত সুবিধা রয়েছে:

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

তালিকা চলে .....

— করনিন
সূত্র

2

উত্তরটি এটি নির্ভর করে, তবে আপনার সম্ভবত এটি ক্লাসে পরিণত করা উচিত।

— মিথ্যা রায়ান
সূত্র

আপনি যদি কোনও ওওপিএলে না লিখেন, তবে সেই ক্ষেত্রে সম্ভবত না :)

— ফ্রাঙ্ক শায়ারার

সিমচা উল্লেখ করেছিলেন যে তারা ডি এবং পাইথন ব্যবহার করছিল।

— ফ্রগস্টায়ার 78

ক্লাসগুলি প্রায়শই এমন লোকদের জন্য ক্র্যাচ হয় যেগুলি লেসিকাল ক্লোজারের মতো জিনিস কখনও শুনেনি।

— কাজ

2

আমি বেশিরভাগ নেস্টেড ফাংশন পছন্দ করি না। ল্যাম্বডাস এই বিভাগে পড়ে তবে 30-40 এর বেশি অক্ষর না থাকলে সাধারণত আমাকে পতাকাঙ্কিত করবেন না।

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

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

— পল নাথান
সূত্র

কখনও কখনও আপনাকে একটি বাহ্যিক ফাংশন (যা এটি কেবল স্থানীয় ফাংশন হিসাবে সুবিধাজনক অ্যাক্সেস করতে পারে) এ এত প্রসঙ্গটি পাস করতে হয়েছিল যে ফাংশনটি কী করে তার চেয়ে কী কীভাবে আহ্বান করা হয় তাতে আরও জটিলতা রয়েছে।

— কাজ

1

এটা কি গ্রহণযোগ্য? এটি সত্যিই একটি প্রশ্নের উত্তর কেবল আপনি দিতে পারেন। ফাংশনটি যা প্রয়োজন তা অর্জন করে? এটা কি রক্ষণাবেক্ষণযোগ্য? এটি কি আপনার দলের অন্যান্য সদস্যদের কাছে 'গ্রহণযোগ্য'? যদি তা হয় তবে তা-ই সত্যই গুরুত্বপূর্ণ।

সম্পাদনা: নেস্টেড ফাংশনগুলি সম্পর্কে জিনিসটি আমি দেখতে পাইনি। ব্যক্তিগতভাবে, আমি সেগুলি ব্যবহার করতাম না। পরিবর্তে আমি নিয়মিত ফাংশন ব্যবহার করব।

— GrandmasterB
সূত্র

1

একটি দীর্ঘ "সরলরেখা" ফাংশন একটি নির্দিষ্ট ক্রমে সর্বদা ঘটে যাওয়া ধাপগুলির দীর্ঘ ক্রম নির্দিষ্ট করার জন্য একটি পরিষ্কার উপায় হতে পারে।

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

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

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

— gwideman
সূত্র

1

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

— কেভিন ক্লাইন
সূত্র

0

আমি যখন অজগরটিতে প্রোগ্রামিং করছি, আমি কোনও ফাংশন লেখার পরে ফিরে যেতে চাই এবং নিজেকে জিজ্ঞাসা করি যে এটি "পাইথনের জেন" (আপনার পাইথনের ইন্টারপ্রেটারে 'এটিকে ইম্পোর্ট করুন' টাইপ করুন):

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

1

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

— কাজ

0

এগুলি একটি পৃথক মডিউলে রাখুন।

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

কেবলমাত্র একটি "জনসাধারণ" ফাংশন সহ এগুলিকে একটি মডিউলে রাখুন।
কেবলমাত্র একটি "পাবলিক" (স্ট্যাটিক) ফাংশন সহ এগুলি একটি শ্রেণিতে রাখুন।
এগুলি কোনও ফাংশনে বাসা বাঁধে (যেমনটি আপনি বর্ণনা করেছেন)।

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

— skyking
সূত্র