কোডিং স্ট্যান্ডার্ডগুলিতে কি খুব বেশি ইউনিফর্ম থাকতে পারে?


12

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

উদাহরণস্বরূপ ifএকাধিক লাইনে বনাম এক লাইনে স্টেটমেন্ট লেখার জন্য সি # ??নাল-কোয়েলসিং অপারেটরটি ব্যবহারের পরিবর্তে == null, ইনডেন্টেশনের জন্য ব্যবধানের পরিমাণ ইত্যাদি ব্যবহার করে

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


2
হাই গ্র্যাজি, প্রোগ্রামার্স.এসই কোনও আলোচনা বোর্ড নয় ; আপনি যে সমস্যার মুখোমুখি হতে পারেন তা সমাধান করার জন্য আমরা এখানে আছি। আপনি কী সমাধান করার চেষ্টা করছেন এমন কোন সমস্যা আছে? যদি তা হয়, তবে আপনি উত্তরটি গঠনমূলক এবং আলোচনার ঝুঁকির বাইরে রাখতে আপনার প্রশ্নটির পুনরাবৃত্তি করতে পারেন?

1
@ গ্র্যাটিজি অন্যভাবে বলার জন্য, আপনি ব্যক্তিগতভাবে যে পরিস্থিতির মুখোমুখি হচ্ছেন সেই পরিস্থিতিতে, সঠিক উত্তরের মাপকাঠি কী হবে?

2
@ মার্ক ট্র্যাপ এফএকিউ অনুসারে এগুলি একটি প্রশ্নের মানদণ্ড যাবতীয় বিষয়গত প্রশ্ন গঠনমূলক বলে আশা করা যায়। আমরা কীভাবে এটি সংজ্ঞায়িত করব? গঠনমূলক সাবজেক্টিভ প্রশ্নসমূহ… 1. উত্তরগুলি অনুপ্রেরণা দেয় যা "কেন" এবং "কীভাবে" ব্যাখ্যা করে। ২. উত্তর দীর্ঘ, সংক্ষিপ্ত নয়। ৩. গঠনমূলক, ন্যায্য এবং নিরপেক্ষ স্বন রয়েছে। ৪. মতামতের উপর ভাগ করে নেওয়ার অভিজ্ঞতাগুলিকে আমন্ত্রণ জানান। ৫. মতামতকে তথ্য ও তথ্যসূত্রের সাথে সমর্থন জানানো উচিত। । এগুলি মূর্খ সামাজিক মজাদার চেয়ে বেশি। আমি বিশ্বাস করি আমার প্রশ্নটি খুব কম সময়ে প্রথম 4 টি জুড়েছে
Gratzy

2
@ গ্রেজিও এফএকিউ থেকেও: "আপনার মুখোমুখি প্রকৃত সমস্যার উপর ভিত্তি করে আপনার কেবল ব্যবহারিক, উত্তরযোগ্য প্রশ্ন জিজ্ঞাসা করা উচিত Chat

2
@ মার্ক ট্র্যাপ আমি ইতিমধ্যে একটি গ্রহণযোগ্য উত্তরের জন্য মানদণ্ড বর্ণনা করেছি এবং হ্যাঁ যেহেতু আমি বলেছি এটি একটি আসল সমস্যা এবং প্রশ্নে আগ্রহ এবং আমি যে উত্তরগুলি বলব তাতে অন্যেরা সম্মত হবেন তা থেকে খুব স্পষ্টভাবেই।
গ্র্যাটিজি

উত্তর:


16

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

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


1
আমি সেখানে ছিলাম

+1, যা আমি বলতে চেয়েছি, তবে আরও ভাল!
হতাশ

@ পিয়ার হ'ল আপনি এখন ফ্রিল্যান্স কেন? :)
নিকোল

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

7

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

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


হ্যাঁ, আপনি সম্ভবত কোথাও একটি পিপীলিকা স্ক্রিপ্ট আটকে থাকতে পারে।
মাইকেল কে

1
অন্ততপক্ষে, ইন্টেলিজির কাছে চেকইনের আগে কোডটি পুনরায় ফর্ম্যাট করার বিকল্প রয়েছে।
নিকোল

3

ওভার-ইউনিফিনিটির একটি ক্ষেত্রে আমি দেখেছি একটি একক মান যা যথাযথতা নির্বিশেষে সমস্ত প্রোগ্রামিং ভাষার ক্ষেত্রে প্রযোজ্য:

  • নিরুৎসাহিত gotoছাড়া C- এর মতো ভাষায় এমনকি try... catch
  • ব্যবহার InitialCapsনামগুলি জাভাস্ক্রিপ্ট মধ্যে যেখানে মানক লাইব্রেরী (Microsoft এর MFC এবং C # হিসেবে) initialLowerCase

2

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


2
@ টুগানো আমি আরও একমত হতে পারি না। কোডিং স্ট্যান্ডার্ডগুলির প্যারাডক্সটি হ'ল তারা যথেষ্ট মূল্যবান তবে তারা বিতর্ক করার পক্ষে মূল্যবান নয়।
চার্লস ই। গ্রান্ট

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

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

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

1
আমি আমাদের জার্মান টিমের কোড, বেশ কয়েকটি ওএসএস প্রকল্প এবং কিছু প্রাচীন কোড পাশাপাশি আমাদের বর্তমান স্টাফ নিয়ে কাজ করি। কিছু সি, কিছু সি ++, কিছু সি # # তাই আমাকে সর্বদা বেশ কয়েকটি বিবিধ কোড শৈলীর সাথে কাজ করতে হবে। যখন আপনি এটি করেন, আপনি বুঝতে পারেন যে স্ট্যান্ডার্ড নির্দেশিকা যে মানগুলিতে বাধ্যতামূলক হয় how আমি যদি অন্য এক প্রকল্পে স্যুইচ করতে পারি তবে আমি কাউকে different different আলাদা জায়গায় রাখার বিষয়টি পরিচালনা করতে পারি। এ কারণেই আমি মনে করি যে 1 টি নিয়ম সহ একটি অভিশাপের মূল মানটি হ'ল: "প্রতিটি প্রকল্পের মধ্যে ধারাবাহিকতা"।
gbjbaanb

2

ইউনিফর্মটির জন্য আমার 2 টি যুক্তি রয়েছে:

  • সম্মিলিত মালিকানা প্রচার করা। পরিবর্তনের ফলে কারও "বাচ্চা" ক্ষতিগ্রস্থ হতে চলেছে এমন আশঙ্কা ছাড়াই যে কেউ অন্য কারও কোড সম্পাদনা করতে পারে। এক ধরণের "আমরা সকলেই একসাথে" মানসিকতা।

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

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