উন্নয়ন দলে বিভিন্ন কোডিং শৈলীর সমর্থন করার কোনও উপায় আছে কি?


13

সমস্যা: দু'টি বিকাশকারী => ইন্ডেনেশন সম্পর্কিত তিনটি মতামত, নতুন লাইনে ব্রাসেকশনগুলি না ইত্যাদি

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

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


1
বেশিরভাগ ভাষার জন্য স্বয়ংক্রিয় কোড ফর্ম্যাটর রয়েছে, তবে কিছু (যেমন সি ++) এর জন্য ভাষার পার্সিংয়ের জটিলতার কারণে তাদের পুরোপুরি নির্ভরযোগ্য করা অত্যন্ত কঠিন।
জোরিস টিমারম্যানস

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

8
হয়তো অন্যান্য অত্যন্ত সাধারণ মন্তব্যটি এখানে করা দরকার: কোড শৈলীতে পার্থক্য নিয়ে কি আসল সমস্যা আছে ? ভাঙ্গা না এমন কিছু ঠিক করবেন না!
জোরিস টিমারম্যানস

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

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

উত্তর:


20

না, আপনাকে একটি স্ট্যান্ডার্ড তৈরি করতে হবে। আপনার যদি টিমের সদস্য বি পরিবর্তন হয় (কোনও স্বয়ংক্রিয় আইডিই সরঞ্জাম সহ, অথবা ম্যানুয়ালি) কোড টিম সদস্য এ এর ​​একটি পুরো apੇਰ, লিখেছেন, এটি প্রতিশ্রুতিবদ্ধ হবে এবং পরিবর্তন হিসাবে প্রদর্শিত হবে।

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

একটি নিয়মিত কোডিং শৈলী থাকা প্রকল্পের রক্ষণাবেক্ষণে এবং কোডে কাজ করা নতুন লোকের প্রবেশের বাধা হ্রাস করতে সহায়তা করবে।


11

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


2
+1 টি। তাদের একটি চয়ন করতে দিন, তবে এটি প্রয়োগ করুন।
ক্লিমেন্ট হেরেমেন

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

4
এটি (কম-বেশি) অজগর ক্ষেত্রে, যেখানে ইন্ডেন্টেশন একটি ভাষার অর্থপূর্ণ।
ক্লিমেন্ট হেরেমেন

2
গো এই জাতীয়ভাবে কঠোরভাবে প্রয়োগ করছে না, তবে এটি একটি অন্তর্নির্মিত উত্স কোড ফরমেটার, সহ আসে go fmtGolangtutorials.blogspot.fr/2011/06/…
ক্লিমেন্ট হেরেম্যান

1
@JesperE যে হয় সঙ্গে পাইথন বাস্তবায়িত PEP8 এবং সংশ্লিষ্ট টুল, inventively নামে pep8
ফিহাগ

8

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

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

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

স্বয়ংক্রিয় কোড পুনরায় ফর্ম্যাটিংয়ের ব্যবহার সর্বনিম্ন রাখতে হবে (যদি সম্পূর্ণ নিষিদ্ধ না হয়) সাথে দুর্দান্ত কাজ করে।
গ্রাহাম্পার্কস

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

আমি মনে করি এই উত্তরটি আসলে "স্বয়ংক্রিয় বিন্যাস" প্রশ্নের অংশটি মিস করেছে?
জোরিস টিমারম্যানস

ফাইলগুলির মধ্যে বিভিন্ন ধরণের শৈলী কেবলমাত্র একটি সামঞ্জস্যপূর্ণ শৈলীর চেয়ে বেশি জটিল er
অ্যান্ডি

4

সংক্ষিপ্ত উত্তর হলো 'না.

কাজের ক্ষেত্রে বিশেষত সফ্টওয়্যার ডেভলপমেন্টের মতো জ্ঞান ভিত্তিক কাজের ক্ষেত্রে মতামতের মূল্যবান হওয়া উচিত, বিকাশকারীদের বুঝতে হবে যে একটি মতামত কেবল একটি মতামত এবং তারা সেখানে সফ্টওয়্যারটি লিখতে পারে যে কোন লাইন ইন্ডেন্টেশন মানটি সবচেয়ে ভাল তা নিয়ে তর্ক না করে write

স্ট্যান্ডার্ড ডকুমেন্টের লক্ষ্যটি হ'ল সাধারণ কোডিং মান / কনভেনশনগুলির একটি সেট প্রয়োগ / প্রস্তাব করা উচিত যা সম্বোধন করে

  1. লেআউট আইটেম যেমন ট্যাবিং, ইন্ডেন্টেশন, {এর ব্যবহার, (,
  2. পরিবর্তনশীল, অবজেক্ট এবং ফাংশন নাম যেমন ক্যামেলকেস, হাঙ্গেরিয়ান স্বরলিপি
  3. এটি কখন / কখন / কোথায় করা হবে তা হ্যান্ডলিং
  4. কোড মন্তব্য। আপনি কি সবসময় কোনও ডিজাইন ডক, একটি বাগ নম্বর ইত্যাদি উল্লেখ করেন?

স্ট্যান্ডার্ড ডকুমেন্টগুলি কনডাকশনগুলিতে কোডটি পড়া সহজ, বজায় রাখা এবং সামঞ্জস্যপূর্ণ তা নিশ্চিত করতে সহায়তা করে।

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

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


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

4

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

তবে , এখানে একটি বড় সমস্যা রয়েছে: স্বয়ংক্রিয় কোড ফর্ম্যাটিং সরঞ্জামগুলি 100% নির্ভরযোগ্য নয়। সুতরাং, আপনি আসলে এই সিস্টেমের সাথে আপনার কোডে সমস্যাগুলি পরিচয় করিয়ে দিতে পারেন। মনে মনে, ধারণাটি মেরে ফেলেছে। সঠিকভাবে স্টাইলড কোডের চেয়ে ফাংশনাল কোড থাকা সবসময় বেশি গুরুত্বপূর্ণ!

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

স্ট্যাক ওভারফ্লো সম্পর্কে এখানে একই আলোচনা


2
লিঙ্কযুক্ত আলোচনায় গৃহীত উত্তরটিও নোট করুন!
জোরিস টিমারম্যানস

1

একমুখী স্বয়ংক্রিয়ভাবে পুনরায় ফর্ম্যাট কোডটি যদি একটি কার্যক্ষম সমাধান হতে পারে তবে:

  1. এমন একটি অটোফরমেটার সন্ধান করুন যা আপনি বাস্তবায়িত করতে চান কনভেনশন এবং আপনার প্রোগ্রামিং ভাষার জন্য আসলে কাজ করে।
  2. এটি পূর্ব-প্রতিশ্রুতিবদ্ধ করতে পারে যাতে রিফর্ম্যাটেশন পরিবর্তনের লগে মিশ্রিত না হয় এবং প্রকৃত কার্যকরী পরিবর্তনগুলি থেকে পৃথক হয়।
  3. কোন দলকে কোন কনভেনশন প্রয়োগ করা উচিত সে বিষয়ে আপনার দলকে সম্মতি জানাতে পরিচালিত করুন (কারণ সাধারণত বলতে গেলে কোনও বিকাশকারীর ব্যক্তিগত পছন্দকে চেক-আউট করার কোনও "উপায়" নেই, আমি জানি না।

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


1

একেবারে আপনি পারেন এটি ছোট ছোট জিনিস ঘাম না করা সম্পর্কে।

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

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

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

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