প্রতিটি ফাংশন / পদ্ধতি যুক্তি একটি নতুন লাইনে তালিকাভুক্ত করা কি খারাপ ধারণা এবং কেন?

Question

আমি এমন কারও সাথে কাজ করি যারা, যখনই তারা কোনও ফাংশন ডাকে তারা যুক্তিগুলিকে একটি নতুন লাইনে রাখে যেমন eg

aFunction(
    byte1,
    short1,
    int1, 
    int2,
    int3,
    int4,
    int5
) ;

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

Comments

+1, আমি আপনার প্রশ্নের উত্তর দেওয়ার জন্য যথেষ্ট জানি না, তবে আমি এটিরও ঘৃণা করি। আপনার যদি কোনও ফাংশনে এমন অনেক যুক্তি থাকে তবে আপনার ফাংশনটি সম্ভবত খুব বেশি করছে।

— ম্যাপেল_শ্যাফ্ট

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

— অ্যালেক্স ফেনম্যান

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

— ব্রায়ান শ্রথ

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

— নিল জি

@ ম্যাপেল_শ্যাফ্ট আমি এ জাতীয় বক্তব্যকে ঘৃণা করি। এটির কোনও সত্যতা নেই বলে নয়, কিন্তু কারণ অনেক লোক অবজ্ঞার অবকাশ ছাড়াই এই জাতীয় পরামর্শ অনুসরণ করে।

— স্টিজন

Answer 1

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

স্পষ্টতই, পঠনযোগ্যতা বৃদ্ধির সর্বোত্তম উপায় হ'ল আর্গুমেন্টের সংখ্যা সীমাবদ্ধ করা।

Comments

অনেকগুলি লোককে অ্যারেতে ফেলে তর্কগুলি হ্রাস করে। আমি বরং লুকানো জটিলতার সাথে ক্লিনার-বর্ণন কোডের চেয়ে কুৎসিত জগাখিচুড়ি দেখতে পাচ্ছি।

— স্যাটোনিকপপি

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

— মাইকেল কে

আমি দেখতে পেলাম যে একাধিক লাইন ব্যবহার করে কোডটি পঠনযোগ্য তৈরি করতে সহায়তা করে যদি পরামিতিগুলি দীর্ঘ অভিব্যক্তি বা কয়েকটি খুব বেশি হয়। অন্যথায় এটি কেবল বিরক্তিকর।

— পেড্রোসি 88

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

— স্কট হুইটলক

Answer 2

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

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

do_complex_op(
      0, //Starting state, always 0, ask Joe why
      X, //X-coord of thingy
      y, //Y-coord of thingy
      73, //in this case, we don't want to use Z but want constant 
      dlogMessageTitle, //message for dialogue title
      dlogMessageText, //message for dialogue contents, don't care about this.
      SomethingIP, //IP of something-or-other server, can be NULL, won't crash.
      someObject.childObject.getValue(key1).HVAL, //very long path to HVAL
      someObject.childObject.getValue(key1).LVAL, //very long path to LVAL
      this.parentWindow.owner.mainTextBox.text.value.trim, //get the trimmed text, untrimmed text causes weird output
      pvrMainSettingForLongBlahs.getObjectByPath(somePath),
      pvrMainSettingForLongBlahs.K_TCA_UPPER_LIMIT,
      pvrMainSettingForLongBlahs.K_ENDPOINT_COMPLIANCE_LEVEL,
 );

যে নামের প্যারামিটারগুলির নাম দেওয়া হয়েছে এমন ভাষাগুলির সাথে যদি আপনি প্যারামিটারের নামগুলি ব্যবহার করেন (উদাহরণস্বরূপ PL / SQL তে থাকে):

PKG_SOME_TEST_CODE.FN_DO_SOMETHING( in_text => 'test text',
                                    in_id => v_id,
                                    in_ref_id => v_ref_id,
                                    out_array_for_storage => v_bArray); 

তবে আমি আপনার সাথে একমত যে ফাংশন কলটি যদি সহজ হয় এবং খুব বেশি পরামিতি না হয় তবে এটি বিরক্তিকর হতে পারে যেমন:

setColour (
    r,
    g,
    b
 );

আমি পড়তে অনেক সহজ মনে করি

 setColour(r,g,b);

---

@ ইম্মকিউ এর জন্য:

rc=a(b,c(d,e(f)))

rc=a(
     b,
     c(
       d,
       e(
         f
        )
      )
    )

Comments

প্রথম উদাহরণটি একটি বাস্তব সমস্যার একটি ভুল উত্তর। প্রথম স্থানে সুস্পষ্ট পরিবর্তনশীল অ্যানিমগুলি ব্যবহার করবেন না কেন?

— ডেডালনিক্স

@ ডিডালনিক্স: ভাল কথা, এটি কিছুটা পরিষ্কার করেছেন।

— হতাশিত

সত্য। যাইহোক, এটি সবসময় পরিবর্তনশীল নামগুলির সাথে কোনও সমস্যা নয়। দীর্ঘ ভেরিয়েবলের নাম, ডিফল্ট মানগুলির সাথে যুক্তি ইত্যাদির সাথে আরও কাজ করা

— ইন্সপেক্টর

আমি তর্ক করব যে সমস্যার আরও ভাল সমাধানটি রিফেক্টর do_complex_op () হয় তাই এটি পরামিতি হিসাবে কাঠামো লাগে। তারপরে আপনি এটি করতে পারেন do_complex_op(new paramStruct { StartingState = 0, XCoord = xcoord }), তারপরে এটি স্ব নথিভুক্ত হয়ে

— ওঠার

@ ক্যালড্রেইক্সএক্সএক্স: আমি সম্মত, তবে কখনও কখনও কোড পরিবর্তন করা কোনও বিকল্প নয়, যেমন এটি যখন অন্য কারও পাঠাগারটিতে কাজ করে। অবশ্যই, আমি এটিতে একটি মোড়ক তৈরি করতে পারতাম, তবে আমি এখনও তাদের মূল ফাংশনটি কিছু সময় কল করতে পারি ।

— হতাশিত

Answer 3

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

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

Comments

এইচএম ... এই পদ্ধতির সাথে আমরা কীভাবে কোনও নতুন সেরা অনুশীলন চালু করতে পারি (বা, গুরুতরভাবে সঠিক: একটি আরও ভাল অনুশীলন )?

— ট্রেব

ট্র্যাব: অবশ্যই, কেবল দেখান যে আরও ভাল অনুশীলন আসলে আরও ভাল , কেবল আলাদা নয় ।

— ব্যবহারকারী 281377

তবে "পড়া কঠিন" নিজেই, বিষয়গত এবং মতামতের বিষয় of আমার জন্য, প্রতি লাইনে একটি যুক্তি প্রতি লাইনে দুটি, তিন, বা চারটি যুক্তির চেয়ে দৃষ্টিভঙ্গি পার্স করা সহজ। এবং আমি সম্পাদককে প্রায় 100 অক্ষরের চিহ্নের বাইরে প্রসারিত হলে আমি সবসময় একাধিক লাইনে বিভক্ত করি।

— টবি

সাধরণ। "কঠিন পড়তে" পারেন নিরপেক্ষভাবে পরিমাপ করা। এটি ঠিক না হয়ে থাকে। এটি নিয়ে তর্ক করা আরও মজাদার।

— জেসনট্রু

এটি উদ্দেশ্যমূলকভাবে পরিমাপ করা যেতে পারে তবে পড়া পড়া ব্যক্তিটির থেকে স্বাধীনভাবে নয়।

— জে কে।

Answer 4

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

তবে আমার মূল উদ্বেগটি কোডটি "কুরুচিপূর্ণ" বা "সুন্দর" কিনা তা নয়। আমার মূল উদ্বেগ হ'ল ভুল না করে বোঝা এবং পরিবর্তন করা কতটা সহজ।

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

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

সুতরাং (ছেলে, আমি এটির জন্য বিস্মৃত হব) আমি এটি এই জাতীয়ভাবে লিখছি:

nameOfFunction(firstArgument
    , secondArgument // optional comment
       ...
    , lastArgument   // optional comment
    );

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

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

Comments

আমি ব্যক্তিগতভাবে মনে করি এটি দুর্দান্ত উত্তর কারণ আপনি নিজের যুক্তিটি খুব ভালভাবে ব্যাখ্যা করেছেন। ভাল কাজ মাইক।

— জর্ডান

Answer 5

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

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

Answer 6

এটি এটিকে আরও সহজ করে তোলে:

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

Answer 7

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

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

Comments

এই ৮০ টি চরিত্রের জিনিসটি যেতে হবে, এটির জন্য কেবল কোনও প্রযুক্তিগত-বৈধ কারণ নেই। আমরা এখন 19XX X 16xx মনিটর এবং সামঞ্জস্যযোগ্য ফন্ট এবং ফন্ট আকারের যুগে বাস করি।

— আনন

@ অ্যানন: এর সঠিক কারণ? আপনি কী ভাবেন পাঠ্যগুলি কলামগুলিতে মুদ্রিত হয় এবং বইগুলি সেগুলির তুলনায় সংকীর্ণ হয়? কারণ খুব দীর্ঘ লাইনগুলি পড়তে গিয়ে মানব চোখ ট্র্যাক হারায়।

— জ্যান লিংস

@ অ্যানন: এছাড়াও আমি আমার ওয়াইডস্ক্রিনটি দুই বা তিনটি ফাইল আনুভূমিক বিভাজনে খোলা রাখতে ব্যবহার করতে চাই যা একটি লাইনে ৮০-১০০ অক্ষরে ফিরে আসে।

— জ্যান লিংস

@ অ্যানন: প্রযুক্তিগতভাবে না, ব্যবহারিকভাবে: হ্যাঁ হ্যাঁ। জ্যান লিনাক্স পুরোপুরি ঠিক আছে, আরও অতিরিক্ত কারণ রয়েছে: কমান্ড লাইন ইউটিলিটিগুলি ব্যবহার করে মার্জ করা, ডিফ করুন ... ওহ ও শুভকামনা যেহেতু আপনি বড় হবেন: 8 পি ফন্টে ফোকাস করছে: ও)

— মার

Answer 8

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

Comments

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

— বিলথোর

Answer 9

এটি কি কোডিং মানদণ্ডের বিরুদ্ধে?

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

আপনি কেন এটি কার্যকর মনে করেন না সে সম্পর্কে একটি সম্পূর্ণ আলোচনা করুন এবং আশা করি আপনি দিনটি জিতবেন। আপনি কখনই জানেন না যে আপনার সহকর্মী আপনাকে বোঝাতে পারে যে তার উপায় সর্বোপরি সর্বোত্তম;)

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

Answer 10

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

এটি পড়ার চেয়েও সহজ:

int f(int, int, int,
      char, double, int
      X const&, Y)
{}

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

গুরুত্বপূর্ণ অংশটি হ'ল আপনার কোডটি প্রিন্টেড বা স্ট্যান্ডার্ড, 80 কোল প্রদর্শনগুলিতে প্রদর্শিত হতে পারে এবং এখনও সুগঠিত হতে পারে।

Answer 11

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

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

আমার পড়ার জন্য কোনটি ... আপনি এই প্রশ্নে অনুরোধ করছেন: আপনার ব্যক্তিগত পছন্দকে ন্যায়সঙ্গত করার জন্য একটি হাস্যকর, ছদ্মবেশী যুক্তি।

Answer 12

সত্য কথা বলতে গেলে এটি ব্যক্তির উপর নির্ভর করে .. আমি হতাশ হ'ল হতাশ হ'ল হ'ল হ'ল হ'ল হতাশা; অন্যথায় একটি বড় কোন। তারপরে আবার এই কারণেই আমি আইডিই কার্যকারিতাটি নির্বিচারে প্রয়োগ করতে পছন্দ করি।

Answer 13

"আমি এটি জানতে আগ্রহী যে এটি আসলে খারাপ অভ্যাস কিনা ..."

হ্যাঁ, এটির বদ অভ্যাস, ভেরিয়েবলের তালিকা অস্বাভাবিক দীর্ঘ হওয়া ব্যতীত। তবে সেক্ষেত্রে সমস্যাটি সম্ভবত ফাংশনের নকশার কারণে। কেন এমন একটি বস্তু পাস করবেন না যা অনেকগুলি পরামিতিগুলিকে আবদ্ধ করে?

"... এবং যদি তা হয় তবে আমি কীভাবে তাদের তা না করার জন্য প্ররোচিত করব?"

এগুলি বেঁধে রাখুন এবং যতক্ষণ না তারা এই জঞ্জালটি বন্ধ করতে রাজি হন ততক্ষণ তাদের টিকিয়ে রাখুন।

Comments

"কেন এমন একটি বস্তু পাস করবেন না যা অনেকগুলি প্যারামিটারকে আবদ্ধ করে?" ঠিক আছে, এখন আপনি সমস্যাটিকে সেই নতুন অবজেক্টে নিয়ে এসেছেন। এটি এখনও একই পরিমাণে প্যারামিটারের প্রয়োজন (উদাহরণস্বরূপ এটির নির্মাতার মাধ্যমে), সুতরাং আপনার এখনও একই সমস্যা রয়েছে।

— স্টিজন

Answer 14

আপনি কেন এইরকম তুচ্ছ উদ্বেগের উপর চক্র নষ্ট করছেন? কেবলমাত্র আপনার বিশ্বাসযোগ্য আইডিই চালু করুন, ফাইলটি খুলুন এবং পুনরায় ফর্ম্যাট করুন। ভাল খবর! এটি আপনি যা ফর্ম চান তা হবে।

এখন আসুন সত্যিকারের গুরুত্বপূর্ণ ইস্যুতে এগিয়ে যাওয়া যাক - vi বা emacs, LOL।

Comments

এবং তারপরে আপনি কখন এটি উত্স-নিয়ন্ত্রণে পরীক্ষা করতে এসেছেন?

— পিডিআর

Answer 15

আমি বলব, যদি যুক্তিগুলি একটি লাইনে ফিট করে তবে তা করুন। যদি তা না হয়, তবে প্রতি লাইনে একটি যুক্তি দুর্দান্ত পাঠযোগ্যতার জন্য তৈরি করে।

foo(arg1, arg2, arg3, arg4, arg5)

বনাম

foo(
    arg1=arg1,
    arg2=arg2,
    arg3=arg3,
    arg4=arg4,
    arg5=arg5,
    arg6=arg6,
    arg7=arg7
)

Comments

এই অফারটি কোন কিছুরই সৃষ্টি পয়েন্ট উপর সারগর্ভ বলে মনে হচ্ছে না এবং পূর্বে 14 উত্তর ব্যাখ্যা

— মশা