যদি বা লুপটি একটি একক লাইনের জন্য ধনুর্বন্ধনী ব্যবহারের উদ্দেশ্য (যেমন {}) কী?

320

আমি আমার সি ++ প্রভাষকের কয়েকটি লেকচার নোট পড়ছি এবং তিনি নিম্নলিখিত লিখেছিলেন:

  1. ইনডেন্টেশন // ঠিক আছে ব্যবহার করুন
  2. অপারেটরের অগ্রাধিকারের উপর কখনই নির্ভর করবেন না - সর্বদা বন্ধনী ব্যবহার করুন // ঠিক আছে
  3. সর্বদা একটি}} ব্লক ব্যবহার করুন - এমনকি একক লাইনের জন্যও // ঠিক আছে না কেন ???
  4. তুলনা বাম দিকে কনট অবজেক্ট // ঠিক আছে
  5. ভেরিয়েবলগুলির জন্য স্বাক্ষরযুক্ত ব্যবহার করুন যা> = 0 // দুর্দান্ত কৌশল trick
  6. মোছার পরে পয়েন্টারটিকে NULL এ সেট করুন - ডাবল মুছুন সুরক্ষা // খারাপ নয়

তৃতীয় কৌশলটি আমার কাছে পরিষ্কার নয়: আমি একটি লাইনে রেখে কী অর্জন করব { ... }?

উদাহরণস্বরূপ, এই অদ্ভুত কোডটি নিন:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

এবং এর সাথে প্রতিস্থাপন করুন: 

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

1 ম সংস্করণ ব্যবহার করে কি সুবিধা?

c++  c  coding-style  curly-braces  defensive-programming 
— জেএএন
সূত্র
256
পঠনযোগ্যতা এবং রক্ষণাবেক্ষণ 'জে ++' স্টেটমেন্ট ব্লকটি কী সম্পর্কিত তা তাত্ক্ষণিকভাবে সুস্পষ্ট নয় এবং এর পরে কোড যুক্ত করার পরে যদি এটি বিবৃতিটির সাথে যুক্ত হয় না।
— বন এবং গাছ
27
আমাকে সর্বদা বেশ কয়েকটি কারণে এই রেখাগুলির জন্য কোঁকড়া ধনুর্বন্ধনী ব্যবহার করতে বলা হয়েছিল। এটি কোডটি পড়ার জন্য আরও পরিষ্কার করে। এছাড়াও ছয় মাসের সময় অন্য কাউকে আপনার কোড সম্পাদনা করতে হবে যাতে স্পষ্টতা গুরুত্বপূর্ণ এবং ব্রেসগুলির সাথে একটি ত্রুটি হওয়ার সম্ভাবনা কম থাকে। এটি সম্পর্কে প্রযুক্তিগতভাবে আরও সঠিক কিছু নেই, এটি কেবলমাত্র ভাল অনুশীলনের বিষয়। মনে রাখবেন কোনও প্রকল্পে হাজার হাজার এবং কয়েক হাজার লাইনের কোড থাকতে পারে যাতে কোনও নতুন লোক প্লট করতে পারে!
— রসস
30
আমি 6 এর সাথে একমত নই, কারণ এটি দ্বিগুণ মুছে ফেলা এবং লজিক ত্রুটিগুলি সম্ভবত লুকিয়ে রাখবে।
— লুচিয়ান গ্রিগোর
28
# 5 চতুর হতে পারে - এই লুপ বিবেচনা করুন: for (unsigned i = 100; i >= 0; --i)।
— আর্চি
36
বিটিডব্লিউ, (i % 2 == 0)বিপরীতে (2)। আপনি অপারেটর প্রাধান্যের উপর নির্ভর করছেন এবং অর্থটি অবশ্যই ((i % 2) == 0)তার চেয়ে বেশি (i % (2 == 0))। আমি নিয়ম 2 কে "একটি বৈধ অনুভূতি তবে 'সর্বদা' ভুল" হিসাবে শ্রেণিবদ্ধ করব।
— স্টিভ জেসপ

উত্তর:

508

আসুন iআমরা যখন বৃদ্ধি করি তখনও সংশোধন করার চেষ্টা করি j:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

ওহ না! পাইথন থেকে আসা, এটি দেখতে ঠিক আছে তবে বাস্তবে এটি এর সমতুল্য নয়:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

অবশ্যই এটি একটি নির্বোধ ভুল, তবে এটি একটি অভিজ্ঞ প্রোগ্রামারও করতে পারে।

আর একটি খুব ভাল কারণ তা.স্পিওটি.আইএস এর উত্তরে দেখানো হয়েছে ।

তৃতীয়টি যা আমি ভাবতে পারি তা হল নেস্টেড if:

if (cond1)
   if (cond2) 
      doSomething();

এখন ধরে নিন, আপনি এখন doSomethingElse()কখন চান cond1তা পূরণ করতে চান (নতুন বৈশিষ্ট্য)। তাই:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

যা স্পষ্টতই ভুল, কারণ elseঅন্তরের সাথে সহযোগী if।

সম্পাদনা: যেহেতু এটি কিছুটা দৃষ্টি আকর্ষণ করছে, তাই আমি আমার দৃষ্টিভঙ্গি পরিষ্কার করব। আমি যে প্রশ্নের উত্তর দিচ্ছিলাম তা হ'ল:

1 ম সংস্করণ ব্যবহার করে কি সুবিধা?

যা আমি বর্ণনা করেছি। কিছু সুবিধা আছে। তবে, আইএমও, "সর্বদা" নিয়ম সর্বদা প্রয়োগ হয় না। সুতরাং আমি সম্পূর্ণ সমর্থন করি না

সর্বদা একটি}} ব্লক ব্যবহার করুন - এমনকি একক লাইনের জন্যও // ঠিক আছে না কেন ???

আমি বলছি না যে সবসময় একটি {}ব্লক ব্যবহার করুন । যদি এটি একটি সহজ পর্যাপ্ত শর্ত এবং আচরণ থাকে তবে করবেন না। যদি আপনার সন্দেহ হয় যে কেউ পরে এসেছেন এবং কার্যকারিতা যুক্ত করতে আপনার কোড পরিবর্তন করতে পারেন তবে তা করুন।

— লুচিয়ান গ্রিগোর
সূত্র
5
@ সায়েন্স_ ফিকশন: সত্য, তবে আপনি যদি i++ আগে যুক্ত করেন j++তবে উভয় ভেরিয়েবলগুলি ব্যবহার করার পরেও তাদের স্কোপ থাকবে।
— মাইক সিমুর
26
এটি অত্যন্ত যুক্তিসঙ্গত বলে মনে হচ্ছে, তবে সম্পাদকটি আপনাকে নয়, ইন্ডেন্টেশনটি সম্পাদন করে এবং এটিকে i++;এমনভাবে ইনডেন্ট করবে যা অবিলম্বে দেখায় যে এটি লুপটির অংশ নয়। (অতীতে, এটি একটি যুক্তিসঙ্গত যুক্তি হতে পারে, এবং আমি এই জাতীয় সমস্যাগুলি দেখেছি About প্রায় 20 বছর আগে since পরে নয়))
— জেমস কানজে
43
@ জেমস: এটি কোনও "সত্য" নয়, যদিও এটি আপনার কর্মপ্রবাহ। এবং অনেক লোকের কর্মপ্রবাহ, তবে সবার নয়। আমি মনে করি না যে W +SIWYG সম্পাদক (vi / emacs / ভিজ্যুয়াল স্টুডিও) এর ফর্ম্যাটিং নিয়মগুলি প্রয়োগ করে তার পরিবর্তে সি ++ উত্সকে একটি সরল পাঠ্য ফাইল হিসাবে বিবেচনা করার জন্য এটি ত্রুটি। সুতরাং এই বিধিটি আপনার যা প্রয়োজন তার চেয়ে বেশি সম্পাদক-অজগনীয়, তবে লোকে আসলে সি ++ সম্পাদনা করতে যা ব্যবহার করে তা ছাড়াই। সুতরাং "প্রতিরক্ষামূলক"।
— স্টিভ জেসপ
31
@ জামেসকানজে আপনি কি এই ধারণার উপর নির্ভর করছেন যে প্রত্যেকে শক্তিশালী আইডিইতে সর্বদা কাজ করে? সর্বশেষ সিআই লিখেছিলেন ন্যানোতে। এমনকি এটি দেওয়া সত্ত্বেও, আমি প্রথমে আইডিই বন্ধ করার ঝুঁকির মধ্যে একটি হ'ল অটো-ইন্ডেন্টেশন - কারণ আইডিই অসম্পূর্ণ তথ্যের উপর ভিত্তি করে আমার 'ভুলগুলি' সংশোধন করার চেষ্টা করে আমার অ-লিনিয়ার ওয়ার্কফ্লো পথে চলেছে । আইডিই প্রতিটি প্রোগ্রামারের প্রাকৃতিক প্রবাহকে স্বয়ংক্রিয়ভাবে অন্তর্ভুক্ত করতে খুব ভাল হয় না। এই প্রোগ্রামগুলির মধ্যে যারা এই জাতীয় বৈশিষ্ট্যগুলি ব্যবহার করে তাদের স্টাইলটি তাদের আইডিইতে মার্জ করে to যা আপনার পক্ষে কেবল একটি আইডিই ব্যবহার করলে ভাল হয় তবে আপনি যদি অনেকগুলি জুড়ে কাজ করেন তবে তা খুব ভাল।
— রাশিও
10
"এটি একটি নির্বোধ ভুল, তবে এটি একটি অভিজ্ঞ প্রোগ্রামারও করতে পারে” " - যেমন আমি আমার উত্তরে বলেছিলাম, আমি এটি বিশ্বাস করি না। আমি মনে করি এটি সম্পূর্ণরূপে স্বীকৃত কেস যা বাস্তবে কোনও সমস্যা তৈরি করে না।
— কনরাড রুডল্ফ
323

আপনি যদি ব্যবহার না করেন {এবং ব্যবহার না করে মন্তব্য সহ দুর্ঘটনাক্রমে নিয়ন্ত্রণ-প্রবাহ পরিবর্তন করা খুব সহজ }। উদাহরণ স্বরূপ:

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

আপনি যদি do_something_else()একটি একক লাইনের মন্তব্য দিয়ে মন্তব্য করেন তবে আপনি এটি শেষ করবেন:

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

এটি সংকলন করে, তবে must_always_do_this()সবসময় বলা হয় না।

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

— ta.speot.is
সূত্র
3
ওহ ছেলে !! এটি নির্ধারিত আচরণ যা must_always_do_this();আপনি // do_something_else () মন্তব্য করলে কার্যকর হবে;
— মিঃ আনুবিস
1
@ সুপ্র, যেমন এটি প্রথম লেখা হয়েছিল, তিনি বলছেন যে আপনি যদি ব্রেস ব্যবহার করেন তবে সঠিক প্রবাহটি ভাঙ্গা কঠিন এবং তারপরে কোডটি সঠিকভাবে
— বন্ধন
20
আমি অন্য দিন এটি ছুটেছি। if(debug) \n //print(info);। মূলত একটি পুরো লাইব্রেরি বের করে নিয়েছে।
— কেভিন
4
Fortunately we caught it in code review.সেকি! এটা খুব ভুল মনে হচ্ছে। Fortunately we caught it in unit tests.আরও ভাল হত!
— BЈовић
4
@ বিЈовић তবে কোডটি ইউনিট পরীক্ষায় থাকলে কী হবে? মন বগল। (মজা করে বলছি, এটি একটি উত্তরাধিকারসূচক অ্যাপ্লিকেশন unit কোনও ইউনিট পরীক্ষা নেই))
— ta.speot.is
59

প্রভাষকের দক্ষতা সম্পর্কে আমার সন্দেহ আছে। তার বিষয়গুলি বিবেচনা করে:

  1. ঠিক আছে
  2. কেউ কি সত্যিই লিখবেন (বা পড়তে চান) (b*b) - ((4*a)*c)? কিছু নজির সুস্পষ্ট (বা হওয়া উচিত), এবং অতিরিক্ত বন্ধনীগুলি কেবল বিভ্রান্তিকে বাড়িয়ে তোলে। (অন্যদিকে, আপনি কম-স্পষ্ট ক্ষেত্রে বন্ধনীগুলি ব্যবহার করতে পারেন, এমনকি যদি আপনি জানেন যে তাদের প্রয়োজন নেই))
  3. প্রকার, রকম. শর্তযুক্ত এবং লুপগুলি বিন্যাস করার জন্য দুটি বিস্তৃত স্প্রেড কনভেনশন রয়েছে: 
    যদি (কনড)
    কোড;
}
    এবং: 
    যদি (কনড)
{
    কোড;
}
    প্রথমদিকে, আমি তার সাথে একমত হয়েছি। উদ্বোধনটি {তেমন দৃশ্যমান নয়, তাই এটি সর্বদা সেখানে রয়েছে তা অনুমান করা ভাল। তবে দ্বিতীয়টিতে, আমি (এবং বেশিরভাগ লোকের সাথে যাদের সাথে আমি কাজ করেছি) একটি একক বিবৃতিতে ধনুর্বন্ধনী বাদ দেওয়া কোনও সমস্যা নেই। (অবশ্যই, প্রদত্ত যে ইনডেন্টেশন পদ্ধতিগত এবং আপনি এই স্টাইলটি ধারাবাহিকভাবে ব্যবহার করেন (
  4. কোন । if ( NULL == ptr )পঠনযোগ্যতা বাধাগ্রস্থ করার মতো বিষয়গুলি যথেষ্ট কুৎসিত। অন্তর্নিহিত তুলনা লিখুন। (যা অনেক ক্ষেত্রে ডানদিকে ধ্রুবকের ফলাফল হয়;) তাঁর 4 টি খারাপ পরামর্শ; কোডটিকে অপ্রাকৃত করে তোলে এমন কিছু এটি কম পঠনযোগ্য করে তোলে।
  5. কোন । intকিছুই কিন্তু বিশেষ ক্ষেত্রে জন্য সংরক্ষিত। সি এবং সি ++ প্রোগ্রামার অভিজ্ঞদের জন্য, unsignedসংকেত বিট অপারেটরগুলির ব্যবহার । সি ++ এর আসল কার্ডিনাল টাইপ নেই (বা অন্য কোনও কার্যকর সাব্রঞ্জ টাইপ); unsignedপ্রচারের নিয়মের কারণে সংখ্যাগত মানগুলির জন্য কাজ করে না। সংখ্যাগত মান যার উপর কোনও গাণিতিক ক্রিয়াকলাপগুলি ক্রমিক সংখ্যার মতো বোধগম্য হয় না, সম্ভবত এটি হতে পারে unsigned। তবে আমি এর বিরুদ্ধে তর্ক করব, কারণ এটি ভুল বার্তাটি পাঠায়: বিটওয়াইজ অপারেশনগুলিও বোঝা যায় না। মূল নিয়মটি হল যে অবিচ্ছেদ্য প্রকারগুলি intহ'ল_বিহীন_ অন্য কোনও ধরণের ব্যবহারের জন্য উল্লেখযোগ্য কারণ রয়েছে।
  6. কোন । নিয়মিতভাবে এটি করা বিভ্রান্তিমূলক, এবং আসলে কোনও কিছুর বিরুদ্ধে সুরক্ষা দেয় না। কঠোর OO যেমন পণ্য কোড ইন, delete this;প্রায়ই অধিকাংশ ঘন ক্ষেত্রে (এবং আপনি সেট করতে পারে না হয় thisথেকে NULL), এবং অন্যথায়, সবচেয়ে deleteযাতে আপনি পরে যাহাই হউক না কেন পয়েন্টার অ্যাক্সেস করতে পারছি না, destructors রয়েছে। এবং এটিকে সেট করা NULLচারপাশে ভাসমান অন্য কোনও পয়েন্টার সম্পর্কে কিছুই করতে পারে না। NULLসুরক্ষার ভ্রান্ত ধারণা দেওয়ার জন্য নিয়মিত বিন্দু নির্ধারণ করা , এবং আপনাকে সত্যিকার অর্থে কিছুই কিনে না।

টিপিক্যাল রেফারেন্সগুলির মধ্যে কোডটি দেখুন। উদাহরণস্বরূপ প্রথমটি ব্যতীত আপনার দেওয়া প্রতিটি বিধি লঙ্ঘন করে St

আমি আপনাকে অন্য একজন প্রভাষক খুঁজে পেতে পরামর্শ দেব। যিনি আসলে জানেন তিনি কী সম্পর্কে কথা বলছেন।

— জেমস কানজে
সূত্র
13
4 নম্বর কুরুচিপূর্ণ হতে পারে তবে এটির একটি উদ্দেশ্য রয়েছে। এটি (পিটিআর = এনএলএল) প্রতিরোধের চেষ্টা করছে। আমি মনে করি না যে আমি কখনও ব্যবহার করেছি delete this, এটি কি আমার দেখার চেয়ে বেশি সাধারণ? আমি মনে করি না যে NUL- এ পয়েন্টার স্থাপনের পরে ব্যবহারের পরে ওয়াইএমএমভি-তে কোনও জিনিস করা খারাপ। হতে পারে এটি কেবল আমি তবে তাঁর বেশিরভাগ নির্দেশিকাগুলি এটিকে খারাপ বলে মনে হয় না।
— ফায়ারড্রাগন
16
@ ফায়ারড্রাগন: বেশিরভাগ সংকলক আপনাকে সতর্ক করে দেবে if (ptr = NULL)যতক্ষণ না আপনি এটি লিখেন if ((ptr = NULL))। জেমস কানজির সাথে একমত হতে হবে যে NULLপ্রথম থাকার কদর্যতা এটিকে আমার জন্য একটি নির্দিষ্ট কোনও নিবন্ধে পরিণত করে না।
— লিও
34
@ জামেসকানজে: আমাকে বলতে হবে যে আপনি এখানে যা বলেছেন তার সাথে আমি বেশিরভাগের সাথে একমত নই - যদিও আমি আপনার যুক্তিগুলি পৌঁছানোর জন্য তাদের প্রশংসা করি এবং শ্রদ্ধা করি। সি এবং সি ++ প্রোগ্রামার অভিজ্ঞদের জন্য, স্বাক্ষরযুক্ত সিগন্যাল বিট অপারেটরগুলির ব্যবহার। - আমি মোটেও একমত নই: বিট অপারেটরগুলির ব্যবহার বিট অপারেটরগুলির ব্যবহারের ইঙ্গিত দেয়। আমার কাছে, ব্যবহারের ফলে প্রোগ্রামারের অংশে unsignedএকটি আকাঙ্ক্ষা নির্দেশ করে যে চলকটি কেবল ধনাত্মক সংখ্যার প্রতিনিধিত্ব করবে। স্বাক্ষরযুক্ত সংখ্যার সাথে মেশানো সাধারণত একটি সংকলক সতর্কবার্তা সৃষ্টি করে যা সম্ভবত বক্তৃতাটির উদ্দেশ্য ছিল।
— উপাদান 10
18
সি এবং সি ++ প্রোগ্রামার অভিজ্ঞদের জন্য, স্বাক্ষরযুক্ত সিগন্যাল বিট অপারেটর ব্যবহার করুন বা না। size_t, যে কেউ?
— ta.speot.is
16
@ জামেস কানজে, উদ্দেশ্যটি বিবেচনা করুন। আপনি অভিজ্ঞ প্রোগ্রামার দ্বারা উত্পাদিত কোডকে শিক্ষামূলক উদাহরণগুলির সাথে তুলনা করছেন। এই নিয়মগুলি প্রভাষক দ্বারা সরবরাহ করা হয়েছে কারণ সে তার শিক্ষার্থীদের যে ধরণের ভুল দেখায় সেগুলি are অভিজ্ঞতার সাথে, শিক্ষার্থীরা এই বিলোপগুলিকে শিথিল বা উপেক্ষা করতে পারে।
— জোশুয়া শেন লিবারম্যান
46

অন্যান্য সমস্ত উত্তর আপনার প্রভাষকের নিয়ম 3 রক্ষা করে।

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

"উপাদান 10" এর উত্তর আসলে একমাত্র অনুমেয় কেসকে হাইলাইট করে যেখানে এটি সত্যই কোনও ত্রুটির দিকে নিয়ে যেতে পারে। তবে অন্যদিকে, নিয়মিত প্রকাশের মাধ্যমে কোডটি প্রতিস্থাপন করা সর্বদা যাইহোক বিপুল যত্নের সতর্ক করে।

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

শুরুতে প্রচুর গার্ডের ধারা সহ একটি ফাংশন বিবেচনা করুন (এবং হ্যাঁ, নীচে সি সি ++ কোডটি খারাপ তবে অন্যান্য ভাষায় এটি বেশ সাধারণ পরিস্থিতি হবে):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

এটি ভয়াবহ কোড, এবং আমি দৃ strongly়ভাবে তর্ক করছি যে নিম্নলিখিতটি আরও বেশি পাঠযোগ্য:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

একইভাবে, সংক্ষিপ্ত নেস্টেড লুপগুলি কোঁকড়া বন্ধনী বাদ দেওয়ার মাধ্যমে উপকার করে:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

তুলনা করা:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

প্রথম কোডটি সংক্ষিপ্ত; দ্বিতীয় কোডটি ফুলে যায়।

এবং হ্যাঁ, পূর্ববর্তী লাইনে খোলার ব্রেস লাগিয়ে কিছুটা হলেও এটি প্রশমিত করা যেতে পারে । কিন্তু যে হবে এখনও কোন কোঁকড়া বন্ধনী ছাড়া কোড কম পাঠযোগ্য হবে।

সংক্ষেপে: অপ্রয়োজনীয় কোড লিখবেন না যা স্ক্রিনের জায়গা নেয়।

— কনরাড রুডল্ফ
সূত্র
26
যদি আপনি অকারণে পর্দার স্থান গ্রহণের কোডটিতে লিখিত বিশ্বাস করেন না, তবে আপনার নিজের লাইনে খোলার ব্রেস লাগানোর কোনও ব্যবসা নেই । আমি সম্ভবত এখন GNU এর পবিত্র প্রতিহিংসা থেকে হাঁসতে হবে এবং চালাতে যাচ্ছি, তবে গুরুত্ব সহকারে - হয় আপনি নিজের কোডটি উল্লম্বভাবে কমপ্যাক্ট করতে চান, বা আপনি তা করেন না। এবং যদি আপনি তা করেন তবে আপনার কোডটি কম উল্লম্বভাবে কমপ্যাক্ট করার জন্য ডিজাইন করা জিনিসগুলি করবেন না। তবে আপনি যেমনটি বলেছেন, এটি স্থির করে আপনি এখনও অপ্রয়োজনীয় ধনুর্বন্ধনী অপসারণ করতে চান। অথবা সম্ভবত শুধু লিখুনif (a == nullptr) { throw null_ptr_error("a"); } একটি লাইন হিসাবে ।
— স্টিভ জেসোপ
6
@ স্টিভ বাস্তব হিসাবে, আমি কি পূর্ববর্তী লাইনে খোলার বক্রবন্ধনী করা, খুব কারণে আপনি বিবৃত জন্য। পার্থক্যটি কতটা তীব্র হতে পারে তা আরও স্পষ্ট করতে আমি এখানে অন্য স্টাইলটি ব্যবহার করেছি।
— কনরাড রুডলফ
9
+1 আমি সম্পূর্ণরূপে সম্মত হই যে আপনার প্রথম উদাহরণটি ধনুর্বন্ধনী ছাড়া পড়া খুব সহজ। দ্বিতীয় উদাহরণে, আমার ব্যক্তিগত কোডিং শৈলীটি হ'ল বাইরের জন্য লুপের উপর বন্ধনী ব্যবহার করা হয় যা অভ্যন্তরীণ অংশে নয়। আমি @ স্টিভ জেসোপের সাথে এক চূড়ান্ত বা অন্যটি উল্লম্বভাবে কমপ্যাক্ট কোড সম্পর্কে থাকার বিষয়ে একমত নই। উল্লম্ব স্থান হ্রাস করার জন্য আমি ওয়ান-লাইনারগুলির সাথে অতিরিক্ত ব্রেসগুলি বাদ দিই, তবে আমি আমার উদ্বোধনী ব্রেসগুলি একটি নতুন লাইনে রাখি কারণ যখন বন্ধনীগুলি রেখাযুক্ত থাকে তখন আমার সুযোগটি আরও সহজ হয়। লক্ষ্যটি পঠনযোগ্যতা এবং কখনও কখনও এর অর্থ আরও উল্লম্ব স্থান ব্যবহার করা হয়, অন্য সময় এর অর্থ কম ব্যবহার করা হয়।
— ট্র্যাভেস্টি 3
22
"বাস্তব জীবনে আমি কখনও এই সমস্যার মুখোমুখি হইনি": ভাগ্যবান আপনি। এর মতো জিনিসগুলি কেবল আপনাকে পোড়াবে না, তারা আপনাকে 90% তৃতীয় ডিগ্রি বার্ন দেয় (এবং এটি সন্ধ্যায় শেষ হওয়ার জন্য দাবী করার ব্যবস্থাপনার কয়েকটি স্তর)।
— রিচার্ড
9
@ রিচার্ড আমি কেবল এটি কিনতে পারি না। আমি যেমন আড্ডায় ব্যাখ্যা করেছি, এমনকি যদি এই ত্রুটিটি কখনই ঘটে থাকে (যা আমি অসম্ভব বলে মনে করি) আপনি একবার স্ট্যাকের সন্ধানের দিকে নজর দিলে এটি সংশোধন করা তুচ্ছ কারণ কারণ কোডটি দেখে ত্রুটিটি যেখানে রয়েছে তা স্পষ্ট। আপনার অতিরঞ্জিত দাবি সম্পূর্ণ সম্পূর্ণ ভিত্তিহীন।
— কনরাড রুডল্ফ
40

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

সবচেয়ে ঘন ঘন সমস্যাযুক্ত উদাহরণটির মুখোমুখি হ'ল এটি:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

সুতরাং আমি যখন উপস্থিত হই এবং তত্ক্ষণাত বিবৃতি যুক্ত করতে চাই, আমি সাবধান না হলে আমি খুব সহজেই এটি দিয়ে শেষ করতে পারি:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

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

— জ্যাম
সূত্র
16
এই উদাহরণস্বরূপ সমস্যাটি কি ধনুর্বন্ধনীগুলির চেয়ে অনুপযুক্ত ইনডেন্টেশন এবং খুব দীর্ঘ লাইনে নেই?
— হনজা ব্র্যাবেক
7
হ্যাঁ, তবে নকশাগুলি / কোডিং নির্দেশিকা অনুসরণ করা যা কেবল 'নিরাপদ' ধরে নিয়ে লোকেরা অন্যান্য নির্দেশিকাগুলি (যেমন দীর্ঘ-দীর্ঘ লাইনে না থাকা) অনুসরণ করছে বলে মনে হচ্ছে তারা সমস্যার জন্য জিজ্ঞাসা করছে। যদি ধনুর্বন্ধনী শুরু থেকে থাকে, তবে এই পরিস্থিতিতে ভুল-ব্লক দিয়ে শেষ করা অসম্ভব।
— জাম
16
কীভাবে ব্রেস যুক্ত করা হবে (এটি if(really long...editor){ do_foo;}আপনাকে এই কেসটি এড়াতে সহায়তা করে? সমস্যাটি এখনও একইরকম মনে হয় Pers ব্যক্তিগতভাবে আমি যখন প্রয়োজন হয় না তখন ধনুর্বন্ধনী এড়াতে পছন্দ করি তবে সেগুলি লেখার জন্য প্রয়োজনীয় সময়ের সাথে তবে এর কম পড়ার যোগ্যতা নেই) কোডে দুটি অতিরিক্ত লাইনের কারণে
— গ্রিজলি
1
ভাল কথা - আমি ধরেই নিয়েছিলাম যে ধনুর্বন্ধনী প্রয়োগের ফলে তাদের বোধগম্য স্থানে রাখার ফলস্বরূপ, তবে অবশ্যই কিছু কঠিন করার জন্য দৃ determined়সংকল্পবদ্ধ কেউ আপনার উদাহরণ হিসাবে এগুলি লাইনটিতে রাখতে পারে। যদিও আমি ভাবতাম বেশিরভাগ লোকেরা তা করবে না।
— জ্যাম
2
কোনও ফাইল স্পর্শ করার সময় আমি প্রথম এবং শেষ জিনিসটি অটো ফর্ম্যাট বোতামটিতে আঘাত করি। এটি এই সমস্যাগুলির বেশিরভাগটি সরিয়ে দেয়।
— জোনাথন অ্যালেন
20

আমার 2 সি:

ইন্ডেন্টেশন ব্যবহার করুন

স্পষ্টত

অপারেটরের অগ্রাধিকারের উপর কখনই নির্ভর করবেন না - সর্বদা বন্ধনী ব্যবহার করুন

আমি "কখনই এবং" সর্বদা "শব্দটি ব্যবহার করতাম না, তবে সাধারণভাবে আমি দেখি এই নিয়মটি কার্যকর হচ্ছে some কিছু ভাষায় (লিস্প, স্মার্টটাক) এটি একটি নন-ইস্যু।

সর্বদা একটি}} ব্লক ব্যবহার করুন - এমনকি একটি একক লাইনের জন্যও

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

তুলনার বাম দিকে কনট অবজেক্ট

যোদার অবস্থা? না, দয়া করে। এটি পঠনযোগ্যতা ব্যথা করে। আপনি আপনার কোডটি সংকলন করার সময় সর্বাধিক সতর্কতা স্তরটি ব্যবহার করুন।

ভেরিয়েবলের জন্য স্বাক্ষরবিহীন ব্যবহার করুন যা = = 0

ঠিক আছে. যথেষ্ট মজাদার, আমি শুনেছি স্ট্রস্ট্রাপ একমত নয়।

মোছার পরে পয়েন্টারটি NULL এ সেট করুন - ডাবল মুছুন সুরক্ষা

খারাপ পরামর্শ! মুছে ফেলা বা অ-বিদ্যমান অবজেক্টের দিকে নির্দেশ করে এমন পয়েন্টার কখনও নেই।

— নেমানজা ত্রিফুনোভিচ
সূত্র
5
শুধুমাত্র শেষ পয়েন্টের জন্য +1। কোনও কাঁচা পয়েন্টারটির কোনও ব্যবসায়ের মালিকানা নেই memory
— কনরাড রুডলফ
2
স্বাক্ষরবিহীন ব্যবহারের ক্ষেত্রে: কেবল স্ট্রাস্ট্রাপই নয়, কে ওআরআর (সি তে), ভেষজ সুটার এবং (আমি মনে করি) স্কট মায়ার্স। প্রকৃতপক্ষে, আমি কখনও এমন কাউকে শুনিনি যাঁর সত্যিকার অর্থে সি ++ এর বিধিগুলি বুঝতে পেরেছিলেন এবং স্বাক্ষর ছাড়াই ব্যবহার করার পক্ষে তর্ক করেন।
— জেমস কানজে
2
@ জামেসকানজে বাস্তবে, একই সময়ে আমি স্ট্রোস্ট্রপের মতামত শুনেছিলাম (২০০৮ সালে বোস্টনের একটি সম্মেলন), হার্ব সটার সেখানে উপস্থিত ছিলেন এবং ঘটনাস্থলে বর্জনের সাথে একমত নন।
— নেমানজা ত্রিফুনোভিচ
3
কেবল " unsignedভাঙ্গা" সম্পূর্ণ করতে সমস্যাগুলির মধ্যে একটি হ'ল সি ++ অনুরূপ আকারের স্বাক্ষরযুক্ত এবং স্বাক্ষরবিহীন প্রকারগুলির সাথে তুলনা করলে এটি তুলনা করার আগে স্বাক্ষরবিহীন অবস্থায় রূপান্তরিত হয় । যার ফলে মান পরিবর্তন হয়। স্বাক্ষরিত রূপান্তর অগত্যা খুব ভাল হবে না; "তুলনামূলকভাবে" উভয় মানকে একটি বৃহত ধরণের রূপান্তর করা হয়েছিল যা উভয় প্রকারের মানগুলিকেই উপস্থাপন করতে পারে the
— জেমস কানজে
1
@ স্টেভ জেসপ আমার মনে হয় আপনাকে কোনও ফাংশন ফেরার প্রসঙ্গে এটি নিতে হবে unsigned। আমি নিশ্চিত: :) এর exp(double)চেয়ে বেশি মূল্য ফেরত দেওয়ার ক্ষেত্রে তার কোনও সমস্যা নেই MAX_INT। তবে আবার, আসল সমস্যাটি অন্তর্নিহিত রূপান্তর। int i = exp( 1e6 );পুরোপুরি বৈধ সি ++। স্ট্রাস্ট্রপ প্রকৃতপক্ষে এক পর্যায়ে ক্ষতিকারক অন্তর্নিহিত রূপান্তরগুলি হ্রাস করার প্রস্তাব দিয়েছে, তবে কমিটি তাতে আগ্রহী ছিল না। (একটি আকর্ষণীয় প্রশ্ন: unsigned- -> intক্ষতিকারক হিসাবে বিবেচিত হবে I'd আমি unsigned-> intএবং int-> unsignedক্ষয়ক্ষতি উভয়কেই বিবেচনা করব unsignedOK যা ঠিক করার জন্য দীর্ঘ পথ যেতে পারে
— জেমস কানজে
18

এটি আরও স্বজ্ঞাত এবং সহজেই বোধগম্য। এটি উদ্দেশ্য পরিষ্কার করে তোলে।

এবং এটা নিশ্চিত করে যে কোড ভাঙে না যখন একটি নতুন ব্যবহারকারী অজান্তে মিস্ পারে {, }যখন একটি নতুন কোড বিবৃতি যোগ করা হয়েছে।

— অলোক সেভ
সূত্র
Makes the intent clear+1, এটি সম্ভবত সবচেয়ে সংক্ষিপ্ত এবং সঠিক কারণ।
— কিউক্স - মনিকা 18
13

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

setCompIds( const std::string& compId, const std::string& compSubId );

যদিও প্রতিস্থাপনের জন্য দুটি কল প্রয়োজন:

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

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

if ( condition )
   setCompIds( compId, compSubId );

এটি:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

যা পরিষ্কারভাবে যা প্রয়োজন ছিল তা নয়। প্রতিস্থাপনটিকে একটি ব্লকের মধ্যে সম্পূর্ণরূপে চিকিত্সা করে এবং তারপরে মূর্খ চেহারাটি শেষ করে এমন কিছু ম্যানুয়ালি পরিবর্তন করে আমাকে প্রথমে ফিরে যেতে হয়েছিল (কমপক্ষে এটি ভুল হবে না))

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

— উপাদান 10
সূত্র
5
আমি একবার এমন কিছু ডকুমেন্টেশন দেখেছি যার দুর্দান্ত কয়েনেজ ছিল "মাইক্রোসফ্টলিজেন্ট"। হ্যাঁ, বৈশ্বিক অনুসন্ধান এবং প্রতিস্থাপনের মাধ্যমে উল্লেখযোগ্য ভুল করা সম্ভব। এর ঠিক অর্থ হ'ল বিশ্বব্যাপী অনুসন্ধান এবং প্রতিস্থাপনটি মাইক্রোসফ্টটিজেন্টলি নয়, বুদ্ধিমানভাবে ব্যবহার করতে হবে।
— পিট বেকার
4
আমি জানি এটি সম্পাদন করা আমার পোস্ট মর্টেম নয়, তবে আপনি যদি সোর্স কোডে টেক্সট রিপ্লেসমেন্ট করতে চলেছেন তবে আপনি সেই একই নিয়ম অনুসারে এটি করা উচিত যা আপনি ভালভাবে প্রতিষ্ঠিত টেক্সট রিপ্লেসমেন্টের জন্য ব্যবহার করেন ভাষায়: ম্যাক্রোস। আপনার কোনও ম্যাক্রো #define FOO() func1(); \ func2(); (ব্যাকস্ল্যাশের পরে লাইন ব্রেক সহ) লেখা উচিত নয় , এটি অনুসন্ধান এবং প্রতিস্থাপনের জন্য যায়। এটি বলেছিল, আমি স্টাইলের নিয়ম হিসাবে উন্নত "সর্বদা ব্রেস ব্যবহার করি" দেখেছি কারণ এটি আপনার সমস্ত মাল্টি-স্টেটমেন্ট ম্যাক্রোগুলিকে মোড়ানো থেকে বাঁচায় do .. while(0)। তবে আমি একমত নই।
— স্টিভ জেসোপ
2
বিটিডব্লিউ, এটি "সুপ্রতিষ্ঠিত" এই অর্থে যে জাপানি নটউইডটি সুপ্রতিষ্ঠিত: আমি বলছি না যে আমাদের ম্যাক্রোগুলি এবং পাঠ্য-প্রতিস্থাপনের উপায়টি ব্যবহার করা উচিত, তবে আমি বলছি যে আমরা যখন এই জাতীয় কাজ করি জিনিসটি, আমাদের এটি এমনভাবে করা উচিত যা কিছু কাজ করে না, কেবল তখনই কাজ করে যদি কোনও শৈলীর নিয়মটি সফলভাবে পুরো কোড বেজে সফলভাবে চাপানো হয় :-)
— স্টিভ জেসোপ
1
@ স্টিভ জেসপ ওয়ান ব্রেস এবং একটি বেল্টের জন্যও তর্ক করতে পারে। যদি আপনাকে এই জাতীয় ম্যাক্রোগুলি ব্যবহার করতে হয় (এবং আমরা সি ++ এর আগে এবং করেছি inline, তবে সম্ভবত তাদের লক্ষ্য করা উচিত যথাসম্ভব কোনও ফাংশনের মতো কাজ করার জন্য, do { ... } while(0)প্রয়োজনে ট্রিকটি ব্যবহার করে (এবং প্রচুর অতিরিক্ত বন্ধনী ব্যবহার করা। তবে এটি এখনও স্থির হবে না) "যদি এটি বাড়ির স্টাইল হয় তবে সর্বত্র ব্রেস ব্যবহার করা থেকে বিরত থাকবেন না ((এফডাব্লুআইডাব্লু: আমি এখানে আলোচিত সমস্ত স্টাইলকে coveringেকে রেখে বিভিন্ন ঘরের শৈলীর সাথে কাজ করেছি I've আমি কোনও গুরুতর সমস্যা হতে দেখিনি।)
— জেমস কানজে
1
এবং আমি গণনা করি, আপনি কোডটি আরও যত্ন সহকারে পড়েন এবং সম্পাদনা করুন with সুতরাং আপনার পড়ার পক্ষে সবচেয়ে সহজ কোন পছন্দটি থাকলেও আপনি অন্যদের সফলভাবে পড়তে পারেন। আমি এমন একটি সংস্থায় কাজ করেছি যেখানে বিভিন্ন দলগুলি বিভিন্ন "বাড়ির শৈলীতে" আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা আলাদা উপাদান তৈরি করে।
— স্টিভ জেসোপ
8

আমি {}স্পষ্ট কয়েকটি ক্ষেত্রে ব্যতীত সর্বত্র ব্যবহার করছি । একক লাইন ক্ষেত্রে অন্যতম:

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner

আপনি ফিরে আসার আগে কিছু পদ্ধতি যুক্ত করলে তা আপনার ক্ষতি করতে পারে। ইন্ডেন্টেশন নির্দেশ করে যে শর্ত পূরণের সময় রিটার্ন কার্যকর হয় তবে তা সর্বদা ফিরে আসবে।

স্টেটমেন্ট ব্যবহারের সাথে সি # তে অন্য উদাহরণ

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

যা সমান 

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}
— লুকাসজ ম্যাডন
সূত্র
1
usingবিবৃতিতে কেবল কমা ব্যবহার করুন এবং আপনার দরকার নেই :)
— Ry-
1
@ এমনিটেক যা এখানে সহজভাবে কাজ করে না - আপনি কেবল তখনই কমা ব্যবহার করতে পারেন যখন প্রকারগুলি সমান হয়, অসম প্রকারের জন্য নয়। লুকাসের এটি করার পদ্ধতিটি মূল উপায়, আইডিই এমনকি এটিকে আলাদাভাবে ফর্ম্যাট করে (দ্বিতীয়টির স্বয়ংক্রিয় ইন্ডেন্টেশনের অভাবটি নোট করুন using)।
— কনরাড রুডল্ফ
8

আমি মনে করতে পারি সবচেয়ে প্রাসঙ্গিক উদাহরণ:

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

কোনটি যুক্ত ifহবে else? সূচকটি বোঝায় যে বহিরাগতটি ifপায় else, তবে সংকলকটি এটি দেখতে পাবে না; ভেতরের if পাবেন else, এবং বাইরেরif না। আপনাকে জানতে হবে (বা ডিবাগিং মোডে এটি সেভাবে আচরণ করে দেখুন) এই কোডটি কেন আপনার প্রত্যাশা ব্যর্থ হতে পারে তা পরিদর্শন করে খুঁজে বের করতে। পাইথনকে জানলে এটি আরও বিভ্রান্ত হয়; সেক্ষেত্রে আপনি জানেন যে ইনডেন্টেশন কোড ব্লককে সংজ্ঞায়িত করে, তাই আপনি ইন্ডেন্টেশন অনুসারে মূল্যায়ন করার প্রত্যাশা করবেন। সি # তবে সাদা স্থান সম্পর্কে উড়ন্ত ফ্লিপ দেয় না।

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

if(someCondition)
   DoSomething();

... তবে এটি ঠিক এভাবে লেখা উচিত। "সর্বদা বন্ধনীর সাহায্যে গাণিতিক ক্রিয়াকলাপকে ঘিরে" এমন বিবৃতি "সর্বদা বন্ধনী ব্যবহার করে" শোনাচ্ছে। এটি খুব সরল বক্তব্যকে a * b + c / dপরিণত করবে ((a * b) + (c / d)), একটি ঘনিষ্ঠ-পেরেন (বহু কোডারের নিষিদ্ধ) অনুপস্থিত হওয়ার সম্ভাবনাটি প্রবর্তন করবে এবং কীসের জন্য? ক্রিয়াকলাপের ক্রমটি সুপরিচিত এবং কার্যকরভাবে প্রয়োগ করা হয়েছে, সুতরাং বন্ধনীগুলি অপ্রয়োজনীয়। আপনি সাধারণত প্রয়োগ হওয়ার চেয়ে আলাদা ক্রিয়াকলাপ প্রয়োগের জন্য প্রথম বন্ধনী ব্যবহার করবেন: a * (b+c) / dউদাহরণস্বরূপ। ব্লক ধনুর্বন্ধনী একই; এটি ডিফল্ট থেকে পৃথক হয় এবং আপনি "স্পষ্টত" না (ক্ষেত্রে সাধারণত বেশ সাধারণ জ্ঞান) ক্ষেত্রে আপনি কী করতে চান তা নির্ধারণ করতে তাদের ব্যবহার করুন।

— KeithS
সূত্র
3
@ অ্যালেক্সব্রাউন ... যা ঠিক আমার বক্তব্য ছিল। ওপিতে বর্ণিত নিয়মটি হ'ল "সর্বদা বন্ধনী ব্যবহার করুন, এমনকি একক লাইনের জন্যও", যা আমি যে কারণে বলেছি তার সাথে আমি একমত নই। বন্ধনীগুলি প্রথম কোডের উদাহরণের সাথে সহায়তা করবে , কারণ কোডটি ইন্ডেন্টডের মতো আচরণ করবে না; দ্বিতীয়টির পরিবর্তে elseপ্রথমটির সাথে জোড়া লাগাতে আপনাকে বন্ধনী ব্যবহার করতে হবে if। ডাউনভোটটি সরিয়ে দিন।
— কিথস
5

উত্তরগুলির সন্ধানের জন্য আপনার কোডের গল্পটি বলার মতো যে অভ্যাসটি আমি অভ্যাস করি সে সম্পর্কে স্পষ্টভাবে কেউ বর্ণনা করেনি:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

হয়ে:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

ফেলে j++উপর একই লাইনে যেন অন্য কাউকে সংকেত উচিত, "আমি শুধু কি কখনো বৃদ্ধিতে এই ব্লক চান j" । অবশ্যই, কেবলমাত্র সার্থক যদি লাইনটি যতটা সম্ভব সরলতর হয়, কারণ এখানে একটি ব্রেকপয়েন্ট স্থাপন করা, পেরির উল্লেখ হিসাবে , খুব কার্যকর হবে না।

আসলে আমি জাভাতে কোডটির এই 'বাছাই' রয়েছে এমন টুইটার স্টর্ম এপিআইর কিছু অংশ জুড়ে চলেছি, এখানে এই স্লাইডশোর পৃষ্ঠা ৪৩ এ রিলভ্যান্ট স্নিপেটটি এক্সিকিউট কোডটি গঠন করে :

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

লুপ ব্লকের জন্য এতে দুটি জিনিস রয়েছে তাই আমি এই কোডটি ইনলাইন করব না। অর্থাত না :

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

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

আপনি যদি অন্য কারও কাছে সত্যিকার অর্থে টেলিগ্রাফ করতে চান তবে এটি কেবলমাত্র এক লাইনের কাজ একটি টের্নারি অপারেটর বা ?:ফর্ম ব্যবহার করে:

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

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

সংক্ষেপে:

কল্পনা করুন যে আপনার পাঠক (অর্থাত্ কোডটি রক্ষণকারী ব্যক্তি) কীভাবে আপনার গল্পের (কোড) ব্যাখ্যা করে। এটি তাদের পক্ষে যতটা সম্ভব পরিষ্কার করুন। আপনি যদি জানেন যে নবজাতী কোডার / ছাত্র এটি বজায় রাখছে, সম্ভবত {}যতটা সম্ভব সম্ভব ছেড়ে দিন , যাতে তারা বিভ্রান্ত হন না।

— Pureferret
সূত্র
1
(1) বিবৃতি একই লাইনে রেখে দেওয়া কম পাঠযোগ্য, বেশি নয় makes বিশেষত সরল চিন্তা ভাবনার মতো সহজেই উপেক্ষা করা যায়। কি তাদের নতুন লাইন উপর করা। (২) অবশ্যই আপনি আপনার forলুপটি একটি লাইনে রাখতে পারেন, কেন এই কাজটি করা উচিত নয়? এটি একই কারণে কাজ করে যে আপনি ধনুর্বন্ধনী বাদ দিতে পারেন; নিউ লাইনটি কেবল সি ++ তে উল্লেখযোগ্য নয়। (3) আপনার শর্তসাপেক্ষ অপারেটরের উদাহরণ, ভয়াবহ হওয়া ছাড়াও অবৈধ সি ++।
— কনরাড রুডল্ফ
@ কনরাড রুডল্ফ ধন্যবাদ, আমি সি ++ তে কিছুটা মরিচা। আমি কখনও বলিনি (1) বেশি পঠনযোগ্য, তবে এটি সংকেত হবে যে কোডটির টুকরা বোঝানো হয়েছিল অনলাইন এক লাইনে। (২) আমার মন্তব্যটি আরও ছিল যে আমি এটি পড়তে সক্ষম হব না এবং এটি কীভাবে কাজ করে তা জানতে পেরে উঠব না, যদিও তা আদৌ বা উদ্দেশ্য হিসাবে ছিল; এই কারণে এটি না করার একটি উদাহরণ। (3) ধন্যবাদ, আমি দীর্ঘ সময় সি ++ লিখিনি। আমি এখন এটি ঠিক করব।
— পিওরফেরেট
2
এছাড়াও আরও একবারে একটি এক্সপ্রেসনকে এক লাইনে রেখে কোড ডিবাগ করা আরও কঠিন করে তোলে। আপনি কীভাবে এই লাইনে ২ য় এক্সপ্রেসনে ব্রেকপয়েন্টটি রেখেছেন?
— পাইওটার পেরাক
5

কারণ যখন আপনার দুটি বিবৃতি ছাড়াই থাকে তখন {}কোনও সমস্যা মিস করা সহজ। আসুন ধরে নেওয়া যাক কোডটি এরকম দেখাচ্ছে।

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

দেখতে বেশ ভাল লাগছে। এটি সহ সমস্যাটি মিস করা সত্যিই সহজ, বিশেষত যখন কোডযুক্ত ফাংশনটি বড় আকারের হয়। বিষয়টি goto failশর্তহীনভাবে চালানো হয়। আপনি সহজেই এটি কল্পনা করতে পারেন যে এটি হতাশার কারণ (যাতে hash_updateসমস্ত কিছু hash_updateফাংশনে সূক্ষ্ম দেখায়, কেন সর্বদা সর্বদা ব্যর্থ হয় ask

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

if (something) goto fail;

তবে নিম্নলিখিতটি নয়।

if (something)
    goto fail;
— কনরাড বোরোস্কি
সূত্র
যথাযথভাবে। কেবলমাত্র (সম্পূর্ণ অপ্রয়োজনীয়) নিউলাইন + ইনডেন্ট লাগাবেন না এবং আপনি এই সমস্যাটিকে পুরোপুরিভাবে ছুঁড়ে ফেলেছেন যে প্রত্যেকে সর্বদা তাড়াতাড়ি এগিয়ে আসে।
— আলেকজান্ডার - মনিকা পুনরায় ইনস্টল করুন
4

এটি আপনার লুপগুলি এবং শর্তসাপেক্ষ ব্লকগুলির ব্যাপ্তিটি স্পষ্টভাবে সংজ্ঞায়িত করে আপনার কোডটিকে আরও পঠনযোগ্য করে তোলে। এটি আপনাকে দুর্ঘটনাজনিত ভুল থেকে বাঁচায়।

— দ্রোণ
সূত্র
4

আর্ট 6: এটি নিরাপদ কারণ নাল পয়েন্টার মোছা একটি অনিচ্ছুক। সুতরাং যদি আপনি দুর্ঘটনাক্রমে দু'বার সেই পথটি অতিক্রম করে যান, তবে আপনি মেমরির দুর্নীতি মুক্ত করবেন না এমন স্মৃতি মুক্ত করবেন বা অন্য কোনও কিছুর জন্য বরাদ্দ দেওয়া হবে।

এটি স্ট্যাটিক ফাইল স্কোপ অবজেক্ট এবং সিঙ্গলটনের বেশিরভাগ ইস্যু যা জীবনকাল খুব পরিষ্কার নয় এবং ধ্বংস হয়ে যাওয়ার পরে পুনরায় তৈরি করার জন্য পরিচিত।

বেশিরভাগ ক্ষেত্রে, আপনি অটো_প্টার ব্যবহার করে এর প্রয়োজনীয়তা এড়াতে পারেন

— টম ট্যানার
সূত্র
6
যদি আপনি দুবার সেই পথটি অতিক্রম করেন তবে আপনি কোনও প্রোগ্রামিং ত্রুটি পেয়ে গেছেন। এই ত্রুটিটিকে কম ক্ষতিকারক করার জন্য একটি পয়েন্টার সেট করা অন্তর্নিহিত সমস্যার সমাধান করে না।
— পিট বেকার
1
সম্মত, তবে আমি এটি আগে প্রস্তাবিত দেখেছি এবং আমি বিশ্বাস করি এটি কিছু পেশাদার প্রোগ্রামিং মান হিসাবে রয়েছে। পোস্টারের অধ্যাপক কেন কোনও ভাল হওয়ার চেয়ে বরং কেন এটি নিয়ে এসেছিলেন আমি সে সম্পর্কে আরও মন্তব্য করছি
— টম ট্যানার
2
পিট বেকার যা বলেছিলেন তা অনুসরণ করে: এটি অন্তর্নিহিত সমস্যার সমাধান করে না, তবে এটি এটি মাস্ক করতে পারে। (এমন কিছু ক্ষেত্রে রয়েছে যা আপনি NULLমুছে ফেলার পরে একটি পয়েন্টার সেট করে দিতেন NULLthose যদি সেই পরিস্থিতিতে পয়েন্টারটির সঠিক মান হয়; উদাহরণস্বরূপ পয়েন্টারটি একটি ক্যাশেড মানকে NULLনির্দেশ করে এবং একটি অবৈধ ক্যাশে নির্দেশ করে But একজন NULLডেস্ট্রাক্টরের সর্বশেষ লাইন হিসাবে নির্দেশক , আপনি অবাক হন যে তিনি সি
— +++
4

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

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

আমার কাছে বিশৃঙ্খল লাগছে এটি লুপ এবং ইফ স্টেটমেন্টকে পৃথক ক্রিয়ায় পৃথক করে, যখন সত্যই আপনার উদ্দেশ্যটি একক ক্রিয়া হয়: সমস্ত সংখ্যাকে 2 দ্বারা বিভাজ্য হিসাবে গণনা করা আরও আরও স্পষ্ট ভাষায় ভাষায়, এটি এমন কিছু লেখা যেতে পারে:

j = [1..100].filter(_%2 == 0).Count

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

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}
— MikeFHay
সূত্র
7
আমি পছন্দ করি সবাই for (int i = 0; i < 100; i += 2);ইন্ডেন্টেশন সম্পর্কিত তর্ক চালিয়ে যাওয়ার জন্য কীভাবে উপেক্ষা করার ব্যবস্থা করে ;-) সম্ভবত আমাদের একটি সম্পূর্ণ পৃথক বন্দুকযুদ্ধ থাকতে পারে, iএকটি নির্দিষ্ট সম্পত্তির সাথে একটি নির্দিষ্ট পরিসরে প্রতিটিটির জন্য "যুক্তিটি প্রকাশ করার জন্য" "সর্বোত্তম" কীভাবে " লুপ ছাড়াই সি ++ এ, স্ট্যান্ডার্ড অ্যালগরিদমের কিছু দুঃস্বপ্নের সংমিশ্রণ ব্যবহার করে filter_iteratorএবং / অথবা counting_iterator।
— স্টিভ জেসোপ
1
এছাড়াও, যদি আমাদের তা ছিল তবে ফলস্বরূপ একক বিবৃতিটি কীভাবে যুক্ত করা যায় সে সম্পর্কে আমরা দ্বিমত পোষণ করতে পারি।
— স্টিভ জেসোপ
2
@ স্টিভ, যদিও এটি কেবল একটি উদাহরণ। প্যাটার্নটির বৈধ ব্যবহারের প্রচুর পরিমাণ রয়েছে। স্পষ্টতই আপনি যদি 1 থেকে 100 নম্বরগুলিকে 2 দ্বারা বিভাজ্য বলে গণনা করতে চান তবে আপনাকে যা করতে হবে তা হল 100/2।
— মাইকএফএই
2
অবশ্যই, আমি জানি, সে কারণেই আমি " iনির্দিষ্ট সম্পত্তি সহ প্রতিটি জন্য" একটি নির্দিষ্ট সম্পত্তি সহ "বিমূর্ত হয়েছি । এটি কেবলমাত্র এসও তে, লোকেদের দেওয়া উদাহরণটির সম্পূর্ণ ভিন্ন পদ্ধতির পক্ষে প্রকৃত প্রশ্নটিকে উপেক্ষা করতে খুব তাড়াতাড়ি। তবে ইনডেন্টিং গুরুত্বপূর্ণ , সুতরাং আমরা তা করি না ;-)
— স্টিভ জেসপ
4

উপরে বর্ণিত ত্রুটিগুলি রোধ করতে সহায়তা করার একটি বিকল্প হ'ল আপনি যখন বন্ধনী ব্যবহার করবেন না তখন কী ঘটতে চান তা ইনলাইন করুন। আপনি কোডটি সংশোধন করার চেষ্টা করার সময় ত্রুটিগুলি লক্ষ্য না করা এটি আরও শক্ত করে তোলে।

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong
— Blacktiger
সূত্র
5
দ্বিতীয় বিকল্পটি একটি সংকলন ত্রুটি অর্জন করবে, কারণ এটি elseকোনওটির সাথে সম্পর্কিত নয় if।
— লুচিয়ান গ্রিগোর
ইনলাইনটিতে তেমন দৃশ্যমান সমস্যাটি হ'ল না যে ডিফল্টরূপে বেশিরভাগ আইডিই তাদের অটোফর্ম্যাট ইউটিলিটি ব্যবহার করার সময় এটিকে ইন্ডেন্ট শৈলীতে পরিবর্তন করে।
— হনজা ব্রাবেক
@ هونজা: যদিও এটি একটি বহুল অভিযোগযুক্ত রাজনৈতিক সমস্যা। যদি আমরা একটি কোড বেসে সহযোগিতা করে থাকি, হয় আমাদের প্রতিটি শেষ বিবরণে একই ইনডেন্টিং শৈলীটি ব্যবহার করতে হবে, অথবা আমাদের "উভয় কারণে" বিদ্যমান কোডটি স্বতঃরূপণ না করতে উভয়ের সম্মত হতে হবে। পূর্বের যদি সম্মত শৈলীটি এখনও এতে অন্তর্ভুক্ত করতে পারে তবে আপনি এটির সম্মানের জন্য আপনার আইডিই কনফিগার করতে হবে বা অটোফর্ম্যাটটি ব্যবহার করবেন না। সম্মত হন যে সাধারণ ফর্ম্যাটটি "আমার আইডিই অটোফর্ম্যাটগুলি যাই হোক না কেন" সবই যদি খুব ভাল হয় তবে আমরা সবাই যদি একই আইডিই চিরকালের জন্য ব্যবহার করি, অন্যথায় এত ভাল না।
— স্টিভ জেসপ
3

আপনি যদি সংকলক হন তবে এতে কোনও তফাত আসে না। দুটোই এক।

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

— পিপি
সূত্র
2
{যাই হোক না কেন, নিজের লাইনে খোলার ব্যতীত ।
— রব
3

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

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

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

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

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

শর্তসাপেক্ষ রিটার্নটি যদি এভাবে বিন্যাস করা হয়:

if (!SomeConditionIsMet())
{
    return;
}

এটি অনেকটা লক্ষণীয় এবং ফাস্ট কোডার এটি এক নজরে খুঁজে পাবে।

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

আমি প্রথমটিকে দ্বিতীয়টি পরিষ্কার বলে বিবেচনা করি। এটা তোলে নির্দেশাবলী বন্ধ, সামান্য কোড সহ অনুভূতি জরিমানা যখন কোড জটিল পায় দেয় {...}অনেক সাহায্য করে এমনকি যদি তা না হয় endifবাbegin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;
— RollRoll
সূত্র
1

আপনি যখন এটি শেষ করেছেন তখন পয়েন্টারটি NULL এ সেট করা ভাল।

এখানে একটি উদাহরণ কেন:

ক্লাস এ নিম্নলিখিতগুলি করে:

  1. মেমরির একটি ব্লক বরাদ্দ করে
  2. তারপরে কিছু সময় পরে এটি মেমরির এই ব্লকটি মোছা করে তবে পয়েন্টারটি NULL তে সেট করে না

ক্লাস বি নিম্নলিখিতটি করে

  1. মেমরি বরাদ্দ করে (এবং এই ক্ষেত্রে এটি একই মেমরি ব্লক দেওয়া হবে যা ক্লাস এ দ্বারা মুছে ফেলা হয়েছিল)

এই স্থানে ক্লাস এ এবং ক্লাস বি উভয়েরই একই মেমোরি ব্লকের দিকে ইঙ্গিত করে পয়েন্টার রয়েছে, যতক্ষণ ক্লাস এ সম্পর্কিত, মেমরির এই ব্লকটি বিদ্যমান নেই কারণ এটি শেষ হয়ে গেছে।

নিম্নলিখিত সমস্যা বিবেচনা করুন:

ক্লাস এ-তে কোনও যুক্তিগত ত্রুটি থাকলে যার ফলশ্রুতিতে এটি এখন ক্লাস বি এর অন্তর্গত?

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

ক্লাস বি অবশেষে ক্রাশ হতে পারে যদি এটি অপ্রত্যাশিত মানগুলির সাথে মুখোমুখি হয় এবং যখন এটি ক্রাশ হয়, সম্ভাবনা থাকে, সমস্যাটি ক্লাস এ-তে থাকাকালীন আপনি ক্লাস বিতে এই বাগটি শিকারে যথেষ্ট দীর্ঘ সময় ব্যয় করবেন class

আপনি যদি মুছে ফেলা মেমরি পয়েন্টারটি NULL তে সেট করে রেখেছিলেন তবে ক্লাস এ-তে যে কোনও যুক্তি ত্রুটি নুয়াল পয়েন্টারটিতে লেখার চেষ্টা করার সাথে সাথে আপনি একটি ব্যতিক্রম ত্রুটি পেয়েছেন।

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

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

— জন
সূত্র
2
যদি কোনও লজিক ত্রুটি ঘটে থাকে তবে এটি ঠিক করা উচিত, বরং এটি মাস্কিং।
— u:10nbɐɥs
@ বার্মার, ওপি বলেছেন ... dele. মোছার পরে পয়েন্টারকে নূলে সেট করুন - ডাবল মুছুন সুরক্ষা // খারাপ নয়। কিছু লোক এটিকে নূলে সেট না করার বিষয়ে প্রতিক্রিয়া জানিয়েছে এবং আমি বলছি কেন এটি নূলে সেট করা উচিত, of. এর কোন অংশ? নূলে সেট করার বিষয়ে আমার উত্তর fit-এর সাথে খাপ খায় না?
— জন
1
@ শাকুইন, এবং এই যুক্তি ত্রুটিগুলি প্রথম স্থানে আবিষ্কার করার প্রস্তাব আপনি কীভাবে করবেন? একবার আপনি পয়েন্টার ভেরিয়েবলটি NULL এ সেট করার পরে মেমরি মুছে ফেলা হবে। আপনার অবৈধ প্রচেষ্টা করা হয়েছে সেই লাইনে ডিবিগারকে নুয়াল পয়েন্টারটি উল্লেখ করার যে কোনও প্রয়াস ক্র্যাশ করবে। আপনি পিছনে ট্রেস করতে পারেন এবং লজিক ত্রুটিটি কোথায় ছিল তা দেখতে এবং সমস্যার সমাধান করতে পারেন। আপনি মেমরিটি মুছে ফেলার পরে যদি আপনি পয়েন্টার ভেরিয়েবলটি NULL তে সেট না করেন তবে অজানা যুক্তি ত্রুটির কারণে এই মুছে ফেলা মেমরিটি লেখার আপনার অবৈধ প্রয়াস সফল হতে পারে এবং সেই কারণে ক্রাশ হয় না। এটি মুখোশ দিচ্ছে না।
— জন
1

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

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

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

পরিবর্তে, যদি তারা এটি দেখেন তবে তারা এমনকি এটি এটি লেখার পরামর্শ দিতে পারে:

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

যে টেকনিক্যালি যে শাসনের লঙ্ঘন যেহেতু মধ্যে কোন কোঁকড়া বন্ধনী হয় elseএবং if। বিধিবিধানের এ জাতীয় দ্বৈততা যখন নির্লজ্জ সরঞ্জামের সাথে স্বয়ংক্রিয়ভাবে কোড বেসে প্রয়োগ করার চেষ্টা করবেন তখন তা ভূপৃষ্ঠ। আসলে, তর্ক কেন করা উচিত, কেবল কোনও সরঞ্জামকে স্বয়ংক্রিয়ভাবে শৈলী প্রয়োগ করতে দেওয়া হোক।

দ্বিতীয় বিবরণ (যে প্রায়শই এই নিয়মের সমর্থকদের দ্বারা ভুলে যায়) হ'ল ত্রুটিগুলি যে ঘটতে পারে তা কেবলমাত্র সেই নিয়ম # 3 লঙ্ঘনের কারণে ঘটে না। প্রকৃতপক্ষে এগুলি প্রায়শই নিয়ম # 1 লঙ্ঘনের সাথে জড়িত থাকে (যার সাথে কারও যুক্তি নেই)। আবার স্বয়ংক্রিয় সরঞ্জামগুলির দৃষ্টিকোণ থেকে, এমন কোনও সরঞ্জাম তৈরি করা কঠিন নয় যা নিয়ম # 1 লঙ্ঘন করা হলে তত্ক্ষণাত্ অভিযোগ করে এবং তাই বেশিরভাগ ত্রুটি সময়মতো ধরা পড়ে।

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

— Öö তিব
সূত্র
1

আমাকে স্বীকার করতে হবে যে সর্বদা {}একক লাইনের জন্য ব্যবহার হয় না তবে এটি একটি ভাল অনুশীলন।

  • বলুন আপনি বন্ধনী ছাড়াই এমন কোনও কোড লিখেছেন যা দেখতে দেখতে এটির মতো দেখাচ্ছে:

    (int i = 0; i <100; ++ i) এর জন্য (int j = 0; j <100; ++ জে) ডোজিং স্টাফ ();

এবং কিছু সময়ের পরে আপনি jলুপে কিছু অন্যান্য জিনিস যুক্ত করতে চান এবং আপনি কেবল প্রান্তিককরণের মাধ্যমে এটি করেন এবং বন্ধনী যুক্ত করতে ভুলে যান।

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

    if (...) {// সোমারস্টাফ ... {// আমাদের কিছু নেই, যখন, ইত্যাদি // // SomeOtherStuff} // SomeMoreStuff}

  • এটি ব্যবহারের তৃতীয় উপায় দ্বিতীয়টির সাথে সমান। এটি কেবল স্ট্যাক ক্লিনার করতে নয় কিছু ফাংশন খোলার জন্য । আপনি যদি mutexদীর্ঘ ফাংশনগুলিতে সাধারণত ব্যবহার করেন তবে ডেটা অ্যাক্সেস করার ঠিক আগে এবং এটি পড়া / লেখা শেষ করার পরে লক এবং আনলক করা ভাল। দ্রষ্টব্য এইভাবে ব্যবহার করছে যদি আপনার কিছু নিজস্ব থাকে classবা structসাথে থাকে constructorএবং destructorমেমরি লক করে রাখে।

  • আর কি আছে:

    যদি (...) যদি (...) সামার স্টাফ (); অন্যটি সামথার স্টাফ (); // যদি দ্বিতীয় হয় তবে অ্যালিগমেন্টটি দেখায় যে এটি প্রথমে রয়েছে ...

সব মিলিয়ে, আমি বলতে পারি না, সর্বদা {}একক লাইনের জন্য ব্যবহার করার সর্বোত্তম উপায় তবে এটি করা খারাপ নয়।

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

— ST3
সূত্র
1

নিয়ন্ত্রণ বিবৃতি লেখার সম্ভাব্য কয়েকটি উপায় রয়েছে; এগুলির কয়েকটি সংমিশ্রণ যথাযথভাবে ক্ষতিগ্রস্থ না করে থাকতে পারে, তবে অন্যান্য সংমিশ্রণ সমস্যার কারণ হতে পারে। স্টাইল

if (condition)
  statement;

নিয়ন্ত্রণ বিবৃতি লেখার অন্যান্য কয়েকটি উপায়ের সাথে স্বাচ্ছন্দ্যে সহাবস্থান করবে তবে অন্যের সাথে তেমন ভাল নয়। যদি বহু-লাইন নিয়ন্ত্রিত বিবৃতিগুলি লিখিত হয়:

if (condition)
{
  statement;
  statement;
}

তারপরে এটি দৃশ্যমানভাবে সুস্পষ্ট হবে যে কোন ifবিবৃতিগুলি একটি একক লাইন নিয়ন্ত্রণ করে এবং কোনগুলি একাধিক রেখাকে নিয়ন্ত্রণ করে। তবে, মাল্টি-লাইন ifস্টেটমেন্টগুলি এভাবে লেখা হয়:

if (condition) {
  statement;
  statement;
}

তারপরে কেউ ifপ্রয়োজনীয় ধনুর্বন্ধনী সংযোজন না করে একক বিবৃতি নির্মাণের প্রসার বাড়ানোর চেষ্টা করার সম্ভাবনা অনেক বেশি হতে পারে।

ifকোডবেস ফর্মটির উল্লেখযোগ্য ব্যবহার করে সিঙ্গল-স্টেটমেন্ট অন-নেক্সট লাইন স্টেটমেন্টটিও সমস্যাযুক্ত হতে পারে

if (condition) statement;

আমার নিজস্ব পছন্দ হ'ল স্টেটমেন্টটি তার নিজের লাইনে রাখলে সাধারণত একইসাথে নিয়ন্ত্রণ ব্লকযুক্ত অনেকগুলি ifস্টেটমেন্ট রয়েছে এমন ক্ষেত্রে ব্যতীত যথাযথতা বৃদ্ধি করে eg

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

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

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