বিকাশকারীরা জোর দিয়ে বলেন যে বিবৃতিগুলির অবহেলিত শর্ত না থাকা উচিত এবং সর্বদা অন্য কোনও ব্লক থাকা উচিত


169

আমার পরিচিত একজন, আমার চেয়ে আরও বেশি মজাদার বিকাশকারী। আমরা প্রোগ্রামিং অনুশীলন সম্পর্কে কথা বলছিলাম এবং 'যদি' বিবৃতিতে তার পদ্ধতির দ্বারা আমাকে হতাশ করা হয়েছিল। তিনি বিবৃতি যে আমি বরং অদ্ভুত মনে হয় সম্পর্কে কিছু অনুশীলন জোর।

প্রথমত , যদি একটি বিবৃতি অনুসরণ করা উচিত অন্য বিবৃতি অনুসরণ করা উচিত, এটিতে কিছু রাখা আছে কি না। যা কোডটির মতো দেখায় বাড়ে:

if(condition) 
{
    doStuff();
    return whatever;
}
else
{
}

দ্বিতীয়ত , মিথ্যা নয় সত্যের মানগুলির জন্য পরীক্ষা করা ভাল। তার মানে হল যে একটি 'ডোরক্লোজড' ভেরিয়েবলের পরিবর্তে 'ডোরক্লোজড' ভেরিয়েবল পরীক্ষা করা ভাল

তার যুক্তি হ'ল কোডটি কী করছে তা স্পষ্ট করে দেয়।

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

if(condition)
{
}
else
{
    doStuff();
    return whatever;
}

এ সম্পর্কে আমার অনুভূতিটি হ'ল এটি প্রকৃতপক্ষে খুব কুৎসিত এবং / অথবা মানের উন্নতি, যদি থাকে তবে তা নগণ্য। তবে জুনিয়র হিসাবে আমি আমার প্রবৃত্তি সম্পর্কে সন্দেহ পোষণ করি।

সুতরাং আমার প্রশ্নগুলি হ'ল : এটা কি ভাল / খারাপ / অনুশীলন "খারাপ কিছু না"? এটা কি সাধারণ অনুশীলন?



57
আপনার সহকর্মী এমন একটি পটভূমি থেকে এসেছেন যেখানে জীবন এবং অঙ্গ-প্রত্যঙ্গ ঝুঁকিতে পড়তে পারে? আমি বিশ্বাস করি যে সিস্টেমগুলিতে আমি এই ধরণের জিনিসটির কয়েকটি উল্লেখ দেখেছি যেখানে কোডে একটি ক্র্যাপ টন টেস্টিং এবং স্বয়ংক্রিয় বিশ্লেষণ করা হয় এবং যেখানে এটি ভুল হয়ে যায় সে কারণে আক্ষরিকভাবে কারওর জন্য জীবন ব্যয় করতে পারে।
jpmc26

11
আপনার কোম্পানির কোড স্টাইল গাইড কী বলে?
থোরবজর্ন রাভন অ্যান্ডারসন

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

9
"আপনার কোডটি নিরর্থক এবং অকেজো, আপনি কি আমাকে মুছতে / রিফেক্টরটি মুছতে চান?" এর লাইনে রিশার্পারের কাছে আপনার বন্ধুকে কিছু বলার দরকার ছিল? "
বিজিআর ওয়ার্কার

উত্তর:


184

সুস্পষ্ট elseব্লক

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

আমি এমনকি এই সত্যটি উল্লেখ করি না যে একটি ifবিবৃতি অগত্যা হয় হয় elseবা কিছুই দ্বারা অনুসরণ করা হয় না: এটি এক বা একাধিক দ্বারা অনুসরণ করা যেতে পারে elif

returnবিবৃতি উপস্থিতি জিনিস আরও খারাপ করে তোলে। এমনকি যদি আপনার কাছে elseব্লকের মধ্যে কার্যকর করার কোড ছিল তবে এটি এটি করা আরও পঠনযোগ্য:

if (something)
{
    doStuff();
    return whatever;
}

doOtherThings();
return somethingElse;

এর ফলে কোডটি দুটি লাইন কম নেয়, এবং elseব্লকটি অনিয়ম করে । গার্ডের ক্লজগুলি সে সম্পর্কে।

তবে খেয়াল করুন যে আপনার সহকর্মীর কৌশলটি কোনও ফাঁকা জায়গা ছাড়াই স্ট্যাকড শর্তাধীন ব্লকের একটি খুব বাজে প্যাটার্নটিকে আংশিকভাবে সমাধান করতে পারে:

if (something)
{
}
if (other)
{
}
else
{
}

পূর্ববর্তী কোডে, প্রথম ifব্লকের পরে বুদ্ধিমান লাইন বিরতির অভাবে কোডটির ভুল ব্যাখ্যা করা খুব সহজ হয়ে যায়। যাইহোক, আপনার সহকর্মীর নিয়মটি কোডটি ভুলভাবে পড়তে আরও জটিল করে তুলবে, তবে একটি সহজ সমাধান হ'ল কেবল একটি নতুন লাইন যুক্ত করা।

জন্য পরীক্ষা, জন্য trueনয়false

দ্বিতীয় নিয়মটি কিছুটা অর্থপূর্ণ হতে পারে তবে এটি বর্তমান রূপে নয়।

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

if (!this.IsMaster || (!this.Ready && !this.CanWrite))

এটিকে সমাধান করার জন্য, খালি ব্লকগুলি যুক্ত করার পরিবর্তে , প্রাসঙ্গিক বা স্থানীয় ভেরিয়েবলগুলি যুক্ত করে অতিরিক্ত বৈশিষ্ট্য তৈরি করুন

উপরের শর্তটি সহজেই পাঠযোগ্য হয়ে উঠতে পারে:

if (this.IsSlave || (this.Synchronizing && this.ReadOnly))

169
খালি ব্লক সবসময় আমার কাছে ভুলের মতো দেখায়। এটি সঙ্গে সঙ্গে আমার দৃষ্টি আকর্ষণ করবে এবং আমি জিজ্ঞাসা করব 'এটি এখানে কেন?'
নেলসন

50
@ নীল একটি শর্তে আলোচনা করার জন্য অতিরিক্ত কোনও সিপিইউ সময় প্রয়োজন হয় না। সি এক্স 86 থেকে কম্পাইল মাত্র লাফ নির্দেশ থেকে অদলবদল পারে JZজন্য (যদি জিরো ঝাঁপ দাও) if (foo)থেকে JNZ(ঝাঁপ দাও যদি না জিরো) জন্য if (!foo)
বিট্রি

71
" স্পষ্ট নাম সহ অতিরিক্ত সম্পত্তি তৈরি করুন ": যদি আপনি ডোমেনটির গভীর বিশ্লেষণ না করেন তবে এটি স্থানীয় সমস্যা সমাধানের জন্য বিশ্বব্যাপী সুযোগ (মূল শ্রেণি) পরিবর্তন করতে পারে (নির্দিষ্ট ব্যবসায়ের নিয়মের প্রয়োগ)। এখানে একটি জিনিস করা যেতে পারে তা হ'ল স্থানীয় বুলিয়ানগুলি পছন্দসই রাজ্যের সাথে তৈরি করা, যেমন "var isSlave =! This.IsMaster" এবং আপনার যদি প্রয়োগ হয় অন্যান্য স্থানীয় বৈশিষ্ট্য তৈরির পরিবর্তে স্থানীয় বুলিয়ানদের সাথে with সুতরাং, নুনের দানার সাথে পরামর্শ নিন এবং নতুন বৈশিষ্ট্য তৈরি করার আগে ডোমেনটি বিশ্লেষণ করতে কিছুটা সময় নিন।
মাচাডো

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

15
@Mark যে, কম পরিষ্কার বললেন চেয়ে আরও মন্তব্য সহ if (!commonCase) { handle the uncommon case },যদিও।
পল

62

প্রথম নিয়ম সম্পর্কে, এটি অকেজো টাইপ করার একটি উদাহরণ। এটি টাইপ করতে কেবল বেশি সময় নেয় না, কোড পড়ার জন্য এটি বিপুল পরিমাণে বিভ্রান্তি সৃষ্টি করবে। কোডটির প্রয়োজন না থাকলে এটি লিখবেন না। elseকোডটি ifব্লক থেকে ফিরে আসার সাথে সাথে এটি আপনার ক্ষেত্রে জনবসতি নাও বাড়িয়ে দেবে :

if(condition) 
{
    doStuff();
    return whatever;
}

doSomethingElse(); // no else needed
return somethingelse;

দ্বিতীয় দফার বিষয়ে, বুলিয়ান নামগুলি এড়ানো ভাল যা নেতিবাচক রয়েছে:

bool doorNotOpen = false; // a double negative is hard to reason
bool doorClosed = false; // this is much clearer

তবে, এটি ইতিবাচক হিসাবে পরীক্ষা না করা পর্যন্ত প্রসারিত করা যেমন আপনি উল্লেখ করেছেন, আরও বেহুদা টাইপিংয়ের দিকে নিয়ে যায়। নিম্নলিখিতটি খালি ifব্লক থাকার চেয়ে আরও পরিষ্কার :

if(!condition)
{
    doStuff();
    return whatever;
}

120
সুতরাং ... আপনি বলতে পারেন যে ডাবল নেতিবাচক একটি নো? ;)
প্যাটসুয়ান

6
@ পাতসুয়ান, খুব চালাক আমি এটা পছন্দ করি। :)
ডেভিড আরনো

4
আমি মনে করি যে অনেকেই কীভাবে অন্যরকম রিটার্নগুলি হ্যান্ডেল করা উচিত তা নিয়ে একমত হবেন না এবং কেউ কেউ এমনকি বলছেন যে এটি প্রতিটি দৃশ্যে একইভাবে পরিচালনা করা উচিত নয়। আমার নিজের দৃ strong় পছন্দ নেই, তবে এটি করার অন্যান্য অনেকগুলি উপায়ের পিছনে আমি অবশ্যই যুক্তি দেখতে পাচ্ছি।
ডিউক্লিং

6
স্পষ্টতই, if (!doorNotOpen)ভয়াবহ। সুতরাং নামগুলি যথাসম্ভব ইতিবাচক হওয়া উচিত। if (! doorClosed)পুরোপুরি ঠিক আছে।
ডেভিড শোয়ার্টজ

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

45

1. খালি elseবিবৃতি দেওয়ার পক্ষে যুক্তি argument

আমি প্রায়শই প্রথম নির্মাণের মতো কিছু ব্যবহার করি (এবং তর্ক করি), অন্যটি শূন্য। এটি কোডের পাঠকদের (মানব এবং স্বয়ংক্রিয় বিশ্লেষণের সরঞ্জাম উভয়) সংকেত দেয় যা প্রোগ্রামার পরিস্থিতিটির মধ্যে কিছু চিন্তাভাবনা ফেলেছে। অনুপস্থিত elseবিবৃতি যা উপস্থিত হওয়া উচিত ছিল তা মানুষকে হত্যা, ক্র্যাশ হয়ে যাওয়া এবং কয়েক মিলিয়ন ডলার ব্যয় করেছিল। উদাহরণস্বরূপ, মিস্রা-সি কমপক্ষে একটি মন্তব্য আদেশ দেয় যে অনুপস্থিত ফাইনাল অন্য একটি if (condition_1) {do_this;} else if (condition_2) {do_that;} ... else if (condition_n) {do_something_else;}অনুক্রমের উদ্দেশ্যমূলক । অন্যান্য উচ্চ নির্ভরযোগ্যতার মানগুলি আরও এগিয়ে যায়: কয়েকটি ব্যতিক্রম বাদে অন্য বিবৃতি অনুপস্থিত।

একটি ব্যতিক্রম একটি সাধারণ মন্তব্য, এর লাইন বরাবর কিছু /* Else not required */। এটি তিনটি লাইন খালি খালি করার মতো একই অভিপ্রায়কে ইঙ্গিত দেয়। অন্য যে ব্যতিক্রম যেখানে খালি আর দরকার নেই তা হ'ল এটি কোডের পাঠক এবং স্বয়ংক্রিয় বিশ্লেষণ সরঞ্জামগুলির উভয়ের কাছে স্পষ্টরূপে সুস্পষ্ট that যে খালি অন্যটি অতিমাত্রায়। উদাহরণস্বরূপ, if (condition) { do_stuff; return; }একইভাবে, এর পরিবর্তে 1throw something বা goto some_label1 এর ক্ষেত্রে খালি অন্য কোনও প্রয়োজন হয় না return

২. if (condition)বেশি পছন্দ করার পক্ষে যুক্তি if (!condition)

এটি একটি মানবিক উপাদান। জটিল বুলিয়ান যুক্তি বহু লোককে ট্রিপ করে। এমনকি একটি পাকা প্রোগ্রামার সম্পর্কে চিন্তা করতে হবে if (!(complex || (boolean && condition))) do_that; else do_this;। সর্বনিম্ন, এটিকে আবার লিখুন if (complex || (boolean && condition)) do_this; else do_that;

৩. এর অর্থ এই নয় যে খালি thenবিবৃতি দেওয়া উচিত ।

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



1 আমি লিখেছিলাম যে এরপরে যে ধারাগুলি শেষ হয়েছে return, throwবা gotoঅন্য কোনও খালি দরকার নেই। এটি স্পষ্ট যে অন্য ক্লজের প্রয়োজন নেই। তবে কি goto? একদিকে যেমন, সুরক্ষা-সমালোচনামূলক প্রোগ্রামিং নিয়মগুলি কখনও কখনও তাড়াতাড়ি ফিরতি অস্বীকার করে এবং প্রায় সর্বদা ছোঁড়া ব্যতিক্রমকে অস্বীকার করে। তবে তারা gotoএকটি সীমিত আকারে (যেমন, goto cleanup1;) অনুমতি দেয় । এই সীমাবদ্ধ ব্যবহারটি gotoকিছু জায়গায় পছন্দসই অনুশীলন। লিনাক্স কার্নেল, উদাহরণস্বরূপ, এই জাতীয় gotoবিবৃতি চকফুল ।


6
!এছাড়াও সহজেই উপেক্ষা করা হয়। এটি খুব ক্লান্ত।
থোরবজর্ন রাভন অ্যান্ডারসন

4
না, অন্য কোনও খালি এটি পরিষ্কার করে না যে প্রোগ্রামার এতে কিছু চিন্তা রেখেছিল। এটি আরও বিভ্রান্তির দিকে নিয়ে যায় "" সেখানে কি কিছু বক্তব্য পরিকল্পনা করা হয়েছিল এবং সেগুলি ভুলে গিয়েছিল বা কেন একটি খালি ধারা আছে? " একটি মন্তব্য অনেক পরিষ্কার।
সাইমন

9
@ সিমন: একটি সাধারণ ফর্মটি হ'ল else { /* Intentionally empty */ }বা সেই লাইনের পাশাপাশি কিছু। খালি অন্যটি স্থির বিশ্লেষককে সন্তুষ্ট করে যা নির্বোধভাবে নিয়ম লঙ্ঘনের সন্ধান করে। মন্তব্য পাঠকদের অবহিত করে যে খালিটি ইচ্ছাকৃত। তারপরে, পাকা প্রোগ্রামাররা সাধারণত মন্তব্যটিকে অপ্রয়োজনীয় হিসাবে বাদ দেয় - তবে অন্যটি খালি নয়। উচ্চ নির্ভরযোগ্যতা প্রোগ্রামিং এর নিজস্ব একটি ডোমেন। নির্মাণগুলি বাইরের লোকদের কাছে বরং অদ্ভুত দেখাচ্ছে। জীবন ও মৃত্যু বা hand হাতের কাছে থাকার সময় হার্ড কড়া নাট, কড়া স্কুল থেকে পাঠের কারণে এই নির্মাণগুলি ব্যবহার করা হয়।
ডেভিড হামেন

2
আমি বুঝতে পারি না যে শূন্যস্থানগুলি কীভাবে খারাপ জিনিস যখন খালি অন্য ক্লোজগুলি না থাকে (ধরে নেওয়া আমরা সেই স্টাইলটি বেছে নিই)। আমি দেখতে পাচ্ছিif (target == source) then /* we need to do nothing */ else updateTarget(source)
বার্গি

2
@ থরবজর্নআরভানএন্ডারসন নোপ, notসি ++ এর একটি কীওয়ার্ড, যেমনটি অন্যান্য বিটওয়াইজ এবং লজিকাল অপারেটরগুলি। দেখুন বিকল্প অপারেটর উপস্থাপনা
রুসলান

31

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

if (condition) {
    // No action needed because ...
} else {
    do_else_action()
}

if (condition) {
    do_if_action()
} else {
    // No action needed because ...
}

কিন্তু না:

if (condition) {
    do_if_action()
} else {
    // I was told that an if always should have an else ...
}

5
এই. আমি বিবৃতিটি বিবৃতিটির if test succeeds -> no action needed -> else -> action neededকাছে শব্দার্থগতভাবে খুব আলাদা বলে মনে করি if it applies that the opposite of a test outcome is true then an action is needed। আমি মার্টিন ফোলারের উক্তিটির কথা মনে করিয়ে দিচ্ছি: "যে কেউ কোড কম্পিউটার লিখতে পারে তা বুঝতে পারে; ভাল প্রোগ্রামাররা কোড বুঝতে পারে মানবেরা বুঝতে পারে"।
তাসোস পাপাস্টাইলিয়ানু

2
পছন্দ করুন 'যদি পরীক্ষা সফল হয় -> কোনও পদক্ষেপের প্রয়োজন নেই' এর বিপরীত 'পরীক্ষা সফল না হলে -> ক্রিয়া প্রয়োজন'। আপনি এটি প্রায় 10 টি শব্দ দিয়ে প্যাড করেছেন।
জেরি বি

@ জেরিবি এটি "পরীক্ষার" উপর নির্ভর করে। কখনও কখনও প্রত্যাখ্যান (ভাষাগতভাবে) সোজা হয়, তবে কখনও কখনও তা হয় না এবং বিভ্রান্তির দিকে নিয়ে যায়। এই ক্ষেত্রে, "ফলসটি সত্য হওয়া" বনাম "ফলাফলের সত্যতা না হওয়া সম্পর্কে প্রত্যাখ্যান / বিপরীত সম্পর্কে কথা বলা স্পষ্ট; তবে মুল বক্তব্যটি হ'ল একটি 'খালি' পদক্ষেপ প্রবর্তন করা বা পরিবর্তনশীল নামের অর্থ উল্টানো আরও পরিষ্কার হবে। এটি "ডি মরগান" পরিস্থিতিতে সাধারণত: উদাহরণস্বরূপ if ((missing || corrupt) && !backup) -> skip -> else do stuffতুলনায় অনেক পরিষ্কার (+ বিভিন্ন সূচিত উদ্দেশ্য)if ((!missing && !corrupt) || backup) -> do stuff
তাসোস পাপাস্টাইলিয়ানু

1
@TasosPapastylianou আপনি লিখতে পারেন if(!((missing || corrupt) && !backup)) -> do stuffঅথবা তার থেকে ভাল if((aviable && valid) || backup) -> do stuff। (তবে প্রকৃত উদাহরণে অবশ্যই আপনার অবশ্যই ব্যাকআপটি ব্যবহারের আগে বৈধ কিনা তা পরীক্ষা করে দেখতে হবে)
12431234123412341234123

2
@ টাসোসপ্যাপাস্টাইলিয়ানু যেখানে আমি বললাম তাতে দ্বিগুণ নেতিবাচকতা কোথায়? অবশ্যই, আপনি যদি ভেরিয়েবলের নাম হিসাবে নিরবিচ্ছিন্নভাবে ব্যবহার করে থাকেন তবে আপনার একটি স্পষ্ট পয়েন্ট থাকবে। যদিও যখন আপনি ভালো মিশ্র বুলিয়ান অপারেটরদের আসে, এটা হতে পারে ভালো হতে ব্যবহার করার জন্য অস্থায়ী ভেরিয়েবল আছে if: file_ok = !missing && !corrupt; if(file_ok || backup) do_stuff();যা আমি ব্যক্তিগতভাবে মনে এটা এমনকি পরিষ্কার করে তোলে।
বাল্ড্রিক

23

অন্য সব সমান হওয়া, ব্রিভিটি পছন্দ করুন।

আপনি যা লেখেন না, তা পড়তে ও বুঝতে কারও দরকার নেই।

সুস্পষ্ট হওয়া কার্যকর হতে পারে, কেবল তখনই যদি এটি অযৌক্তিক ভার্বোসটি ছাড়াই স্পষ্ট করে তোলে যে আপনি যা লিখেছেন তা হ'ল আপনি যা লিখতে চেয়েছিলেন তা সত্য।


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

এছাড়াও, যদি আপনি সরাসরি-শাখা থেকে বেরিয়ে আসেন তবে অন্য কোনও শাখা লেখা এড়ানো উচিত।

এক্সপ্লোসিটিস-এর একটি দরকারী অ্যাপ্লিকেশনটি আপনি যখনই স্যুইচ-কেসগুলির মধ্যে পড়েছেন তখন কোনও মন্তব্য দেবেন // FALLTHRUএবং যেখানে আপনার খালি বিবৃতি প্রয়োজন সেখানে একটি মন্তব্য বা একটি খালি ব্লক ব্যবহার করবেন for(a;b;c) /**/;


7
// FALLTHRUউঘ, স্ক্রিমিং ক্যাপগুলিতে বা txtspk সংক্ষিপ্তসার সহ নয়। অন্যথায়, আমি একমত এবং এই অনুশীলনটি নিজেই অনুসরণ করি।
কোডি গ্রে

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

1
@ ওয়াসনাম: আমি কেবল আমার পরীক্ষা করে দেখেছি vimএবং এটির কোনও প্রকারের স্বীকৃতি নেই FALLTHRU। এবং আমি মনে করি, সঙ্গত কারণেই: TODOএবং FIXMEমন্তব্যগুলি এমন মন্তব্যগুলি যা গ্রেপ্তযোগ্য হওয়া দরকার কারণ আপনি নিজের কোডে এবং আপনার অবস্থানটি git grepকোথায় রয়েছে সে সম্পর্কে আপনার জানা থাকা ত্রুটিগুলি জিজ্ঞাসা করতে সক্ষম হতে চান । একটি পতনশীলতা একটি ত্রুটি নয়, এবং এটির জন্য গ্রেপ করার কোনও কারণ নেই, যা এখনও হয়।
মাস্টার

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

1
@ মাস্টার - এই চিৎকারটি আপনার পক্ষে মতামত হিসাবে ভাল ধারণা নয় । অন্য মানুষের মতামত পৃথক। এবং শুধুমাত্র আপনার ভিএম এর কনফিগারেশনটি স্বীকৃতি FALLTHRUদেয় না তার অর্থ এই নয় যে অন্যান্য ব্যক্তিরা ভিমকে এটির জন্য কনফিগার করেনি ।
ডেভিড হামেন

6

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

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


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

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

ব্যক্তিগত শৈলী: আমি কোন ধনুর্বন্ধনী স্টাইল ব্যবহার করি না কেন (Allman, 1TB, ...), আমি সর্বদা ধনুর্বন্ধনী ব্যবহার করি।
ডেভিড হামেন

জটিল শর্তসাপেক্ষ বা আপনি যেগুলি বোঝা মুশকিল বলে মনে করছেন প্রায়শই তাদের নিজস্ব পদ্ধতি / ফাংশনগুলিতে পুনরায় ফ্যাক্টর করে সমাধান করা যেতে পারে। এরকম কিছু if(hasWriteAccess(user,file))নীচে জটিল হতে পারে তবে এক নজরে আপনি ঠিক কী ফলাফলটি হওয়া উচিত তা জানেন। এমনকি যদি এটি কেবল কয়েকটি শর্ত থাকে, উদাহরণস্বরূপ if(user.hasPermission() && !file.isLocked())একটি উপযুক্ত নাম সহ একটি মেথড কল পয়েন্টটি পেয়ে যায়, তাই নেতিবাচক কোনও ইস্যুতে কম যায়।
ক্রিস স্নাইডার

একমত। তারপরে আবার, যখনই সম্ভব আমি রিফ্যাক্টরিংয়ের একটি বড় অনুরাগ :)
ল্যাঞ্জক্রিউ

5

সুস্পষ্ট elseব্লক

আমি সমস্ত বিবৃতি coveringেকে একটি কম্বল স্টেটমেন্ট হিসাবে এটির সাথে একমত নই ifতবে elseঅভ্যাসের বাইরে কোনও ব্লক যুক্ত করা ভাল জিনিস হ'ল এমন সময় রয়েছে।

ifআমার মতে একটি বিবৃতি আসলে দুটি স্বতন্ত্র ফাংশন coversেকে রাখে।

আমাদের যদি কিছু করার কথা হয় তবে তা এখানে করুন।

এই মত স্টাফ স্পষ্টত একটি অংশ প্রয়োজন হয় নাelse

    if (customer.hasCataracts()) {
        appointmentSuggestions.add(new CataractAppointment(customer));
    }
    if (customer.isDiabetic()) {
        customer.assignNurse(DiabeticNurses.pickBestFor(customer));
    }

এবং কিছু ক্ষেত্রে একটি elseবিভ্রান্ত হতে পারে যোগ করার জন্য জোর দেওয়া ।

    if (k > n) {
        return BigInteger.ZERO;
    }
    if (k <= 0 || k == n) {
        return BigInteger.ONE;
    }

হয় না হিসাবে একই

    if (k > n) {
        return BigInteger.ZERO;
    } else {
        if (k <= 0 || k == n) {
            return BigInteger.ONE;
        }
    }

যদিও এটি কার্যত একই রকম। ifখালি দিয়ে প্রথম লেখা elseআপনাকে দ্বিতীয় ফলাফলের দিকে নিয়ে যেতে পারে যা অহেতুক কুৎসিত।

আমরা যদি কোনও নির্দিষ্ট রাষ্ট্রের জন্য যাচাই করে নিই তবে প্রায়শই elseআপনাকে খালিটি যুক্ত করা ভাল ধারণাটি আপনাকে সেই ঘটনাটি আবরণ করার জন্য মনে করিয়ে দেবে

        // Count wins/losses.
        if (doors[firstChoice] == Prize.Car) {
            // We would have won without switching!
            winWhenNotSwitched += 1;
        } else {
            // We win if we switched to the car!
            if (doors[secondChoice] == Prize.Car) {
                // We picked right!
                winWhenSwitched += 1;
            } else {
                // Bad choice.
                lost += 1;
            }
        }

মনে রাখবেন যে আপনি যখন নতুন কোড লিখছেন তখনই এই নিয়মগুলি প্রযোজ্য । আইএমএইচও খালি elseক্লজগুলি চেকিনের আগে মুছে ফেলা উচিত।


জন্য পরীক্ষা, জন্য trueনয়false

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

যদিও কোড পছন্দ

    if(!customer.canBuyAlcohol()) {
        // ...
    }

পাঠকের কাছে ব্যঙ্গ করছে, তবে তা তৈরি করছে

    if(customer.canBuyAlcohol()) {
        // Do nothing.
    } else {
        // ...
    }

খারাপ না হলেও কমপক্ষে খারাপ।

আমি বহু বছর আগে বিসিপিএলে কোড করেছি এবং সেই ভাষায় একটি IFধারা এবং একটি UNLESSধারা রয়েছে যাতে আপনি আরও সহজেই কোডিং করতে পারেন:

    unless(customer.canBuyAlcohol()) {
        // ...
    }

যা উল্লেখযোগ্যভাবে ভাল, তবে এখনও নিখুঁত নয়।


আমার ব্যক্তিগত প্রক্রিয়া

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

  if (returnVal == JFileChooser.APPROVE_OPTION) {
    handleFileChosen();
  } else {
    // TODO: Handle case where they pressed Cancel.
  }

আমি দেখতে পাই যে সাধারণত আমি elseআমার কোডটিতে খুব কমই ব্যবহার করি কারণ এটি প্রায়শই কোডের গন্ধকে নির্দেশ করতে পারে।


"খালি" ব্লক তোমার হ্যান্ডলিং মত স্ট্যান্ডার্ড কোড stubbing আউট সার্চ যখন thngs বাস্তবায়ন ...
Deduplicator

unlessব্লক একটি ভাল পরামর্শ, এবং কষ্টসহকারে BCPL সীমাবদ্ধ।
tchrist

@ টবিস্পাইট উফস এটি একরকমভাবে আমার দৃষ্টি এড়িয়ে গেল যে আমি যা লিখেছি ...তা আসলে return। (বস্তুত, সঙ্গে k=-1, n=-2প্রথম আগমন নেওয়া হয় কিন্তু এই মূলত তর্ক করা হয়।)
ডেভিড Richerby

আধুনিক পার্ল আছে ifএবং unless। আরও কী, এটি বিবৃতি দেওয়ার পরে এগুলিও মঞ্জুরি দেয়, যাতে আপনি বলতে পারেন print "Hello world!" if $born;বা print "Hello world!" unless $dead;এবং উভয়ই আপনার মতামত ঠিক তাই করবে।
একটি সিএনএন

1

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

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

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

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

নেতিবাচক যুক্তি কম পাঠযোগ্য হতে পারে, যদিও এই ধরনের একটি সাধারণ আইএফ বিবৃতিতে তেমন কিছু না।


2
আমি দেখতে পাচ্ছি, তাই এটি এক পর্যায়ে সাধারণ অনুশীলন ছিল
পাতসুয়ান

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

1
"অনেক আগে ... এটা স্বীকার করা হয়েছিল যে নেতিবাচক চেকগুলি কম দক্ষ ছিল।" ওয়েল, তারা হয় যদি না কম্পাইলার সেরা অনুকূল রূপ if !A then B; else Cথেকে if A then C; else B। শর্তের অবহেলা গণনা করা একটি অতিরিক্ত সিপিইউ নির্দেশনা। (যদিও হিসাবে আপনি বলুন, এই হতে করার সম্ভাবনা কম উল্লেখযোগ্যভাবে কম দক্ষ।)
ডেভিড Richerby

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

1

আমি বেশিরভাগ উত্তরের অবস্থানকে দ্বিতীয় করে বলব যে খালি elseব্লকগুলি কার্যত সর্বদা বৈদ্যুতিন কালি এর ক্ষতিকারক বর্জ্য। আপনার যদি এটি করার খুব ভাল কারণ না থাকে তবে এগুলি যুক্ত করবেন না, সেক্ষেত্রে খালি ব্লকটি একেবারেই খালি না হওয়া উচিত, এটি কেন আছে তা ব্যাখ্যা করে একটি মন্তব্য থাকা উচিত।

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

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


0

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


1
আমি শুনেছি আপনি কোনও নিয়োগকর্তার পক্ষে কখনও কাজ করেন নি যারা পিরিয়ড অনুসারে উত্পাদিত এসএলওসি এর উপর ভিত্তি করে আপনার পারফরম্যান্সকে গ্রেড করে ...
একটি সিএনএন

0

এখানে অন্য একটি প্যাটার্ন রয়েছে যা দ্বিতীয় কেসটি পরিচালনা করার বিষয়ে এখনও উল্লেখ করা হয়নি যা খালি যদি-ব্লক করে। এটির সাথে মোকাবিলা করার একটি উপায় যদি ইফ ব্লকে ফিরে আসে। এটার মত:

void foo()
{
    if (condition) return;

    doStuff();
    ...
}

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


0

"সর্বদা অন্য একটি ধারা থাকা উচিত" যুক্তিটি বিবেচনা করার সময় একটি বিষয় রয়েছে যা আমি অন্য কোনও উত্তরে দেখিনি: এটি কার্যকরী প্রোগ্রামিং শৈলীতে অর্থবোধ করতে পারে। প্রকার, রকম.

ক্রিয়ামূলক প্রোগ্রামিং স্টাইলে আপনি বিবৃতি না দিয়ে অভিব্যক্তিগুলিতে ডিল করেন। সুতরাং প্রতিটি কোড ব্লকের একটি রিটার্ন মান থাকে - একটি if-then-elseঅভিব্যক্তি সহ । এটি, তবে, একটি খালি elseব্লক আটকে দেবে । আমি আপনার একটি উদাহরণ দিতে দিন:

var even = if (n % 2 == 0) {
  return "even";
} else {
  return "odd";
}

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

var even = (n % 2 == 0) ? "even" : "odd";

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


0

... যদি একটি বিবৃতি অনুসরণ করা উচিত অন্য বিবৃতি অনুসরণ করা উচিত, এটিতে কিছু রাখা আছে কি না।

আমি অসম্মতি if (a) { } else { b(); }হিসেবে পুনরায় লিখতে হবে if (!a) { b(); }এবং if (a) { b(); } else { }হিসেবে পুনরায় লিখতে হবে if (a) { b(); }

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

দ্বিতীয়ত, মিথ্যা নয় বরং সত্য মানগুলির জন্য পরীক্ষা করা ভাল। তার মানে হল যে একটি 'ডোরক্লোজড' ভেরিয়েবলের পরিবর্তে 'ডোরক্লোজড' ভেরিয়েবল পরীক্ষা করা ভাল

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

আমি আমার প্রবৃত্তি সম্পর্কে সন্দেহ পোষণ করি।

নিজেকে প্রশ্ন করা চালিয়ে নেওয়া ভাল।

এটা কি ভাল / খারাপ / "কিছু যায় আসে না" অনুশীলন?

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

এটা কি সাধারণ অনুশীলন?

মনে নেই কখনই ফাঁকা শাখা দেখেছি। যদিও আমি প্রত্যাখ্যান এড়ানোর জন্য লোকেরা সম্পত্তি যুক্ত করে দেখছি।


0

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

তবে এটি কোনওভাবে উত্তর না দিয়ে বর্ধিত মন্তব্য comment

যখন এটি বিবৃত হয়

দ্বিতীয়ত, মিথ্যা নয় বরং সত্য মানগুলির জন্য পরীক্ষা করা ভাল। তার মানে হল যে একটি 'ডোরক্লোজড' ভেরিয়েবলের পরিবর্তে 'ডোরক্লোজড' ভেরিয়েবল পরীক্ষা করা ভাল

তার যুক্তি হ'ল কোডটি কী করছে তা স্পষ্ট করে দেয়।

আমার দৃষ্টিকোণ থেকে ধারণাটি এখানে নেওয়া হচ্ছে যে দরজা রাজ্যটি একটি বাইনারি রাষ্ট্র যখন বাস্তবে এটি অন্তত একটি বার্ষিক রাষ্ট্র হয়:

  1. দরজাটি খোলা.
  2. দরজা পুরোপুরি খোলা বা পুরোপুরি বন্ধ নয়।
  3. দরজাটা বন্ধ.

সুতরাং যেখানে একটি একক, বাইনারি ডিজিটাল সেন্সরটি অবস্থিত তার উপর নির্ভর করে আপনি কেবল দুটি ধারণার মধ্যে একটি আবিষ্কার করতে পারেন:

  1. সেন্সরটি যদি দরজার খোলার দিকে থাকে: দরজা হয় খোলা হয় না খোলা থাকে
  2. সেন্সরটি যদি দরজার বন্ধ দিকে থাকে: দরজা হয় বন্ধ থাকে না বন্ধ হয় না।

এবং আপনি একটি বাইনারি অবহেলা ব্যবহারের মাধ্যমে এই ধারণাগুলি বিনিময় করতে পারবেন না। সুতরাং doorClosedএবং !doorOpenedসম্ভবত সমার্থক নয় এবং তারা সমার্থক বলে ভান করার যে কোনও প্রয়াসই ভুল ধারণা যা আসলে বিদ্যমান অবস্থার চেয়ে সিস্টেমের অবস্থার বৃহত্তর জ্ঞানকে ধরে নেয়।

আপনার প্রশ্নে ফিরে আসার সময় আমি ভেরিয়েজ সমর্থন করব যা ভেরিয়েবল প্রতিনিধিত্ব করে এমন তথ্যের উত্সের সাথে মেলে। তথ্য দরজা বন্ধ দিক থেকে প্রাপ্ত করা হয় তাই যদি তারপর সঙ্গে যেতে doorClosedপারেন ইত্যাদি এই ব্যবহার পরোক্ষভাবে পারে doorClosedবা !doorClosedবিভিন্ন বিবৃতিগুলির মতো প্রয়োজনীয় অস্বীকৃতি ব্যবহারের সঙ্গে সম্ভাব্য বিভ্রান্তির ফলে প্রয়োজন হয়। তবে এটি যা করে না তা হ'ল সুস্পষ্টভাবে সিস্টেমের অবস্থার উপর অনুমানগুলি প্রচার করা।


আমি যে কাজটি করি তার জন্য আলোচনার উদ্দেশ্যে, সিস্টেমের অবস্থা সম্পর্কে আমার যে পরিমাণ তথ্য পাওয়া যায় তা সামগ্রিক সিস্টেমের নিজস্ব প্রয়োজনীয় কার্যকারিতার উপর নির্ভর করে।

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

প্রথমটির উদাহরণ হ'ল মাইক্রোওয়েভ ওভেনের দরজা। আপনি দরজাটি বন্ধ হওয়া বা বন্ধ না হওয়ার ভিত্তিতে চুলার অপারেশন সক্ষম করুন। দরজাটি কতটা উন্মুক্ত তা আপনার মাথাব্যথা নেই।

দ্বিতীয়টির উদাহরণ হ'ল একটি সাধারণ মোটর চালিত অ্যাকিউউটর। যখন অ্যাকিউউটর সম্পূর্ণরূপে বাইরে চলে যায় তখন আপনি মোটরটিকে চালিত করতে বাধা দেন। এবং যখন অ্যাকিউউটর সম্পূর্ণরূপে প্রবেশ করবে তখন আপনি বিপরীতে মোটর চালনা আটকাবেন।

মৌলিকভাবে সেন্সরগুলির সংখ্যা এবং ধরণের সেন্সরগুলির প্রয়োজনীয় কার্যকারিতা অর্জনের জন্য প্রয়োজনীয় বিশ্লেষণের বিপরীতে সেন্সরগুলির ব্যয় বিশ্লেষণ চালিয়ে নেমে আসে।


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

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

-1

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

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

অন্য কোথাও উল্লিখিত হিসাবে, অন্য ব্লকটি থাকা খুব কার্যকর যে আপনি স্পষ্টভাবে অন্য কোনও ক্ষেত্রে কিছু না ঘটতে চান তা দেখাতে কার্যকর is প্রচুর ক্রিয়ামূলক প্রোগ্রামিং করার পরে (যেখানে অন্যটি প্রয়োজন হয়), আমি শিখেছি যে আপনি যখন লেখেন তখন সর্বদা অন্যটি বিবেচনা করা উচিত, যদিও @ ওल्डকর্মডিজিয়ন উল্লেখ করেছেন যে সেখানে দুটি পৃথক ব্যবহারের ঘটনা রয়েছে। একজনের আর একটি থাকা উচিত, একজনের উচিত নয়। দুর্ভাগ্যক্রমে এটি এমন কিছু নয় যা আপনি সর্বদা এক নজরে বলতে পারেন, একটি রেখার সাথে একা থাকুন, তাই এই মতবাদী 'সর্বদা অন্য কোনও ব্লক রাখুন'।

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

static var cached = null

func getCached() {
    if !cached {
        cached = (some calculation, etc)
    }

    return cached
}

যদি আসল (মানসিক / ইংরাজী) যুক্তি একটি নেতিবাচক জড়িত, তাই যদি বিবৃতি দেওয়া উচিত।

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