আমাদের কি কোডিং শৈলীর বিকাশকারীদের স্বায়ত্তশাসনের পক্ষে উত্সাহ দেওয়া উচিত বা ধারাবাহিকতার পক্ষে নিরুৎসাহিত করা উচিত?


15

একজন বিকাশকারী if/elseএক-লাইন কোড স্টেটমেন্ট সহ ব্লকগুলি লিখেন যেমন:

if (condition)
   // Do this one-line code
else
   // Do this one-line code

আরেকটি তাদের সবার জন্য কোঁকড়ানো ধনুর্বন্ধনী ব্যবহার করে:

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

একজন বিকাশকারী প্রথমে কোনও বস্তুকে ইনস্ট্যান্ট করে, তারপরে এটি ব্যবহার করে:

HelperClass helper = new HelperClass();
helper.DoSomething();

অন্য বিকাশকারী এক লাইনে অবজেক্টটি ইনস্ট্যান্ট করে এবং ব্যবহার করে:

new HelperClass().DoSomething();

একজন বিকাশকারী অ্যারে এবং forলুপগুলির সাহায্যে আরও সহজ :

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

আরেকজন লিখেছেন:

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

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


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

ধারাবাহিক শৈলী পাঠ কোড সহজ করে তোলে, সুতরাং একটি সামঞ্জস্যপূর্ণ শৈলী ব্যবহার করুন। আপনার উদাহরণগুলিতে, পড়ার পক্ষে সহজতমটি হ'ল ২, ১, ২. যদিও শেষ কেসটি ভিন্ন। কর্মক্ষমতা সমালোচনামূলক অ্যাপ্লিকেশনগুলিতে তালিকার উপরে পুনরাবৃত্তি করার সময় লুপের জন্য দ্রুত হয়। পারফরম্যান্স অ্যারেগুলিতে অভিন্ন পুনরাবৃত্তি। এবং সমস্ত ক্ষেত্রে varপুরোপুরি যোগ্য টাইপের নামের পরিবর্তে ব্যবহার করুন।
স্টিফেন

উত্তর:


19

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

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

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

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

  • সভার শেষে কোনও সিদ্ধান্ত না নিলে ম্যানেজার সিদ্ধান্ত নেবেন।
  • সভাটি দুই ঘন্টা পরে শেষ হবে, বা যখন কেউ চিৎকার করে বা কান্নাকাটি শুরু করে, প্রথমে যেই আসে।
  • পুরো স্ট্যান্ডার্ডটি (যুক্তিসঙ্গত ধরণের আকারে!) একটি শিট বা দুটি কাগজের কাগজে ফিট হবে, কেবলমাত্র যদি প্রয়োজন হয় তবে ডাবল-পার্শ্বযুক্ত।

কাউকে গ্রহণ করার কথা বিবেচনা করুন | অন্যের | স্ট্যান্ডার্ডগুলি হয় আপনার নিজের কোডিং স্ট্যান্ডার্ড মিটিংয়ের সূচনা পয়েন্ট হিসাবে বা পুরোপুরি সভাটিকে এড়িয়ে যাওয়ার উপায় হিসাবে।

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

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

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

প্রতিটি ক্ষেত্রে (এবং আরও অনেক) একজন উপযুক্ত অনুশীলনকারী সহজেই "কোড" বুঝতে পারতেন যা প্রত্যাশিত মানটিকে পূরণ করে না। এতগুলি শিল্প কেন নথিগুলির জন্য বিশদ প্রয়োজনীয়তা রচনা করে যেতে থাকে যা সংকলক দ্বারা বিশ্লেষণের প্রয়োজন হয় না? কারণ শৈলী গুরুত্বপূর্ণ । একটি স্ট্যান্ডার্ড স্টাইলে তথ্য উপস্থাপন পাঠককে সম্পূর্ণ সামগ্রীতে ফোকাস করতে দেয়, পড়া দ্রুততর করে এবং বুঝতে সহায়তা করে এবং ত্রুটিগুলি হ্রাস করে।


1
আপনি যদি আপনার পোস্টে লেটিং সরঞ্জামগুলির ব্যবহার যুক্ত করেন, আমি আমার এবং আপনার +1
মুছব

@ ডেমিয়ানব্রেচট, ভাল পরামর্শ, ধন্যবাদ। আমার উত্তরকে উন্নত করতে লিন্ট সরঞ্জামগুলি যুক্ত করা হয়েছে, তবে আমি মনে করি আপনারও আপনার উচিত।
কালেব

ঠিক আছে তাহলে। যাইহোক +1 :)
ডেমিয়ান ব্রেচেট

এবং আপনিও!
কালেব

আমার অভিজ্ঞতার মতো "... ... তাত্ক্ষণিকভাবে স্থানান্তর ..." এর জন্য +1 যেমন আচরণটি সোসাইওপথ এবং / অথবা নারকাসিস্টিক প্রবণতাগুলির সাথে সামঞ্জস্যপূর্ণ, সফ্টওয়্যার বিকাশকারী দলের সাথে বেমানান।
mattnz

16

স্টাইল কিছু যায় আসে না।

সেখানে, আমি এটা বলেছি।

30 বছর পরে এবং শত শত ক্লায়েন্ট সাইটগুলি এবং সেই বছরগুলিতে 500 (বা আরও) টিমের সদস্যদের (অনুমানের) কোডের পরে, আমি খুঁজে পেয়েছি যে স্টাইলটি কোনও বিষয় নয়।

প্রথমে এটি কাজে লাগান।

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

সমস্ত কিছু সমাধানের পরে "স্টাইল" এর উপর ঝাঁকুনি । শুধুমাত্র সরঞ্জাম দিয়ে "স্টাইল" এর উদ্বেগ, ম্যানুয়ালি কখনও।


2
আমেন! কোডিং মানগুলি সত্যিকারের সুবিধার ক্ষেত্রে ন্যায়সঙ্গত হওয়া দরকার এবং ধারাবাহিকতা একটি আসল সুবিধা নয়, তবে একটি বিলাসিতা।
জনএফএক্স

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

6
তবে এটি '==' এর পরিবর্তে '=' এড়াতে সহায়তা করে (শর্তের মধ্যে অ্যাসাইনমেন্ট ব্যবহার করবেন না)। এটি if (t) { x;y;}বরং এড়াতে সহায়তা করে if (t) x;y;(সর্বদা যদি '{}' পরে থাকে তবে)। কনস্টের সঠিক কোডটি পছন্দ করুন (লেখার পরে কোডে কনস্টের যথার্থতা যুক্ত করা খুব কঠিন st std :: cout / std :: cin ব্যবহার না করে প্রিফিন্টফ / স্ক্যানফ প্রাক্তন ত্রুটি হওয়ার সম্ভাবনা বেশি থাকে। অ্যারেগুলির পরিবর্তে ভেক্টর ব্যবহার করুন (সাহায্য করতে ওভারফ্লো প্রতিরোধ)।
মার্টিন ইয়র্ক

5
এটিকে কাজে লাগানো স্পষ্টতই सर्वोपरि। তবে এটি কাজ করে বলে এর অর্থ এটি হয়ে গেছে। এটিও পরীক্ষা করা দরকার। এবং তারপর পর্যালোচনা। যে সমস্ত কয়েক দিন সময় নিতে পারে। তারপরে বছরের পর বছর ধরে এটি পড়তে হবে এবং বুঝতে হবে এবং বজায় রাখতে হবে। দরকারী কোড (অন্য কোনও ধরণের কেন লিখবেন?) এর লিখিত চেয়ে অনেক বেশি বার পড়া হবে , সুতরাং এটি পড়তে ও বুঝতে সহজ করে ভবিষ্যতে উত্পাদনশীলতার উন্নতি করে। সংগঠন জুড়ে ধারাবাহিক স্টাইল ব্যবহার করা সেই সম্মানের ক্ষেত্রে সহায়তা করার এক উপায়।
কালেব

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

4

কোডিং শৈলী আছে এবং কোডিং গন্ধ আছে। এটি আমি একবার খুঁজে পেয়েছি না:

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

আমার পূর্ববর্তী নিয়োগকর্তা if()বন্ধনী ছাড়াই মাল্টলাইন ব্যবহার করে কঠোরভাবে নিষেধ করেছেন । এটি "আবার এটি করুন এবং আপনি বরখাস্ত" টাইপ ত্রুটি হিসাবে বিবেচিত হয়েছিল। অনুমোদিত কনস্ট্রাক্টস ছিল

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

এটি উপরে যেমন দেখায় ঠিক তেমন একটি ত্রুটির ফলে ঘটেছিল, যা পোর্টালের মূল পৃষ্ঠাটি থামাতে কয়েক ঘন্টা সময় নেয়।

এমন কিছু জিনিস রয়েছে যা আপনার সর্বদা করা উচিত। পছন্দ switch():

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

এদিকে, টাইপ করা:

     case 1:
         something();
     case 2:
         something();
     break;

একটি বন্ধ না করেই caseসঙ্গে //fallthroughএকটি বাগ বিবেচনা করা হয়।

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


3

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

এই নকশাটি আমাকে অন্যান্য বিকাশকারীদের কাছে প্রয়োগের বিবরণ জমা দেওয়ার অনুমতি দেয়। পুরো সিস্টেমের নকশা তৈরি করার পরিবর্তে তারা শূন্যস্থান পূরণ করছে।

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

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


3

এটি নির্ভর করে ...

আপনার প্রথম দুটি উদাহরণ আমার কাছে ব্যক্তিগত স্বাদের বিষয় নয়।

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(বন্ধনী ছাড়াই) = আরও বাগ-প্রবণ, যদি আরও কোড পরে যুক্ত করা হয়:

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

এবং এটি ডিবাগ করার পক্ষে কম সুবিধাজনক:

new HelperClass().DoSomething(GetSomeData()); // etc.

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

আপনার তৃতীয় উদাহরণ হিসাবে (বনাম foreach জন্য), আমি এটি স্বাদের বিষয় হিসাবে দেখতে।


2

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


2

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


2

একটি শিল্প স্ট্যান্ডার্ড আবরণ সরঞ্জাম (দৃশ্যত সি # এর জন্য FxCop ) ব্যবহার করুন। যদিও এটা শেষ সব না হতে-সব, দৃঢ়তা হয় বড় বড় প্রকল্পের তাদের উপর কাজ মানুষের একটি নম্বর আছে গুরুত্বপূর্ণ।

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

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


1

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


1

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


1

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

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


1

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

if() {}
else() {}

অথবা এমনকি:

if() {} else () {}

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

Object.method();
Object.method2();

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

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


1

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

অন্যান্য দলের সদস্যদের কোডের সাথে কাজ করার পরে, কখনও কখনও কয়েক মাসের জন্য সামান্য সময়ের জন্য, এটি মূলত ইন-লাইন লাইনে কাজ শুরু করে git blame। আমার কোম্পানিতে 10+ বছর থাকার পরে, আমি সম্ভবত আপনাকে 80% + নির্ভুলতার সাথে বলতে পারি যিনি আমাদের দেওয়া 500k কোডের লাইনে কেবল যে কোনও শ্রেণি লিখেছিলেন, কেবল তা দেখে।

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

ফরমেটারের মাধ্যমে প্রত্যেকের কোড চালানো এই তথ্যটি মূলত এটিকে ছড়িয়ে দেয়, এটি কোনও এর পিছনে লুকিয়ে রাখে git blame, যা আপনি চালানোর পক্ষে বিরক্ত করবেন না।


0

এটি সত্যই প্রতিষ্ঠানের ধরণের উপর নির্ভর করে।

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

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

আপনারা অনেকেই, "তবে অপেক্ষা করুন, কেন বি এবং সি প্লেয়ারদের সাথে দূরে থাকবেন না?"

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

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