কোঁকড়ানো ধনুর্বন্ধনী ছাড়া একটি বিবৃতি ব্যবহার করা কি খারাপ অভ্যাস? [বন্ধ]


130

আমি এর মতো কোড দেখেছি:

if(statement)
    do this;
else
    do this;

তবে আমি মনে করি এটি আরও পঠনযোগ্য:

if(statement){
    do this;
}else{
    do this;
}

যেহেতু উভয় পদ্ধতিই কাজ করে, তাই এটি কি কেবল পছন্দের বিষয় যা কোনটি ব্যবহার করা উচিত বা অন্যদিকে কোনও উপায়ে সুপারিশ করা হবে?



আমার মতে এটি খারাপ, কারণ আপনি হোয়াইটস্পেস ইনডেন্টেশনের উপর নির্ভর করা শুরু করেন যা প্রায় সম্পূর্ণরূপে সামঞ্জস্যপূর্ণ হয় না। পাঠকদের চিন্তার ট্রেনটি লাইনচ্যুত করে যখন তাদের যখন এই জাতীয় বিষয় নিয়ে চিন্তা করতে হয়।
শ্রীধর সারনোবাত 21

উত্তর:


212

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

রক্ষণাবেক্ষণের ভিত্তিতে, দ্বিতীয় ফর্মটি ব্যবহার করা সর্বদা বুদ্ধিমান ।

সম্পাদনা: নেড মন্তব্যগুলিতে এই বিষয়টি উল্লেখ করেছেন, তবে এটি এখানে লিঙ্ক করাও মূল্যবান বলে মনে করি। এটি কেবলমাত্র কিছু আইভরি-টাওয়ার অনুমানীয় বুলশিট নয়: https://www.imperialviolet.org/2014/02/22/applebug.html


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

12
অথবা আপনি এমন কোনও ভাষা ব্যবহার করতে পারেন যা কোড ব্লকগুলির জন্য বন্ধনী ব্যবহার করে না ...
টোর ভ্যালামো

10
@ লিনস 314159 - না, আমি পাইথনের মতোই বোঝাতে চাইছি। কারণ আমি এক্ষেত্রে গোঁড়াবাদী
টোর ভালামো

17
আরও প্রমাণের ভুলগুলি ঘটতে পারে (এবং করতে পারে): imperialviolet.org/2014/02/22/applebug.html
নেড

8
এসএসএল বাগটি ধনুর্বন্ধনীগুলির পক্ষে একটি যুক্তি হিসাবে দাবি করা স্বতন্ত্র is এটি এমন নয় যে বিকাশকারী লেখার ইচ্ছা করেছিলেন if (…) { goto L; goto L; }তবে বন্ধনীগুলি ভুলে গেছেন। এটি সম্পূর্ণরূপে কাকতালীয় যে `` if (…) {গোতো এল; গেটো এল; `a সুরক্ষা বাগ হিসাবে না ঘটে, কারণ এটি এখনও একটি বাগ (সুরক্ষা পরিণতিতে কেবল একটি নয়)। অন্য উদাহরণে, জিনিসগুলি বিপরীত দিকে যেতে পারে এবং ব্রেসলেস কোডটি দুর্ঘটনাক্রমে নিরাপদ হতে পারে। তৃতীয় উদাহরণে, ব্রেসলেস কোডটি প্রাথমিকভাবে বাগ-মুক্ত হবে এবং বিকাশকারীগুলি যুক্ত করার সময় বিকাশকারী একটি টাইপো প্রবর্তন করবে।
পাস্কেল কুয়াক

112

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

if(one)
    if(two)
        foo();
    else
        bar();

এটা থেকে:

if(one)
    if(two)
        foo();
else
    bar();

8
এটি শীর্ষ উত্তরের (দ্বিতীয় বিবৃতি যোগ করার ক্ষেত্রে) উল্লিখিত একের চেয়ে অনেক বেশি গুরুতর সমস্যা।

3
প্রকৃতপক্ষে, এই উত্তরটি আসলে আমাকে উত্তরগুলি মাতাল হয়ে পড়া থেকে মৃদুভাবে উদ্বিগ্ন করার দিকে নিয়ে গিয়েছিল আমি সম্ভবত এই ভুলটি করতে পারি।
omikes

2
যদি অন্য কেউ যদি ভাবছিলেন যে আমি আসলে সিটি কোন উপায়ে এটি ব্যাখ্যা করে তবে জিসিসির সাথে আমি যে পরীক্ষাটি করেছি তা এই কোডটিকে প্রথমভাবে ব্যাখ্যা করে। tpcg.io/NIYeqx
horta

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

35

আমার সাধারণ প্যাটার্নটি হ'ল এটি যদি এক লাইনে ফিট করে তবে আমি করব:

if(true) do_something();

যদি অন্য কোনও ধারা থাকে, বা আমি যে কোডটি চালাতে চাই তা trueযদি উল্লেখযোগ্য দৈর্ঘ্যের হয় তবে সমস্তভাবেই বন্ধনীগুলি:

if(true) {
    do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}

if(false) {
    do_something();
} else {
    do_something_else();
}

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


4
যদিও এটি লেখা সহজ তত সহজ if(true){ do_something(); }, কেন অন্য প্রোগ্রামার রাস্তায় একটি গুরুতর বাগ প্রবর্তন করার সুযোগ নেবে (অ্যাপলের "গেটো ফেইল" মোট এসএসএল কোড স্ক্রুআপ দেখছে)।
ক্রেগ

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

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

10

আমি যে আইডিই ব্যবহার করি তার কোড ফর্ম্যাটরটি ব্যবহার করছি। এটি পৃথক হতে পারে তবে এটি পছন্দ / বিকল্পগুলিতে সেটআপ করা যেতে পারে।

আমার এটা ভাল লেগেছে:

if (statement)
{
    // comment to denote in words the case
    do this;
    // keep this block simple, if more than 10-15 lines needed, I add a function for it
}
else
{
    do this;
}

5
এটি সম্পূর্ণরূপে বিষয়গত শৈলীর সমস্যা হওয়ায় আমি ব্যক্তিগতভাবে ব্রেস-কেবলমাত্র রেখার অপ্রয়োজনীয়তা পছন্দ করি না। তবে আরে।
ম্যাচু

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

6
আমি সবসময় এই স্টাইলটি পছন্দ করেছি। সম্পর্কিত সমাপ্ত বন্ধনীগুলি খুঁজে পাওয়া অনেক সহজ। তাহলে অনেক জায়গা লাগে? একটি ছোট ফন্ট ব্যবহার করুন।
টিমডে

4
ব্রেসগুলি যখন আলাদা লাইনে থাকে তখন আমি কোডের মাধ্যমে সর্বদা "স্ক্যান" করা সহজ করি। যে সব কিছু যায়; ক্লাস, পদ্ধতি, যদি- এবং যখন-বিবৃতি, ইত্যাদি। একই লাইনে প্রথম ব্রেস থাকা কখনও পছন্দ
করেনি

2
হোয়াইটস্পেস সস্তা, বিশেষত যখন আপনার কাছে কোড ফোল্ডিং সক্ষম আইডিই থাকে।
মো

10

আমি যে "বিধি" অনুসরণ করি তা হ'ল:

যদি "যদি" স্টেটমেন্টটি কিছু করার জন্য পরীক্ষা করে থাকে (IE কল ফাংশনগুলি, ভেরিয়েবলগুলি কনফিগার করুন ইত্যাদি), বন্ধনী ব্যবহার করুন।

if($test)
{
    doSomething();
}

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

যদি "যদি" বিবৃতিটি কিছু করা বন্ধ করার জন্য পরীক্ষা করে থাকে (কোনও লুপ বা ফাংশনের মধ্যে IE প্রবাহ নিয়ন্ত্রণ), একটি একক লাইন ব্যবহার করুন।

if($test) continue;
if($test) break;
if($test) return;

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


8

ঠিক প্রথম মুহুর্ত থেকে ধনুর্বন্ধনী থাকা আপনাকে এটিকে কখনও ডিবাগ করা থেকে বিরত রাখতে সহায়তা করে:

if (statement)
     do this;
else
     do this;
     do that;

1
এটি গ্রহণযোগ্য যুক্তি বলে মনে হচ্ছে, তবে (এখানে শয়তানের উকিল বাজানো) একটি লাইন সংরক্ষণ করার পরে, একটি অতিরিক্ত অতিরিক্ত বাক্য গঠন-হাইলাইটিং নিয়মটিও এটি সমাধান করবে না?
কেন

2
সুতরাং এমন একটি আইডিই থাকবে যা আঘাত করলে আপনি ইন্ডেন্টেশনটি সংশোধন করে ;:)
স্যাম হারওল

6

এমনকি সাধারণগুলির বিবৃতি থাকলেও সবার জন্য বন্ধনী ব্যবহার করুন। অথবা, টের্নারি অপারেটরটি ব্যবহার করতে একটি সাধারণ বিবৃতি পুনরায় লিখুন:

if (someFlag) {
 someVar= 'someVal1';
} else {
 someVar= 'someVal2';
}

দেখতে অনেক সুন্দর লাগছে:

someVar= someFlag ? 'someVal1' : 'someVal2';

তবে কেবলমাত্র টের্নারি অপারেটরটি ব্যবহার করুন যদি আপনি সম্পূর্ণরূপে নিশ্চিত হন যে যদি / অন্য ব্লকগুলিতে যাওয়ার দরকার নেই তবে অন্য কিছু নেই!


4

আমি ধনুর্বন্ধনী ব্যবহার পছন্দ করি। ব্রেস যুক্ত করা পড়া এবং সংশোধন করা সহজ করে তোলে।

ধনুর্বন্ধনী ব্যবহারের জন্য এখানে কয়েকটি লিঙ্ক রয়েছে:


2

আমার অভিজ্ঞতা থেকে প্রথম ফর্মের একমাত্র (খুব) সামান্য সুবিধা হ'ল কোড পঠনযোগ্যতা, দ্বিতীয় ফর্মটি "শব্দ" যোগ করে।

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

পর্যাপ্ত শক্তি গ্রহণকারী বাগ রয়েছে, লোকেরা সময়ের অপচয়গুলির জন্য কেবল দরজা খোলে না।

কোড লেখার সময় মনে রাখা সবচেয়ে গুরুত্বপূর্ণ নিয়মের একটি হ'ল ধারাবাহিকতা। কোডের প্রতিটি লাইন একইভাবে লিখতে হবে, এটি কে লিখেছে তা বিবেচনা করেই। কঠোর হওয়ার কারণে বাগগুলি "ঘটতে" বাধা দেয়;)

আপনার ভেরিয়েবলগুলি, পদ্ধতিগুলি, ফাইলগুলিকে স্পষ্টভাবে এবং স্পষ্টভাবে নামকরণ করার সাথে বা সঠিকভাবে ইনডেন্ট করার সাথে এটি একই ...

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


2

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

if(statement)
{
    do this;
}
else
{
    do this;
}

যাইহোক, আমি মনে করি পাইথন এ সমস্যার সর্বোত্তম সমাধান solution হোয়াইটস্পেস-ভিত্তিক ব্লক স্ট্রাকচারের সাথে, আপনার কাছে একটি বিবৃতি তৈরির দুটি পৃথক পদ্ধতি নেই: আপনার কেবল একটি রয়েছে:

if statement:
    do this
else:
    do this

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


আমি নিজেই মনে করি যেভাবে পাইথন কীভাবে হ্যান্ডেল করে - যদি অন্য বিবৃতিগুলি খুব
কুরুচিপূর্ণ হয়

1

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

কাজ করবে না:

যদি (বিবৃতি) এটি করে; এবং এই; অন্যথায় এটি করুন;


1

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

উদাহরণ:

if (argument == null)
    throw new ArgumentNullException("argument");

if (argument < 0)
    return false;

নইলে আমি দ্বিতীয় স্টাইলটি ব্যবহার করি।


1

আমার ব্যক্তিগত পছন্দগুলি এই জাতীয় সাদা অংশ এবং বন্ধনীগুলির মিশ্রণটি ব্যবহার করছে:

if( statement ) {

    // let's do this

} else {

    // well that sucks

}

আমি মনে করি এটি পরিষ্কার দেখায় এবং আমার কোডটি পড়তে খুব সহজ করে এবং সবচেয়ে গুরুত্বপূর্ণভাবে - ডিবাগ করে।


0

আমি বেশিরভাগ উত্তরের সাথে একমত যে আপনার কোডে স্পষ্ট হওয়া এবং ব্রেস ব্যবহার করা ভাল। ব্যক্তিগতভাবে আমি কোডিং মানগুলির একটি সেট গ্রহণ করব এবং এটি নিশ্চিত করব যে দলের সবাই তাদের চেনে এবং তা মেনে চলে। আমি যেখানে কাজ করি আমরা । নেট প্রকল্পের জন্য IDesign.net দ্বারা প্রকাশিত কোডিং মান ব্যবহার করি ।


0

আমি একটি কোঁকড়া ধনুর্বন্ধনী করা পছন্দ। তবে কখনও কখনও, টার্নারি অপারেটর সহায়তা করে।

পরিবর্তে :

int x = 0;
if (condition) {
    x = 30;
} else {
    x = 10;
}

একটি সহজভাবে করা উচিত: int x = condition ? 30 : 20;

একটি কেস কল্পনাও করুন:

if (condition)
    x = 30;
else if (condition1)
    x = 10;
else if (condition2)
    x = 20;

আপনি কোঁকড়ানো ধনুর্বন্ধনী ভিতরে রাখলে এটি আরও ভাল হবে।

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