সংগঠনগুলিতে কোডিং শৈলী কি একটি optionচ্ছিক জিনিস?


30

এই প্রোগ্রামিং স্টাইল ডকুমেন্টটির একটি সাধারণ নিয়ম রয়েছে, যা বলে:

তাদের বিরুদ্ধে কঠোর ব্যক্তিগত আপত্তি থাকলে নিয়ম লঙ্ঘন করা যেতে পারে।

এটি আমি যেভাবে ভাবছি তার সাথে এটি সংঘর্ষিত হয়েছে এবং অনেক নিবন্ধ রয়েছে যে কোডিং শৈলীটি আসলে গুরুত্বপূর্ণ। উদাহরণস্বরূপ এটি বলেছেন:

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

সুতরাং, আমি কি এই দস্তাবেজ এবং এই প্রশ্নের শীর্ষে থাকা উদ্ধৃতি থেকে কিছু ভুল বুঝছি? লোকেরা কি কেবল কোডিং শৈলীতে উপেক্ষা করতে পারে?


সম্ভবত আমি যথেষ্ট পরিষ্কার ছিল না, তাই এই সম্পাদনাটি দিয়ে, আমি কিছুটা স্পষ্ট করতে যাচ্ছি।

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

তবে তারপরে, উক্তিটি যদি সঠিক হয় তবে কোডিং স্টাইল ডকুমেন্টটি কী ব্যবহার করতে পারে, যদি কেউ যা খুশি তাই করতে পারে?


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

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

আপনি যে স্টাইল ডকটি সংযুক্ত করেছেন সেটি হ'ল "একটি" প্রস্তাবিত কোডিং স্টাইল ডক; এটি "দ্য" স্টাইল ডক নয় আপনি যদি নিজের সাইটের ডক তৈরি করেন তবে এটি যতটা ভাল ফিট হয় ততক্ষণ এটিকে ব্যবহার করুন। যদি আপনার আপত্তি থাকে তবে সে অনুযায়ী আপনার ডকটি পরিবর্তন করুন । উদাহরণস্বরূপ, আপনার পছন্দ নয় এমন বিবৃতি ছেড়ে দিন।
ব্যবহারকারী 2338816

"তাদের বিরুদ্ধে কড়া ব্যক্তিগত আপত্তি থাকলে নিয়ম লঙ্ঘন করা যায়।" কখনও কখনও এটি একটি রাজনৈতিক বিবেচনা: প্রথম পর্বটি অপ্ট-ইন হয়। এটি ছাড়াই কোনও পুরানো-স্কুল প্রবীণ সহকর্মী কোডের মান সম্পর্কে ধারণাটি পুরোপুরি মেরে ফেলবেন।
brian_o

উত্তর:


12

যতদূর আমি বলতে পারি, যে বিবৃতি আপনাকে বিভ্রান্ত করেছে তা হ'ল নির্দেশিকাগুলি যথাসম্ভব প্রশস্ত পরিবেশন করার জন্য তৈরি করা একটি বাস্তববাদী সমঝোতা। আপনার নির্দিষ্ট প্রসঙ্গে উপর নির্ভর করে (নীচে তার আরও) আপনার এটিকে সামঞ্জস্য করতে এবং নির্দেশিকাগুলির আরও দক্ষতার সাথে ব্যবহার করার বিকল্প থাকতে পারে।

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

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

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

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

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

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

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


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

আপনি যদি আপনার বিকাশের কাজের প্রবাহে অনেকগুলি বাধা না দিয়ে এই প্রক্রিয়াটিকে কাজ করার কোনও উপায় মনে করেন তবে বিশৃঙ্খলা "যদি আপনি যথেষ্ট জোরে কান্নাকাটি করেন তবে লঙ্ঘন করুন" এর পরিবর্তে একটি আনুষ্ঠানিক এবং চ্যালেঞ্জ / রেজোলিউশন পদ্ধতির ট্র্যাক করা সহজ worth


পার্শ্ব নোট হিসাবে, আপনি অন্য একটি মন্তব্যে যা লিখেছিলেন তা আমি সম্বোধন করতে চাই , "ধরে নিন যে কোডিং শৈলী আদর্শ, এবং যদি তা না হয় তবে ইত্যাদি।"

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


এটিকে এভাবে রাখা যাক: আমাদের দলটি ছোট, এবং আমাদের প্রক্রিয়াতে আমার মনিবের উপরে কাউকে অন্তর্ভুক্ত করা হয় না (যা কেবল একটি দলের নেতা)। সুতরাং, আপনার উপরে উল্লিখিত গেমগুলি ঘটবে না।
BЈовић

@ BЈовић যে ক্ষেত্রে চ্যালেঞ্জ / রেজল্যুশন পদ্ধতির মধ্যে একটি স্পষ্ট বিজয়ী দেখায়
মশা

53

ব্যক্তিগত পছন্দের কারণে কোডিং শৈলীর উপেক্ষা করার অনুমতি দেওয়া একটি খারাপ ধারণা।

আপনার প্রশ্নের উদ্ধৃতিটি কোনও বিকাশকারীকে সহজভাবে বলতে দেওয়ার অনুমতি দেয় বলে মনে হচ্ছে "আমি এই স্টাইলটি ব্যবহার করব না কারণ এটি আমার পছন্দ নয়" "

এটি পুরো পয়েন্টের বিপরীতে চলেছে, যা ধারাবাহিকতা এবং পঠনযোগ্যতার জন্য দলের প্রত্যেককে একইভাবে জিনিসগুলি পাচ্ছে।

আমি সম্মত হই যে এই জাতীয় বিবৃতি সহ একটি শৈলী নথি সম্ভবত অর্থহীন।

তবুও, শৈলী নির্দেশিকাগুলি মেনে চলার ক্ষেত্রে কিছুটা নমনীয়তা বাঞ্ছনীয়:

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

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


4
এটি বলাই ভাল হবে যে যদি নিয়ম ভাঙার উপযুক্ত কারণ থাকে তবে সেগুলি ভঙ্গ করুন। সমস্ত ভাল কারণ তালিকাভুক্ত করা অসম্ভব তবে আমি পরামর্শ দিচ্ছি যে নিছক ব্যক্তিগত পছন্দ এক নয়। পাইথন শৈলী গাইড যখন আপনি নিয়ম ভঙ্গ করা উচিত একটি চিন্তাশীল অধ্যায় আছে।
মাইকেল হফম্যান

1
অটোমেটেড স্টাইলের নিটপিক চেকিং দরকারী হতে পারে: তবে কেবলমাত্র সমস্ত প্রস্তাবিত পরিবর্তনগুলি প্রয়োগ করার জন্য একটি সহজ বোতামের সাথে একত্রিত হলে এবং "কোনও কারণেই আমি সেই নিয়মটি ভেঙেছি না" বলার উপায়। আপনার প্রক্রিয়া স্তরের উপর নির্ভর করে উত্তরোত্তর এমন কিছু হতে পারে যা কোড পর্যালোচনা / ইত্যাদি ক্ষেত্রে ন্যায়সঙ্গত হওয়া দরকার।
ড্যান নীলি

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

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

2
কয়েক বছর ধরে আমি এই সিদ্ধান্তে পৌঁছেছি যে স্টাইল গাইডের একমাত্র সত্যিকারের দরকারী অংশটি সঠিকভাবে কোডটি ইনডেন্ট করা। এমনকি আপনার সমস্ত ইনডেন্ট একইভাবে প্রয়োজন নেই - ঠিক সঠিকভাবে ইনডেন্ট করুন। আমি যে স্টাইল গাইডগুলি লিখেছি সেগুলিতে সাধারণত 3 টির বেশি নিয়ম থাকে না (সাধারণত কেবলমাত্র একটি নিয়ম - সঠিকভাবে ইনডেন্ট যাতে এটি দেখতে খারাপ না লাগে)। যদি আমি কোনও দোকানে andুকে দেখি এবং কোডটি ইতিমধ্যে ঠিক আছে দেখছে তবে আমি কোডিং শৈলীর প্রয়োজনেরও সুপারিশ করি না।
slebetman

13

কোডকে আরও পঠনযোগ্য করে তুলতে কোডিং স্টাইল এবং স্টাইল গাইড উপস্থিত রয়েছে। জটিলতার সাথে সহায়তা করার জন্য পাঠযোগ্যতা বিদ্যমান।

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

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

কোনও বোকা কোড বুঝতে পারে এমন একটি কোড যা কম্পিউটার বুঝতে পারে। ভাল প্রোগ্রামাররা কোড লিখেন যা মানুষ বুঝতে পারে। - মার্টিন ফওলার, ২০০৮


আপনার উত্তর হ্যাঁ বা কোনও পরিষ্কার নয়। সুতরাং, আপনি কি বলছেন যে এটি সত্যিই alচ্ছিক? বিশ্রামের সাথে - আমি সম্মত
BЈовић

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

3
@ বিЈовић বিশ্বাসঘাতক মূলত যা বলছে তা হ'ল আপনার ভুল ফোকাস। বিধিগুলি যাদু নয়। আপনি নিয়মের একটি সেটকে কঠোরভাবে মেনে চলার মাধ্যমে যাদুকরিভাবে সবকিছুকে আরও উন্নত করতে যাচ্ছেন না। সুতরাং আপনাকে ভাবতে হবে, "এই বিধিগুলি কী সম্পাদন করার কথা?" পরিবর্তে, এবং আপনি পরিবর্তে যে লক্ষ্য দিকে কাজ । নিয়মগুলি আপনাকে জানিয়ে দেয় যে আপনার ডিফল্টটি কী হওয়া উচিত; যদি নিয়ম অনুসরণ করে তাদের লক্ষ্যটি অর্জনের লক্ষ্যে কার্যকর হয় তবে তারা সে ক্ষেত্রে অনুসরণ করার মতো নয় ।
jpmc26

6

সংগঠনগুলিতে কোডিং শৈলী কি একটি optionচ্ছিক জিনিস?

সংস্থাগুলি কোডিং স্টাইলগুলি বেছে নেয় - প্রথম স্থানে থাকার কোনও প্রয়োজন নেই।

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

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

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


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

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

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

3

সুতরাং, আমি কি এই দস্তাবেজ এবং এই প্রশ্নের শীর্ষে থাকা উদ্ধৃতি থেকে কিছু ভুল বুঝছি? লোকেরা কি কেবল কোডিং শৈলীতে উপেক্ষা করতে পারে?

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

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

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

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


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

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

@ ড্যান 1111 - নিশ্চিত? আমি বোঝাতে চাইছি তারা সম্ভবত "আপনার সতীর্থদের ছেড়ে দেবেন না" তেড়ে উঠতে পারেন তবে নথি এবং প্রকাশনা সম্পর্কে প্রশ্নটি বিশেষভাবে জিজ্ঞাসা করেছিল।
টেলাস্টিন

2

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

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

লক্ষ্যটি হ'ল প্রত্যেককে সামান্য বিস্তৃত বিবরণ এবং ব্যাখ্যার পরিবর্তে কোডিং গাইডলেন্সের চেতনায় জড়িত হওয়া should

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


সুতরাং, আপনার পরামর্শটি হ'ল জেনকিন্সে একটি চাকরী স্থাপন করা, যা কেউ কিছু পরীক্ষা করার সাথে সাথেই ফাইলটির পুনরায় ফর্ম্যাট করতে চলেছে? বিটিডব্লিউ "উইগল রুম" হ'ল আমি এই উত্তরের মতো কিছু অনুমানের অনুমান করছি ।
BЈовић

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

2

আপনার সম্পাদনাগুলির ভিত্তিতে, আপনার সঠিক লক্ষ্যের জন্য লক্ষ্য।

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

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

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

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

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


0

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

এটাও লক্ষ করা উচিত যে হ্যাটারিয়ার কোড মানক প্রয়োগের নীতিগুলি সাধারণত জিনিস এখন যেভাবে করা হয় তা নয়।

পুরানো দিনগুলিতে, আপনি কেবল বিকাশকারীদের ডেস্ক এবং উদ্ধৃতি অধ্যায় এবং শ্লোকের শেষে টোমটি ধরে রেখেছিলেন কেন তার কোডটি 34.5.5767 ধারা লঙ্ঘন করছে।

আমাদের কাছে এখন স্ট্যাটিক কোড বিশ্লেষণ এবং অটো-ডকুমেন্টেশন সরঞ্জাম রয়েছে যা কোড মানককে অনেক দূরে নিয়ে যায়।

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


ধরে নিন যে কোডিং শৈলীটি আদর্শ, এবং যদি এটি না হয় - তবে লোকেরা এটি পরিবর্তন করতে পারে। এমনকি এই ক্ষেত্রে লোকেরা কি এটিকে উপেক্ষা করার অনুমতি দেয়?
BЈовић

বলা মুশকিল - বিশেষত যদি সামগ্রিক sensক্যমত্য না হয়। আমার ধারণা বিকাশকারী জ্যেষ্ঠতা এবং / বা মধ্যস্থতা এখানে কার্যকর হবে ...
রবি ডি

0

আপনার প্রশ্ন দুটি উদ্ধৃতি পুনরায় মিলনের চারপাশে centers আমি বিশ্বাস করি বিশ্বাসঘাতক যা লিখেছেন তা আপনার প্রশ্নের উত্তর সাধারণত দেয়। এটি শৈলীর নির্দেশিকাগুলি লেখার ক্ষেত্রে আপনার গাইডিং নীতি উপস্থাপন করে।

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

সুতরাং আপনি এই দুটি আপাত দ্বন্দ্বের মত পুনরায় সমন্বয় করতে পারেন:

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

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


0

কোডিং শৈলীর লোকেরা যতটা কোডিং স্টাইল রাখে ততক্ষণ তা বেশি গুরুত্ব দেয় না। যদি কোনও সংস্থা কোডিং শৈলীতে জোর দেয় তবে তারা প্রায় 49% তাদের বিকাশকারীর পায়ের আঙ্গুলগুলিতে প্রচুর পদক্ষেপ নেয়।

সমস্যাটি হ'ল বিপুল সংখ্যক বিকাশকারী তাদের কোডিং শৈলীর কোনও সংস্থার প্রচলিত মানের সাথে খুব বেশি মানিয়ে নেওয়ার বিষয়ে কিছু মনে করেন না, তবে তারা যারা কোম্পানির রাজনীতিতে আরও ভাল (বা কেবল আরও যত্নশীল হন) তাদের দ্বারা বলা খুব খারাপ মনে করে।

এর অর্থ কোডিং শৈলীর মান তৈরি করা সময়ের অপচয়, অন্তহীন যুক্তির উত্স, অসীম বিরক্তির কারণ এবং সামগ্রিকভাবে সময় এবং শক্তির বিশাল ড্রেন হতে পারে।


0

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

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

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

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

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

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

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

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

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

( অস্বীকৃতি: আমি একটি সাধারণ কাজটি সমাধান করার জন্য এই বাস্তবায়নটি সম্পূর্ণভাবে লিখেছি is_base_ofএবং এটি সিনিয়র বিকাশকারীদের কাছ থেকে পেয়েছি এবং এর জন্য প্রতিটি নরক অর্জন করেছি I আমি বলেছি এটি মূল্যবান। আমি এখনও প্রতিবারই হাসির এক মাতাল বুদবুদ পাই I সেই প্যাটার্নটি কীভাবে সি ++ স্পেসিফিকেশনের 7 টি সম্পর্কযুক্ত অংশের মতো একসাথে আশ্চর্যজনক কিছু করার জন্য দেখুন you boostএটি প্রবীণ বিকাশকারীরা নিন! আপনি এই নির্দিষ্ট প্রকল্পে নিষেধাজ্ঞার জন্য যা পেয়েছেন ! )


-1

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

কোডটির সদ্য নির্মিত বিভাগে ফর্ম্যাটরটি প্রয়োগ করার অভ্যাসটি বিকাশ করা সমস্ত বিকাশকারীদের কাছ থেকে নেওয়া সম্পূর্ণ যুক্তিসঙ্গত।

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

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

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


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

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

-1

আসল সমাধান (শুধু দর্শন নয়)

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

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

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