নিয়মিত কোনও সংগ্রহস্থলে কোড ফরম্যাটারগুলি চালানো কি খারাপ ধারণা হবে?


68

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

অটোফর্মেটর ব্যবহার করে এমন বেশিরভাগ প্রকল্পগুলি এগুলিকে গিট হুকের মধ্যে রাখে তবে প্রতি কয়েক ঘন্টা স্বয়ংক্রিয়ভাবে এটি করা প্রতিটি গিটার হুক ইনস্টল করার জন্য বোঝা সরিয়ে ফেলবে।

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


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

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

13
আমার একটি অটোফর্মেটর সঠিকভাবে আপডেট না হওয়া এবং আমার কোড ভঙ্গ করা নিয়ে সমস্যা হয়েছে। কিছু মনে রাখবেন।
isaacg

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

18
যদি আপনার লক্ষ্য মানুষকে ঘৃণা করতে পারে তবে এটি একটি দুর্দান্ত ধারণা। এটি খুব অল্প অর্জন করেছে তবে অবশ্যই অপ্রত্যাশিত সমস্যা সৃষ্টি করবে।
টনিকে

উত্তর:


130

দুর্দান্ত লাগছে তবে আমি বট নয়, কোড পরিবর্তন করার জন্য লোককে দায়ী করতে পছন্দ করব।

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


50
এছাড়াও এটি ভিসিএসকে ভেঙে দেয়। কারা দোষের সাথে সহজেই একটি লাইন লিখেছিল তা আপনি জানতে পারবেন না এবং যদি কোনও বিরোধ হয় তবে আপনার ভিসিএস জানতে পারবেন না যে সরঞ্জামটির পরিবর্তনগুলি কেবল স্টাইলের জন্য এবং প্রতিবারই তা বাতিল করা উচিত।
পিয়ের.সাসৌলাস

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

20
@ জেফো git blameকেবল কোনও ত্রুটিযুক্ত ত্রুটিটি খুঁজে বের করার জন্য নয়, কোনও কিছু যুক্ত / অপসারণের সময় প্রতিশ্রুতিটি সন্ধান করা হয়েছে যা বিভিন্ন কারণে কার্যকর হতে পারে।
পোকেচু 22

2
"আমাদের একটি নিয়ম আছে যা বর্ণ এবং পদ্ধতিগুলি বর্ণানুক্রমিক অর্ডার দেয়" বয়, এটি ভয়াবহ শোনায়! আপনাকে অবিচ্ছিন্নভাবে সমস্ত ফাইল জুড়ে আশা করতে হবে
আলেকজান্ডার

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

72

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

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


7
"হাতের এমন একটি ফরম্যাটার যেখানে আপনি 100% নিশ্চিত যে এটি কোনও কিছু ভেঙে ফেলবে না" - আপনি কখনই এমন কোনও কোডের টুকরোতে চলেছেন যে সত্যই 100% নিশ্চিত কখনই ভাঙবে না?
জিবব্বজ

2
@ জিববোজ: কোড সম্পাদনা করতে, এটি সংকলন করতে এবং লিঙ্ক করতে, এবং ভিসিএস-এর যে কোনও সরঞ্জামগুলিতে, বাগ থাকতে পারে, যা আমাদের কার্যকরী প্রোগ্রামগুলি বিকাশের চেষ্টা বন্ধ করে না ;-) তবে আমার সম্পাদনা দেখুন।
ডক ব্রাউন

আমি সম্পাদনাটিকে অনুমোদন দিই - কেবলমাত্র যদি অতিরিক্ত সতর্কতার জন্য এক পাউন্ড ডিবাগিংয়ের মূল্য হয়। ;)
জিবব্বজ

@ জিববজ প্রায়শই! মনে রাখবেন যে কোনও কিছুর বিষয়ে 100% নিশ্চিত হওয়ার অর্থ এটির সত্য হওয়ার 100% সম্ভাবনা নেই।
ইমিবিস

@ মিম্বিস: আপনি হয়ত মিস করেছেন যে মন্তব্যটি আমার উত্তর থেকে কিছুদিন আগে আমার উত্তর থেকে সরিয়ে দেওয়া একটি বাক্যটিকে উল্লেখ করেছে।
ডক ব্রাউন

37

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


10
আমার মনে হয় যদি সে কোনও বোট চেক জিনিস সংগ্রহস্থলের ভিতরে এবং বাইরে রাখার কথা বলছে, ভিসিএস দেওয়া হবে?
স্টারওয়েভার

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

14
এটি… আমি এখন দুঃস্বপ্ন দেখতে যাচ্ছি
>>>

7
@ স্টার ওয়েইভার আপনি কেন ভাবেন যে 14 বছর পরেও আমি এখনও সেই পরিবেশটি মনে করছি;)
13:37 এ উঠা

28

আমি বিশ্বাস করি যে এটি একটি ভাল ধারণা (স্বয়ংক্রিয়ভাবে কোড ফর্ম্যাটরগুলি চালানো) তবে এটি কেবল আমার অভিমত।

আমি তাদের পর্যায়ক্রমে চালাব না, তবে সংস্করণ নিয়ন্ত্রণের আগে যদি সম্ভব হয়।

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

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

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

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


ঠিক আছে, তবে এর অর্থ প্রতিটি বিকাশকারীকে কমিট হুক ইনস্টল করা দরকার।
bigblind

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

ঠিক আছে, তাই আপনি গিট হুক ইনস্টল করার সামাজিক নিয়মটি বলছেন, এটি একটি স্বয়ংক্রিয় সিস্টেমের চেয়ে ভাল যা এটি করে? (গুরুতর প্রশ্ন, বাজে বক্তব্য হিসাবে বোঝানো হয়নি, ইন্টারনেটে স্বর প্রকাশ করা শক্ত) :)
বিগব্লিন্ড

15
হ্যাঁ, আমি এটা বলছি।
বেসাইল স্টারিনকিভিচ

17

আমি মনে করি এটি খারাপ ধারণা। উত্তরগুলির মধ্যে অনেকটি ইতিমধ্যে আচ্ছাদিত ছিল যে কে আসলে লাইন যুক্ত করেছে তা পিন করা কঠিন করে ইতিহাসকে নষ্ট করে দেয় এবং এটি লোককে কেবল যা কিছু করতে উত্সাহ দেয় এবং বিন্যাস-বট এটি পরিচালনা করবে handle

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

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


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

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

@ 18446744073709551615 আমি স্বয়ংক্রিয় বিন্যাসের পরামর্শ দিচ্ছি না, আমি স্বয়ংক্রিয় চেকিংয়ের পরামর্শ দিচ্ছি । আপনার নিয়মগুলি এই জিনিসগুলির অনুমতি দিতে পারে।
ক্যাপ্টেন ম্যান 21

16

সাধারণভাবে, আমি এটি একটি খারাপ ধারণা বলে মনে করি। নীতিগতভাবে এটি একটি বৈধ ধারণা, তবে এটি বাস্তবে সমস্যাযুক্ত হতে পারে। কোড ফরমেটারটি আপনার কোডটি ভেঙে ফেলা সত্যই সম্ভাবনা, এবং আপনার বিকাশকারীরা (সম্ভবত ন্যায়সঙ্গত) শত্রুতার সাথে প্রতিক্রিয়া জানাতে কেবল একটি ফর্ম্যাটিং রান লাগে (যেমন "আপনার লস কোডের বিন্যাসটি বিল্ডটি ভেঙে ফেলে, এখনই এটি বন্ধ করুন ! " )।

@ বেসাইলস্টারিঙ্কেভিচের সুপারিশের মতো একই শিরাতে আমরা কোড স্টাইল সম্পর্কে "পরামর্শমূলক ইমেল" প্রেরণের জন্য গিট সার্ভার-সাইড পোস্ট-রিসিভ হুক ব্যবহার করি।

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

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

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

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


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

10

হ্যাঁ, আমি মনে করি এটি একটি খারাপ ধারণা। আমাকে ভুল করবেন না, এটি করার কারণটি দুর্দান্ত শোনাচ্ছে তবে ফলাফলটি এখনও ভয়াবহ হতে পারে।

ট্র্যাকড শাখাটি টান দেওয়ার সময় আপনার একত্রীকরণের দ্বন্দ্ব হবে, কমপক্ষে আমি আশংকা করি যে ঘটনাটি ঘটবে, তবে আমি ভুল হতে পারি।

আমি এখনই কর্মক্ষেত্রে এটি পরীক্ষা করতে চাই না, তবে আপনার নিজেরাই এটি চেষ্টা করা উচিত।

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

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

পরিবর্তে আপনি সম্ভবত এটি একটি রাত্রি বিল্ড বা সাপ্তাহিক বিল্ডে রেখে দিতে পারেন।

এমনকি একটি রাত্রে একটি খারাপ ধারণা হতে পারে।

আপনি হয় সপ্তাহে এটি চালাতে পারবেন, যখন আপনি নিশ্চিত হন যে কোনও মার্জ সংঘাত তৈরি হবে না কারণ সোমবার সবকিছু শেষ হয়েছে।

অন্যথায় ছুটির মরসুমে এটি বছরে 1-2 বার চালান, যখন মার্জ বিরোধগুলি ঘটে না।

তবে সমাধান কোড শৈলীর জন্য আপনার অগ্রাধিকারের উপর নির্ভর করতে পারে।

আমি মনে করি যে একটি সেটআপ স্ক্রিপ্ট তৈরি করা যা স্বয়ংক্রিয়ভাবে গিট সংগ্রহস্থল তৈরি করে এবং প্রকল্পের জন্য হুকগুলি সেট করে নেওয়া ভাল।

অথবা আপনি প্রকল্পের মধ্যে আপনার ডেভসের জন্য একটি ফোল্ডারে হুক সেটআপ স্ক্রিপ্ট অন্তর্ভুক্ত করতে পারেন এবং কেবল গিটটিতে এটি পরীক্ষা করতে পারেন।


7

আমি উল্লেখ করি না এমন কিছু হ'ল সত্য যে নিয়মের একটি সেট অনুসারে কিছু ফর্ম্যাট না করার বৈধ কারণ রয়েছে। কখনও কখনও কোডের স্পষ্টতা প্রদত্ত গাইডলাইনটির বিরুদ্ধে গিয়ে 99% সময়টি বোঝায় যা উন্নত হয়। মানুষের সেই কল করা দরকার। এই ক্ষেত্রে, স্বয়ংক্রিয় কোড ফর্ম্যাটিং জিনিসগুলি কম পাঠযোগ্য করে তোলে।


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

7

এটি একটি ভয়াবহ ধারণা।

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

আপনি যদি নিয়মিতভাবে এটি করতে চান তবে তা কেবল ভয়াবহ।

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

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


4

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


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

1

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


1

এই ধারণাটি অন্য কয়েকটি উত্তরের মতো, তবে আমি আমার পরামর্শগুলিতে মন্তব্য করতে পারি না।

একটি বিকল্প হ'ল একটি নাম (বা হুক, বা যাই হোক না কেন) প্রতিশ্রুতিবদ্ধ ফাংশনে সেট করুন, যা প্রতিশ্রুতিবদ্ধ হওয়ার পূর্বে কোড-প্রতিশ্রুতিবদ্ধ কোডটিতে কোড ফর্ম্যাটরটি চালায়।

এটিতে 2 (বা আরও) ফলাফল থাকতে পারে:

1) ব্যবহারকারীকে প্রস্তাবিত পরিবর্তনগুলি দেখান এবং পরিবর্তনগুলি প্রয়োগ এবং প্রতিশ্রুতিবদ্ধ হওয়ার জন্য তাদের অনুমোদনের জন্য জিজ্ঞাসা করুন।

2) প্রস্তাবিত পরিবর্তনগুলি উপেক্ষা করুন এবং মূল কোডটি প্রতিশ্রুতিবদ্ধ করুন।

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

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


0

আমি এটি সংগ্রহস্থলে করব না তবে আমি যদি সরঞ্জামটি সমর্থন করে তবে এটি সংরক্ষণে করব। Eclipse এক এবং এর পাশাপাশি আমি বাছাই সহ কোড সাফাই করি।

সুন্দর অংশটি হ'ল এটি প্রকল্পের অংশ তাই প্রতিটি বিকাশকারী তাদের প্রকল্পের জন্য এটি পাবেন।

যেহেতু জিনিসগুলি চারপাশে ঝাঁপিয়ে পড়বে না একটি যুক্ত বোনাস মার্জগুলি উল্লেখযোগ্যভাবে সরল হবে।

কোড পর্যালোচনা যে কোনও ভুলভ্রান্তি রোধ করবে।

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

এইভাবে যখন বিকাশকারীরা এটির জন্য প্রস্তুত থাকে তখন তাদের টানার অনুরোধের জন্য সমস্ত পরিষ্কার করা হবে।

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