ভিসিএস ব্যবহার করার সময় কোডকে ফর্ম্যাটিং করা কোনও খারাপ জিনিস?

Question

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

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

সুতরাং আমি জিজ্ঞাসা করি, সবসময় কোডটি আসলে কোনও খারাপ জিনিস ফর্ম্যাট করা হয়? কোডটি পাঠযোগ্য কিনা তা নিশ্চিত করার চেয়ে কি তার উদ্বেগগুলি আরও বৈধ?

Comments

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

— gbjbaanb

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

— মাইকেল কে

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

— এডগার গঞ্জালেজ

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

— দ্রুত_বলি

Answer 1

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

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

Comments

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

— gbjbaanb

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

— রায়ান হেইস

যদি কোনও নথির বিন্যাস করার চেষ্টা করার জন্য ওপিকে তিরস্কার করা হয় তবে কিছু আমাকে বলে যে তিনি স্টাইলকপ ব্যবহারের পরামর্শ দিতে পারবেন না।

— ওয়েইন মোলিনা

@gbjbaanb: হ্যাঁ এই কারণেই শুরুতে এই ধরণের সিদ্ধান্ত নেওয়া ভাল। আমি এখন যে প্রকল্পে আছি সেগুলিতে ভান্ডারগুলিতে অ্যাকলিপ ফর্ম্যাটর সেটিংস পরীক্ষা করা আছে যাতে আমরা জানি যে প্রত্যেকেরই একই সেটিংস রয়েছে।

— unholysampler

@ কুইক্লি_নউ: এ কারণেই আমাদের ভেটো অধিকার সহ পরিচালক রয়েছে। লোকেরা যদি সম্মত না হতে পারে তবে তারা সিদ্ধান্ত নিতে পারে।

— আনহোলিসম্প্লার

Answer 2

না, ফর্ম্যাটিং কোডটি খুব গুরুত্বপূর্ণ । তবে কমিট দুটি গ্রুপে করা উচিত:

1. কসমেটিক পরিবর্তন - কোডটি আরও পাঠযোগ্য anything
2. অন্যান্য পরিবর্তনগুলি - কোডকে প্রভাবিত করে এমন সমস্ত কিছু।

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

Comments

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

— স্টিভেন জিউরিস

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

— ডাইপল

Answer 3

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

Comments

আমি মনে করি এটি আপনার বর্তমান পরিস্থিতির সেরা সমাধান তবে আপনার দলের সাথে আপনার এটি সম্পর্কে কথা বলা উচিত। তবে আপনার একটি বড় সমস্যা রয়েছে যা কোডিং স্ট্যান্ডার্ডের অভাব।

— থমাস ওভেনস

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

— ওয়েইন মোলিনা

Answer 4

আমিও নিট-পিকার একটি ফর্ম্যাটিং, তাই এখানে কয়েকটি টিপস:

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

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

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

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

আরও একটি টিপের জন্য সম্পাদনা করুন:

• এটি ভাষাতে রূপের ভাষা পরিবর্তিত হয়, তবে কোডটিতে সত্যিকারের প্রসাধনী পরিবর্তনের জন্য, আপনি বড় আকারের ক্লিনআপের আগে এবং পরে সংকলিত বাইনারিগুলির তুলনা করতে সক্ষম হবেন একেবারে নিশ্চিত যে আপনি এটিকে উপভোগ করেন নি।

Comments

যতক্ষণ আপনি বাইনারি (বা বিল্ড তথ্য) এ ভিসি ট্যাগ অন্তর্ভুক্ত করবেন না।

— ভ্যাটাইন

Answer 5

আপনার অন্য লোকের কোডে পুনরায় ফর্ম্যাট করা এবং প্রতিশ্রুতিবদ্ধ হওয়া উচিত নয় যতক্ষণ না:

• আপনি টিম কোডিং স্ট্যান্ডার্ড স্থাপনের চেষ্টা করছেন এমন পরিচালক
• আপনার পরিচালক আপনাকে টিম কোডিং মানকে মেনে চলার জন্য কোডটি পরিষ্কার করতে বলেছে
• আপনি কোনও টিম কোডিং মানকে মেনে চলার জন্য কোনও বিকাশকারী থেকে কোড পরিষ্কার করছেন।

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

Comments

"তাদের পিছনে পিছনে": এটি কোডের মালিকানার মানসিক সমস্যাগুলিতে ফিরে যায় (বা বিকাশের টারফ যুদ্ধ)।

— রওয়ং

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

— কালেব হুইট - সিউহিত

@ কালেব: যদি তারা অস্বীকার না করে তবে কঠোর হবে।

— দ্রুত_বলি

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

— সিডিকেমুজ

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

— সিডিকেমুজ