এক-লাইন পদ্ধতিতে রিটার্ন মান এবং রিটার্নের স্টেটমেন্টের গণনা বিভক্ত করবেন?

Question

একটি সহকর্মীর সাথে আমার একটি returnবক্তব্য এবং স্টেটমেন্টটি ভাঙ্গা নিয়ে আলোচনা হয়েছে যা দুটি লাইনে ফেরতের মান গণনা করে।

উদাহরণ স্বরূপ

private string GetFormattedValue()
{
    var formattedString = format != null ? string.Format(format, value) : value.ToString();
    return formattedString;
}

পরিবর্তে

private string GetFormattedValue()
{
    return format != null ? string.Format(format, value) : value.ToString();
}

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

আমার প্রশ্ন হ'ল, যদি কোডটি কম স্পষ্ট লেখার পক্ষে এটি এখনও একটি বৈধ পয়েন্ট হয় তবে কেবল ডিবাগিংকে আরও সহজে একটি ঝলক দেওয়া যায়? বিভাজন গণনা এবং বিবৃতি দিয়ে বৈকল্পিকের জন্য আরও কি কোনও যুক্তি রয়েছে return?

Comments

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

— tofro

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

— এমসাল্টাররা

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

— ভু

আজকের দিনে কোনও ডিবাগারটিতে "বিবৃতিগুলির খুব বিশদ পরিদর্শন" করা কীভাবে কোডটি লেখার জন্য এটি একটি খারাপ বিকল্প হিসাবে তৈরি করে যাতে কোনও ডিবাগারে ডিবাগ করা সহজ হয়?

— ইয়ান

পুরো ফাংশন বডি কমিয়ে তাকে আরও private string GetFormattedValue() => string.Format(format ?? "{0}", value);

— গ্রাহাম

Answer 1

ভেরিয়েবলগুলি ব্যাখ্যা করা একটি সুপরিচিত রিফ্যাক্টরিং যা কখনও কখনও জটিল ভাবগুলি আরও ভালভাবে পাঠযোগ্য। তবে দেখানো ক্ষেত্রে,

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

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

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

Comments

আমি এটিও সম্মত করি যে, অবশ্যই এর মধ্যে এমন কয়েকটি ক্ষেত্রে কার্যকর রয়েছে যা সন্দেহ নেই।

— পল কার্টেসার

আমি সাধারণত চলকটির resultনাম হিসাবে ব্যবহার করি । ডিবাগ করা এত বেশি দীর্ঘ এবং সহজ নয়

— edc65

@ এডসি 65: একটি জেনেরিক নাম result প্রায়শই কোডটিতে শব্দ যোগ করে এবং খুব কমই পঠনযোগ্যতা বৃদ্ধি করে যা আমার উত্তরটির ঠিক এটিই। এটি প্রাসঙ্গিকভাবে ন্যায়সঙ্গত হতে পারে যেখানে এটি ডিবাগিংয়ে সহায়তা করে তবে আমি যখন কোনও পৃথক ভেরিয়েবলের প্রয়োজন হয় না এমন কোনও ডিবাগার ব্যবহার করার সময় এড়াতে পারি।

— ডক ব্রাউন

আমার মতে @ জনহান্না পথের সরঞ্জামটি দীর্ঘ। নামটি resultতথ্যটি জানায় যে এটি ফাংশনের ফলে প্রাপ্ত মান value যাতে ফাংশন ফেরার আগে আপনি এটির দিকে নজর দিতে পারেন।

— edc65

@ edc65 তবে এটি কার্যকর দেখাচ্ছে। সুতরাং এখন যখন আমি আপনার কোডটি পড়ছি তখনই আমি তাৎক্ষণিকভাবে বুঝতে পারি না এটি তা নয়। সুতরাং আপনার কোডটি কম পঠনযোগ্য হয়ে উঠেছে।

— জন হান্না

Answer 2

সত্য যে দেওয়া:

ক) কম্পাইলারটি ভেরিয়েবলটিকে অপ্টিমাইজ করায় চূড়ান্ত কোডের কোনও প্রভাব নেই।

খ) পৃথক করে রাখলে ডিবাগিং ক্ষমতা বাড়ায়।

আমি ব্যক্তিগতভাবে এই সিদ্ধান্তে পৌঁছেছি যে তাদের 99% সময়কে আলাদা করা ভাল অভ্যাস।

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

Comments

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

— ম্যাথু জেমস ব্রিগেস 16

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

— জন রেয়নর

রিটার্ন মানটির জন্য @ জনরাইনর, ফাংশনের সমাপ্তি বন্ধনীটিতে ব্রেকপয়েন্টটি রাখুন। এটি একাধিক রিটার্ন সহ ফাংশনে এমনকি ফেরত মানটি ধরে value

— বাল্ড্রিক

Answer 3

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

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

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

Comments

"আমি উভয় সমাধানই বিভ্রান্তিমূলক মনে করি কারণ শর্তসাপেক্ষ অপারেটর অহেতুক ব্যবহৃত হচ্ছে।" - এটি সত্যিকারের বিশ্বের উদাহরণ নয়, আমাকে দ্রুত কিছুটা তৈরি করতে হয়েছিল। স্বীকারোক্তিটি এটি সর্বোত্তম উদাহরণ নাও হতে পারে।

— পল কার্টেসার

এটি মূলত "রাডারের নীচে" পার্থক্যের জন্য বলার জন্য +1 (অন্যান্য জিনিস সমান হচ্ছে) যেটি উদ্বিগ্ন তা হওয়া উচিত নয়।

— ট্রিপহাউন্ড

@ মাইন্ডউইন, আমি যখন টার্নারি অপারেটর ব্যবহার করি তখন আমি সাধারণত এটি একাধিক লাইনে বিভক্ত করি যাতে এটি স্পষ্ট হয় যে আসল ঘটনাটি কী এবং মিথ্যা মামলা কী।

— আর্টুরো টরেস সানচেজ

@ ArturoTorresSánchez আমি যে খুব না, কিন্তু এর পরিবর্তে একটি এর ?এবং :আমি ব্যবহারের if() {এবং } else {- - - - \\ :)

— Mindwin

@ মাইন্ডউইন, তবে যখন আমি কোনও অভিব্যক্তির মাঝামাঝি (কোনও অবজেক্ট ইনিশিয়ালাইজারের মতো) থাকি তখন আমি তা করতে পারি না

— আর্টুরো টরেস সানচেজ

Answer 4

আপনার প্রশ্নের জবাবে:

আমার প্রশ্ন হ'ল, যদি কোডটি কম স্পষ্ট লেখার পক্ষে এটি এখনও একটি বৈধ পয়েন্ট হয় তবে কেবল ডিবাগিংকে আরও সহজে একটি ঝলক দেওয়া যায়?

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

ডিবাগিংকে সহজ করে তোলা (প্রায়) কখনই " ছোট মেধা " এর নয়, কারণ কিছু অনুমান হিসাবে কোনও প্রোগ্রামারের 50% সময় ডিবাগিং ( রিভার্সিবল ডিবাগিং সফ্টওয়্যার ) ব্যয় করে ।

বিভাজন গণনা এবং রিটার্ন বিবৃতি দিয়ে বৈকল্পিকের জন্য আরও কি যুক্তি রয়েছে?

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

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

Answer 5

আমি আরও যেতে হবে:

private string GetFormattedValue()
{
    if (format != null) {
        formattedString = string.Format(format, value);
    } else {
        formattedString = value.ToString()
    }
    return formattedString;
}

কেন?

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

আরেকটি সুবিধা হ'ল আপনার কোড কভারেজ রিপোর্টটি আপনাকে জানাতে দেবে যে আপনি যদি কোনও পরীক্ষা নষ্ট formatনা করে ভুলে যান তবে । এটি টার্নারি অপারেটরের ক্ষেত্রে হবে না।

---

আমার পছন্দের বিকল্প - যদি আপনি "যত দ্রুত ভিড়ের সাথে দ্রুত রিটার্ন পান" তে থাকেন এবং কোনও পদ্ধতি থেকে একাধিক রিটার্নের বিরুদ্ধে না থেকে থাকেন:

private string GetFormattedValue()
{
    if (format != null) {
        return string.Format(format, value);
    }

    return value.ToString();
}

সুতরাং, আপনি ডিফল্টটি কী তা দেখতে শেষ রিটার্নটি দেখতে পারেন।

যদিও এটি সামঞ্জস্যপূর্ণ হওয়া জরুরী - এবং আপনার সমস্ত পদ্ধতি একটি বা অন্য কনভেনশন অনুসরণ করে।

Comments

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

— স্টিভ

কেন private string GetFormattedValue() => string.Format(format ?? "{0}", value); একই প্রভাব ফেলবে না , এবং ডিবাগারের উপর নির্ভর না করে নির্ভুলতা নিশ্চিত করতে ইউনিট পরীক্ষাগুলি ব্যবহার করে।

— বেরিন লরিটস

যদিও আমি সম্মত একটি তিন পারেন কম পরিষ্কার হবে, নাল টারমিনেটর জিনিষ করতে পারেন আরো স্পষ্ট। অন্তত এই ক্ষেত্রে।

— বারিন লরিটস

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

— ভ্যাক্সকুইস

"আরও জটিল যুক্তির জন্য ত্রিনিরি অপারেটরগুলি ব্যবহার করা অপঠনযোগ্য হবে" যদিও এটি প্রকৃতপক্ষে ঘটনা (এবং আমি লোককে অতিরিক্ত সংখ্যক যুক্তি দেখিয়েছি) এটি ওপি কোডের ক্ষেত্রে সত্য নয়, এবং টের্নারি অপারেটরগুলির পক্ষেও এটি নির্দিষ্ট বিষয় নয়। আমি সম্পূর্ণ আত্মবিশ্বাসের সাথে একটাই বলতে পারি যে লাইনটি দীর্ঘ। gist.github.com/milleniumbug/cf9b62cac32a07899378fif6c06c776 আমি কীভাবে এটির পুনর্নির্মাণ করব।

— milleniumbug

Answer 6

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

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

Comments

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

— tale852150

Answer 7

আমি মনে করি কিছু লোক এই জাতীয় যেমন টের্নারি অপারেটরের মতো প্রশ্নের স্পর্শকাতর বিষয়গুলিতে ঝুঁকছেন। হ্যাঁ, প্রচুর লোকেরা এটি ঘৃণা করে, তাই যাইহোক এটি আনাই ভাল।

আপনার প্রশ্নের কেন্দ্রবিন্দু সম্পর্কিত, ফেরত দেওয়া বিবৃতিটি একটি ভেরিয়েবল দ্বারা রেফারেন্স করার জন্য সরানো ...

এই প্রশ্নটি এমন দুটি অনুমান করে যার সাথে আমি একমত নই:

1. যে দ্বিতীয় রূপটি আরও স্পষ্ট বা পড়তে সহজ (আমি বলছি বিপরীতটি সত্য), এবং

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

একটি নামযুক্ত ভেরিয়েবলের বাইরে কিছু ভাঙ্গা খুব কমই পড়া সহজ করে তোলে, এটি প্রায়শই বিপরীত হয়। কেউ যে নির্দিষ্ট পদ্ধতিতে এটি করে তাতে সমস্যা হতে পারে, যেমন যদি কোনও স্ব-ডকুমেন্টেশন ওভারলর্ড var thisVariableIsTheFormattedResultAndWillBeTheReturnValue = ...স্পষ্টতই এটি খারাপ, তবে এটি একটি পৃথক বিষয়। var formattedText = ...ভাল.

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

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

যেহেতু এটির মান যুক্ত হওয়ার সম্ভাবনা নেই তাই নির্দিষ্ট উদাহরণের জন্য আমি 2 টি লাইন করব না। আমি ভেরিয়েন্ট 2 (1-লাইনার) করব কারণ পয়েন্টগুলি এ ক্ষেত্রে অন্যথায় করার মতো শক্তিশালী নয়।