একক বিবৃতি যদি ব্লক - বন্ধনী বা না? [বন্ধ]


59

কোনটি আরও ভাল / আরও সাধারণভাবে গৃহীত হয়?

এই:

if(condition)
{
  statement;
}

বা:

if(condition)
  statement;

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


2
তবে আপনার প্রারম্ভিক বন্ধনীটি ভুল অবস্থানে রয়েছে। এটাই নিশ্চিত।
খ্রিস্টান মান

অনেক ভাষায়, একটি ব্লক হ'ল একটি বিবৃতি, সুতরাং, সিন্টেক্সিকভাবে, এটি সর্বদা যদি হয় (এক্সপ্রেশন) বিবৃতি
ইনগো

2
যেহেতু আপনি কোনও ভাষা নির্দিষ্ট করেন নি ... কী হবে statement if condition;?
ডেভ শেরোহমান

@ ক্রিশ্চিয়ান - ভাল। এ থেকে অন্য প্রশ্নটি আলাদা হবে, না?
জাঞ্জামিন্ডারসন

@ ইঙ্গো - ভাল পয়েন্ট
জাঞ্জামিন্ডারসন

উত্তর:


131

প্রথমটি আরও ভাল কারণ দ্বিতীয়টি ত্রুটি-প্রবণ। উদাহরণস্বরূপ, ধরুন আপনি কিছু ডিবাগ করার জন্য কোডটি অস্থায়ীভাবে মন্তব্য করছেন:

if(condition) 
//      statement;
otherStatement;

বা তাড়াহুড়োয় কোড যুক্ত করুন:

if(condition) 
    statement;
    otherStatement;

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

if(condition) statement;

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


35
সবকিছুকে এক লাইনে রাখার জন্য ভাল বিষয়।
নিল আইটেন

7
@ আর্টজোমকা: যদি বিবৃতিটি দীর্ঘ হয়, এবং তার নিজস্ব লাইনে যেতে হয় তবে আমি পাঠ্যতার জন্য বন্ধনী ব্যবহার করি। মুল বক্তব্যটি হ'ল আপনি সংক্ষিপ্ততম, কমপক্ষে সিন্ট্যাক্টিক্যালি কোলাহলপূর্ণ কনস্ট্রাক্ট চান যা কোনও মানুষের কাছে তা যাচাই-বাছাইয়ের পরিবর্তে দ্রুত এটি পড়ছে তা স্পষ্ট নয়।
dsimcha

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

10
@ টিএমএন হোয়াইটস্পেস বিনামূল্যে, মনিটর বড় এবং আপনার মস্তিষ্ক সেই আকারটি সনাক্ত করতে শেখে যা আপনাকে কোডটি বিশ্লেষণ করতে সহায়তা করে।
মার্ফ

5
@ মুরফ: হোয়াইটস্পেস বিনামূল্যে? আমি অবশ্যই এটি মিস করেছি আমার পর্দায়, এটি সত্যিই অনেক বেশি জায়গা নেয়। আসলে 50% এরও বেশি। যা আমার বইয়ের একটি বড় অপচয় হিসাবে মনে হচ্ছে। ব্যক্তিগতভাবে, আমি কোডে প্রতি বর্গ সেন্টিমিটার সামগ্রী সর্বাধিক করতে চাই।
কনরাড রুডল্ফ

44

আমি সবসময় বন্ধনী ব্যবহার করি কেবল নিরাপদ থাকতে।

আপনি যখন এটি লিখবেন ঠিক আছে, তবে আপনি জানেন যে ভবিষ্যতে কেউ আসবে এবং চারপাশে বন্ধনী না রেখে অন্য একটি বিবৃতি statementোকান।


20
মানুষ কি সত্যিই এটি ঘটতে দেখেছে? আমি মনে করি না যে আমি এটি 10 ​​বছরের প্রোগ্রামিংয়ে কখনও দেখেছি। সম্ভবত আমি খুব আশ্রয় পেয়েছি। :)
ডেভিড

9
আমি না বলতে পছন্দ করি তবে দুঃখের সাথে আমি এটি দেখেছি।
নিল আইটেন

13
আপনি সর্বদা বন্ধনী ব্যবহার করেন যাতে আপনি বন্ধনী ব্যবহার করতে কখনই ভুলে যান না - এটি এতটা সহজ।
মার্ফ

12
@ মুরফ থেকে +1 কারও আশেপাশে না থাকাকালীন - এবং পার্কিংয়ের জায়গায় আমি আমার টার্ন সিগন্যাল ব্যবহার করি!
ড্যান রে

7
শাখা-ট্রাঙ্ক থেকে ট্রাঙ্কে বা শাখাগুলিতে জুড়ে যাওয়ার সময় ত্রুটিগুলি রোধে সহায়তা করার জন্য এটি ভাল অনুশীলন।
জেবিআরওয়িলকিনসন

27

আমি যেখানে সম্ভব সেখানে ধনুর্বন্ধনী ছাড়া সংস্করণ পছন্দ করি

নীচের ব্যাখ্যাটি দীর্ঘস্থায়ী। আমার সাথে সহ্য করুন। আমি আমার এই স্টাইলটি পছন্দ করার জন্য একটি বাধ্যতামূলক কারণ দেব। আমি কেন আমার মনে হয় যে সাধারণ পাল্টা যুক্তি ধরে রাখে না তাও আমি ব্যাখ্যা করব।

(কাছাকাছি-) খালি লাইনগুলি অপচয় হয়

এর কারণ হ'ল সমাপ্তি বন্ধনীটির জন্য কোডের একটি অতিরিক্ত লাইন প্রয়োজন - এবং তাই শৈলীর উপর নির্ভর করে উদ্বোধনী ব্রেসটি হয়। 1

এটা কি বড় কথা? অতিমাত্রায়, না। সর্বোপরি, বেশিরভাগ লোকেরা যুক্তিযুক্তভাবে কিছুটা স্বতন্ত্র ব্লকগুলি পৃথক করতে তাদের কোডে খালি লাইন রাখেন, যা পঠনযোগ্যতার ব্যাপক উন্নতি করে।

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

এটি একটি মৌলিক সমস্যা: একবার আপনি যদি আপনার স্ক্রিনে পুরো ব্লকটি আর দেখতে না পান তবে বুঝতে পারা জটিল হয়ে যায়।

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

তেমনি, লাইনগুলি যা কেবল একটি ধনুর্বন্ধকে ধারণ করে, এবং যা অর্থায়ন করা যায়, হওয়া উচিত। একটি একক-বিবৃতি ব্লক যা ধনুর্বন্ধনী দ্বারা সীমিত হয় এক থেকে দুটি লাইনের অপচয় করে। প্রতিটি স্ক্রিনের উচ্চতায় কেবল 50-ইশ লাইন রয়েছে, এটি লক্ষণীয়।

বন্ধনী বন্ধনী সম্ভবত কোনও ক্ষতি করতে পারে না

ব্রেসগুলি বাদ দেওয়ার বিরুদ্ধে কেবল একটি যুক্তি রয়েছে: যে পরে কোনও ব্যক্তি প্রশ্নে ব্লকটিতে অন্য বিবৃতি যুক্ত করবে এবং ধনুর্বন্ধনী যুক্ত করতে ভুলে যাবে, এইভাবে অজান্তেই কোডটির শব্দার্থবিজ্ঞান পরিবর্তন করে।

এটি সত্যিই একটি বড় চুক্তি হবে।

তবে আমার অভিজ্ঞতাতে তা হয় না। আমি একজন ঝালর প্রোগ্রামার; এবং তবুও, আমার দশকের প্রোগ্রামিংয়ের অভিজ্ঞতায়, আমি সত্যই বলতে পারি যে আমি সিঙ্গেলটন ব্লকে অতিরিক্ত বিবৃতি যুক্ত করার সময় একবার ধনুর্বন্ধনী যুক্ত করতে ভুলে যাইনি।

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

এখন, আমি বলছি না যে বন্ধনী বাদ দেওয়া ভুলের কারণ হয় না। আমি যা বলছি তা হ'ল আমাদের কাছে কোনও উপায় বা অন্য কোনও প্রমাণ নেই। আমরা কেবল জানি না যে এটির ক্ষতি হয়।

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


1 ধনুর্বন্ধনী সহ - সমস্ত কিছু একই লাইনে রেখে এই সমস্যাটি সমাধান করা হয়:

if (condition)
{ do_something(); }

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


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

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

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

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

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

19

আমি দ্বিতীয় সঙ্গে যেতে। এটি বেশি সংক্ষিপ্ত এবং কম ভার্বোস।

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


11
একেবারে! সর্বোপরি, কোডটি লেখা যদি শক্ত হয় তবে এটি বজায় রাখাও শক্ত হওয়া উচিত! ;-)
স্টিভেন এ লো।

3
@ স্টিভেন আপনি যদি ধনুর্বন্ধনী ভুলে যান তবে আমার মনে হয় এখানে আরও কিছু সমস্যা আছে।
TheLQ

আরও সাফল্য == কম
ভার্বোজ

5
@ এসএনআরফাস: কিছুটা ব্যঙ্গাত্মক, যেহেতু অতিরিক্ত 2 টি অক্ষর তুচ্ছ ওভারহেড এবং খুব সাধারণ রক্ষণাবেক্ষণের ভুলটি রোধ করে। আপনার মাইলেজ মে মেশিনের পরিবর্তন হতে পারে ;-)
স্টিভেন এ। লো

1
আমার কাছে ইনডেন্টিংটি পরিষ্কার করছে যে কী চলছে going প্রথম ফর্মটি অতিরিক্ত পর্দার স্থান পোড়ায় এবং এটি আমার কাছে নেতিবাচক।
লরেন পেচেল

16

আমি নিম্নলিখিতটি ব্যবহার করব (hereকমত্য এখানে):

if (condition) {
    any_number_of_statements;
}

এছাড়াও সম্ভব:

if(condition) single_compact_statement;

বিশেষত সি / সি ++ - তে ভালো ভাষার মতো খুব ভাল নয়:

if(condition) 
    single_compact_statement;

( পাইথনে এখানে কোনও পছন্দ নেই ;-)


ইন পার্ল , আপনি ব্যবহার করতে চাই:

$C = $A**3 if $A != $B;

অথবা

$C = $A**3 unless $A == $B;

(এটি সিউডোকোড নয় ;-)


1
আমার চিন্তা ঠিক. ifধারাটির পরে যদি একক বক্তব্য একক লাইনে ভাল দেখায় , আমি ধনুর্বন্ধনী ব্যবহার করি না। অন্য ifযে কোনও বিবৃতিতে (বা কোনও বিবৃতি যা একাধিক লাইন ব্যবহার করে) এর জন্য আমি সর্বদা ধনুর্বন্ধনী ব্যবহার করি। বিশেষত, যদি একটি elseধারা থাকে তবে প্রতিটি ক্ষেত্রে সর্বদা ব্রেস থাকে।
ইজাল্ড

9
আমি এর আগে কাউকে কখনও সিডোকোড দিয়ে পার্লকে বিভ্রান্ত করতে দেখিনি। এলোমেলো অক্ষর হ্যাঁ, সিউডোকোড - না।
জো ডি

3
আমি আশ্চর্য হয়েছি যে কেউ যদি পার্ল ইন্টারপ্রেটারকে কেবল / ডেভ / এলোমেলোভাবে ঝুঁকি দিয়ে পার্ল প্রোগ্রাম জেনারেটর তৈরি করে থাকে ...
খ্রিস্টান মান Mann

আমি এখানে রুবির যোগাযোগ পছন্দ করি। এটি পার্ল স্টাইলের একক-লাইন <statement> if <condition>বা মাল্টলাইন ব্লক শৈলী if <condition>/ <do something>/ end(রুবি বন্ধনীগুলি এড়ায়, তাই এখানে প্রারম্ভিক বন্ধনী দ্বারা আবদ্ধ হয় ifএবং শেষ বন্ধনীটি একটি আক্ষরিক দ্বারা প্রতিস্থাপিত হয় end) সরবরাহ করে। এমনকি যদি বিবৃতিটি অদ্ভুত একাধিক-তবে-সত্যই-কেবল-একক-লাইন অফার করে না।
বেন লি

ওয়ান-লাইনার বেশিরভাগ ডিবাগারের সাথে কাজ করে না ('যদি' ধারাটির বিষয়বস্তু কার্যকর হতে চলেছে তখন ব্রেক বিরতি দেওয়া সম্ভব নয়)।
পিটার মর্টেনসেন

11

আমি ধনুর্বন্ধনী পদ্ধতিটি ব্যবহার করি - উপরোক্ত কারণে আরও একটি কারণে।

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

সুতরাং আমি ধনুর্বন্ধনী সঙ্গে - তাদের নিজস্ব লাইনে যান। স্তরগুলিকে সেভাবে চিহ্নিত করা সহজ। হ্যাঁ, এটি উল্লম্ব স্ক্রিন রিয়েল এস্টেট নষ্ট করে এবং এটি একটি আসল ক্ষতি হয়। ভারসাম্য বজায় থাকলেও, আমি মনে করি এটি মূল্যবান।


10

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


3
একদম ঠিক! এটা আমাদের দোষ নয় যে সে সিনট্যাক্সটি জানে না।
kirk.burleson

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

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

8

আমাদের এখানে এই যুক্তি একাধিকবার হয়েছে এবং সামগ্রিক sensকমত্য সর্বদা ব্রেস ব্যবহার করা। মূল কারণগুলি পঠনযোগ্যতা / রক্ষণাবেক্ষণযোগ্যতা সম্পর্কে।

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

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


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

পাইথন যেহেতু সীমানার পরিবর্তে ইন্ডেন্টেশন ব্যবহার করে তারা জড়িত এটি বৈধ তুলনা নয়।
মার্ফ

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

@ শিমোনেক: সুতরাং মূলত আপনার পর্যবেক্ষণগুলি আমার এই দৃ support় সমর্থনকে সমর্থন করে যে এই সমস্যাটি অনর্থক? যাইহোক, ব্যক্তিগত পর্যবেক্ষণগুলি উপাখ্যানগুলি, তারা অভিজ্ঞতাগত প্রমাণ হিসাবে গণনা করে না।
কনরাড রুডল্ফ

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

7

আমি প্রথম বাক্য গঠনটি ব্যবহার করি, প্রায় ব্যতিক্রম ছাড়াই। কারণ এটি ভুল ব্যাখ্যা করা যায় না

"আমাকে ভাববেন না" কেবল ব্যবহারকারী-ইন্টারফেসের জন্য প্রযোজ্য নয়, আপনি সব ;-)


4
আমি এটি করতাম, তবে প্রোগ্রামারদের ভাষাটি জানা দরকার এবং তাদের চিন্তা করা উচিত বলে আমি এই যুক্তিতে জয়ী হয়েছি।
kirk.burleson

2
আমি এটিকে সাধারণ সৌজন্য বিবেচনা করি ... আমার ভবিষ্যতের স্বার্থে।
স্টিভেন এ লো।

5

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

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

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

if (condition) {
    statement;
} // stupid extra brace looks ugly

তারপর

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

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


আপনি যদি ম্যাক্রোগুলি লিখতে চলেছেন তবে সেগুলি কোডের যে কোনও অংশে canোকানো যায় না তা নিশ্চিত করার জন্য আপনার সেগুলি লিখতে হবে।
কোভর

4

আমি ধনুর্বন্ধনী (দ্বিতীয় রূপ) ছাড়াই দ্বি-লাইনের সংস্করণ ব্যবহার করি, তবে স্থান বাঁচাতে নয়।

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

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

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

নীচে কয়েকটি উদাহরণ দেওয়া আছে যা দেখায় যে আমি কীভাবে ifবিবৃতিটির এই ফর্মটি ব্যবহার করি ।

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

3

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

একক লাইন কোডের চারপাশের ধনুর্বন্ধনীগুলির "কৌতুক" অতিরিক্ত কাজের চেয়ে কম ক্ষতিকারক যা ডিবাগিং এবং / অথবা কোড যুক্ত করার ক্ষেত্রে সম্ভাব্য।


1
আমি কখনও কখনও কাউকে ত্রুটি করতে বলে দেখিনি।
kirk.burleson

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

2

ব্যক্তিগতভাবে আমি বন্ধনী নিয়ে যাই।

কেন?

ভাল কেউ যদি আসে এবং যদি বিবৃতিতে কোড যুক্ত করা দরকার তবে এটি সুযোগটি যেখানে 100% তা পরিষ্কার।

এটি ifব্লকের মধ্যে কতগুলি বক্তব্য রয়েছে তা নির্ধারণ করে স্টেটমেন্টগুলির ফর্ম্যাটটিকে সুসংগত রাখে ।

যাইহোক, যদি প্রকল্পের স্টাইলটি বাইরে যেতে হয়, তবে এটি আটকে দিন।


1

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

if (x==5) Console.WriteLine("It's a five!");

অনুমান করুন যে কেউ বক্রতার অনুরাগী নয়।
জনএফএক্স

2
পঠনযোগ্যতার স্বার্থে ব্রেভিটি? একেবারে না. এটি কোড, কোনও গল্ফের প্রতিযোগিতা নয়।
জোশ কে

3
আমি মনে করি পাঠ্যতা ব্যক্তিগতভাবে ব্যক্তিগতভাবে ব্রিভের এক দুর্দান্ত কারণ। যাই হোক না কেন: হোয়াইট-স্পেস আমার কোড-গল্ফ রুলবুকে গণনা করে না।
জনএফএক্স

এর সাথে একটি সমস্যা হ'ল এটি নিজেকে আপত্তিজনকভাবে ধার দেয়
কনরাড ফ্রিক্স

2
তাহলে এটিকে গালি দিবেন না। আমি এটিকে কোডিং মান হিসাবে ব্যবহার করার কথা বলছি না। অনেক সময়ই ঘটে থাকে যখন আপনি যখন একটি সংক্ষিপ্ত শর্তসাপেক্ষে একটি ছোট সংক্ষিপ্ত বিবৃতি অনুসরণ করেন এবং এটি ভালভাবে কাজ করে। উদাহরণস্বরূপ একটি if (assert) log.write ("দৃsert়তা ব্যর্থ হয়েছে");
জনএফএক্স

1

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

If (cond) { statement; }

আকর্ষণীয়, আমি আসলে কোডটি দেখতে পাচ্ছি না তবে আমি এটি পছন্দ করি।
থমাস এডিং

0

আমি সাধারণত ধনুর্বন্ধনী ব্যবহার করি, তবে এমন কিছু ক্ষেত্রে রয়েছে যা আমি করি না।

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

আমার কাছে এটি কেবল সেখানে যুক্ত করা বোকামি হবে। এর পরে যদি কেউ বিবৃতি যোগ করে তবে returnআমাদের স্কোপিং ইস্যুগুলির চেয়ে বড় সমস্যা রয়েছে।


আপনি ঠিক তত সহজেই ব্যবহার করতে পারেনreturn (obj != null) ? obj : "Error";
জোশ কে

@ জোশ, সম্পাদনা দেখুন
নোট

সেক্ষেত্রে আমি এরকম কিছু ব্যবহার করব Object returnObj = defaultObj; /* Three else-if's to change it to obj1/2/3 */ return returnObj;
জোশ কে

@Josh মাধ্যমে পড়ুন stackoverflow.com/questions/36707/... । প্রথম উত্তরের প্রথম মন্তব্য, "যদিও একাধিক প্রস্থান পয়েন্টটি হাতছাড়া হয়ে যেতে পারে, তবে আমি অবশ্যই আপনার সম্পূর্ণ ফাংশনটি আইএফ ব্লকে রাখার চেয়ে ভাল মনে করি ।"
স্বরে নোট করুন -

0

আইডিইতে কোড বিন্যাস উপলব্ধ থাকলে আমি ধনুর্বন্ধনী ব্যবহার করি না।

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

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