সমস্ত বিকাশকারীদের জন্য কি একই কোড ফর্ম্যাটটি চাপানো ভাল ধারণা?


88

আমরা আমাদের প্রকল্পে একক মানক কোড ফর্ম্যাট চাপানোর বিষয়ে বিবেচনা করছি (Eclipse এ সংরক্ষণ ক্রিয়া সহ স্বয়ংক্রিয় ফর্ম্যাট)। কারণটি হ'ল বর্তমানে বেশ কয়েকটি (> 10) বিকাশকারীদের দ্বারা ব্যবহৃত কোড ফর্ম্যাটগুলিতে একটি বড় পার্থক্য রয়েছে যা এক বিকাশকারীকে অন্য বিকাশকারীর কোডে কাজ করা আরও শক্ত করে তোলে। একই জাভা ফাইলটি মাঝে মাঝে 3 টি বিভিন্ন ফর্ম্যাট ব্যবহার করে।

সুতরাং আমি বিশ্বাস করি সুবিধাটি স্পষ্ট (পঠনযোগ্যতা => উত্পাদনশীলতা) তবে এটি চাপিয়ে দেওয়া কি ভাল ধারণা হবে? আর যদি না হয় তবে কেন?

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


2
আপনার সমস্ত বিকাশকারীই কি গ্রহটিকে ব্যবহার করেন? আপনি কি তাদের সাথে এই পরিকল্পনা সম্পর্কে কথা বলেছেন? এই বুদ্ধিমান ছাড়া, আপনার প্রশ্নের উত্তর দিতে কঠিন, এক অনুমান করতে খুব বেশী হবে
মশা

9
একজন বিকাশকারীকে অন্যের কোডে কাজ করা কি আসলেই আরও শক্ত করে তোলে, বা বিকাশকারীরা কি কিছুটা আলাদা কোড পড়তে কেবল অ্যালার্জি করে চলেছেন?
জোরিস টিমারম্যানস

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

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

3
অন্যদিকে: যদি প্রত্যেকে একই বিন্যাস ব্যবহার করে তবে সমস্ত কিছু পুনরায় ফর্ম্যাট করার জন্য প্রথম প্রথম প্রতিশ্রুতি দিয়ে তা আটকে থাকবে। বাকি সমস্ত কিছুই কেবল স্থানীয় পরিবর্তনের জন্য স্পর্শ করবে, যা আমার মতে গ্রহণযোগ্য।
জেরোইন ভেনেভেল

উত্তর:


107

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

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

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

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

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


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

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

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

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

কঠোর সতর্কতা এবং ত্রুটি একটি ভাল জিনিস।
ক্রিস্টোফ রাউসি

37

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

অনেক সফ্টওয়্যার বিকাশকারী সুসমাচার প্রচারের যুদ্ধগুলি .....

দলের এবং দলের গতিশীলতার মধ্যে আপনার অবস্থানের উপর নির্ভর করে আপনি সিদ্ধান্ত নিতে পারেন যে যুদ্ধে জয়লাভ করা সম্ভব নয়। এই ক্ষেত্রে, না শুরু করা ভাল ...


Tx, আমি ঠিক কী বলতে চাই তা আমি জানি
স্টিজন গিউকেনস

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

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

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

1
@রুখ এমএসডিএন সি # কোডের নমুনাগুলি দেখুন, দেখুন ভিজ্যুয়াল স্টুডিও সি-কে কীভাবে ডিফল্টরূপে পুনরায় ফর্ম্যাট করে: own এটি নিজস্ব লাইনে রয়েছে। জাফল্যের জন্য ওরাকলির ডকুমেন্টেশন এবং পুনরায় ফর্ম্যাট করার সময় অ্যাকলিপের ডিফল্টে অনুশীলনটি পুনরাবৃত্তি করুন: above উপরের লাইনে রয়েছে।
ড্যান নীলি

30

হ্যাঁ, সমস্ত বিকাশকারীদের জন্য একটি কোড বিন্যাস শৈলী থাকা ভাল।

কোড শৈলীর ফর্ম্যাটগুলি ডিজাইন করুন এবং তা সমস্ত বিকাশকারীকেই গ্রহনটি আমদানি করুন।

আমরা যখন merging'সংস্করণ নিয়ন্ত্রণ' সিস্টেমে কোড করি এটি এটির সহায়তা করবে ।


5
একত্রীকরণ এবং বিবিধ সরঞ্জামগুলি উল্লেখ করার জন্য +1। ফর্ম্যাটটি বিকাশকারীদের মধ্যে সামঞ্জস্য না হলে কোনও কোড বেসের দুটি সংস্করণের মধ্যে পার্থক্য চিহ্নিত করার চেষ্টা করা সত্যিকারের ব্যথা।
pgras

1
+1, আমি সংস্করণ নিয়ন্ত্রণ ব্যবস্থার যুক্তিটি দ্বিতীয় স্থানে রেখেছি। (তবে এটি বেশিরভাগ ক্ষেত্রে ইনডেন্টেশন নিয়মের কারণে
n

নামকরণের কনভেনশনগুলি যখন ক্লাসে আপনার জানা পদ্ধতিটি কী তা কী বলা হয় তা নির্ধারণের জন্য আপনাকে সহায়তা করে।
ড্যান নীলি

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

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

16

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

  1. কোডের কাছে একটি সাধারণ চেহারা এবং অনুভূতি প্রকৃতপক্ষে কোডকে আরও পঠনযোগ্য করে তুলতে সহায়তা করতে পারে তবে এটি ভুল চেহারা এবং অনুভূত হলে জিনিসগুলিকে আরও খারাপ করে তুলতে পারে। _এইউগারিয়ান_এলএফএফস্ট্রেশন একটি প্রধান উদাহরণ হিসাবে চিহ্নিতকরণ :)
  2. আমি মন্তব্য কোডগুলিতে শ্বেত স্পেসের সংখ্যাগুলির সংখ্যা, পদ্ধতির নামের বর্ণানুক্রমিক ক্রম এবং অন্যান্য বাজে কথা বলার মধ্যে "কোড স্ট্যান্ডার্ড" দেখেছি। এটা করবেন না।
  3. বিভিন্ন ভাষার বিভিন্ন মানের রয়েছে লোকেরা তাদের ব্যবহারে অভিজ্ঞ যারা তাদের ব্যবহৃত হয়। কেউ কেউ এই মানদণ্ডগুলিও নির্ধারণ করে (পাইথন, কোবল, ভিজ্যুয়াল স্টুডিও স্বয়ংক্রিয়ভাবে সি ++ স্টাইল ব্র্যাকিং কনভেনশনগুলি চাপিয়ে দেয় যখন জাভা কনভেনশন দ্বারা সি স্টাইল ব্যবহার করে ইত্যাদি ইত্যাদি)।
  4. বিদ্যমান কোডটি পরিবর্তনের স্বার্থে কখনই পরিবর্তন করবেন না, আপনি কেবল সেভাবেই নতুন সমস্যাগুলি প্রবর্তন করছেন। এবং এর অর্থ কোড বিভাগের পাশাপাশি পুরো উত্স ফাইলগুলি। সুতরাং কেউ যখন 1000 লাইন ফাইলে একটি একক লাইন পরিবর্তন করে তখন বিদ্যমান কোডটি পুনরায় ফর্ম্যাট করার আশেপাশে যাবেন না।
  5. অভিজ্ঞ প্রোগ্রামাররা যদি আরও লিখতে থাকে যে তারা যা লিখছে তা স্বয়ংক্রিয় অনুমোদনের সিস্টেমে "সঠিক দেখাচ্ছে" কিনা তা পর্যালোচনা করতে না পারলে আরও বেশি উত্পাদনশীল হতে পারে। তারা ক্লিন কোড লেখার অভ্যাসেও চলে যাচ্ছেন কেবল কারণ এটি তাদের কাজ করে এমনকি তাদের প্রাকৃতিক শৈলীর মধ্যে সামান্য পার্থক্য রয়েছে।



সুতরাং একটি নির্দিষ্ট শৈলী এবং স্ট্যান্ডার্ড আরোপ করার উপযুক্ত কারণগুলি থাকা সত্ত্বেও, কঠোরভাবে (খুব) তা না করার যথেষ্ট কারণ রয়েছে।


1
১-২-৩: এটি জাভা এবং কোড ফর্ম্যাটটি সূর্যের এক; এটি কেবল ফর্ম্যাট করা তাই পদ্ধতি বা পরিবর্তনশীল নাম অর্ডার না করে; ৪-৫: ঠিক আছে, ধারণাটি হবে স্বয়ংক্রিয়ভাবে সেভের উপর ফর্ম্যাট করা (এক্সিলিপ সেভ ক্রিয়া) যাতে কোনও অতিরিক্ত কাজ হয় না (কোড করার সময় আপনাকে ফরম্যাটটি নিয়ে ভাবতে হবে না) তবে অবশ্যই বিদ্যমান ফাইলগুলি পুনরায় ফর্ম্যাট করা হবে ( প্রথমবার).
স্টিজন গিউকেনস

1
KISS এর জন্য +1। @ স্টিজন কেন পুরাতন কোডটিকে পুনরায় ফর্ম্যাট করবেন? আপনার যখন এটি সংশোধন করা দরকার তখনই এটি হিট করুন।
এরিক পুনরায়

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

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

2
আপনি অন্য কারণটি ভুলে গেছেন ড্যান: বড় আকারের ফর্ম্যাট পরিবর্তনগুলি অপ্রত্যাশিত জায়গায় সহজেই নতুন বাগগুলি প্রবর্তন করতে পারে।
জেভেন্টিং

11

হ্যাঁ, দৃঢ়তা একটি ভাল ধারণা, কারণে হয় অন্যদের আছে উল্লেখ

আমি কেবল কয়েকটি পয়েন্ট যোগ করতে চেয়েছিলাম যা অন্য কোথাও ব্যবহার করা হয়নি:

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

9

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

(আমাদের সিদ্ধান্তের উদাহরণস্বরূপ: characters২ টি অক্ষর প্রস্থ খুব ছোট, তবে 120 টি ভাল ছিল; স্ট্যাটিক ফাইনালের জন্য _ALLCAPS ব্যবহার করা ভাল; একটি ফাংশন থেকে একক-বহির্গমনকে প্রয়োগ করা ভাল ধারণা))

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

(কোড গন্ধ অপসারণ সামঞ্জস্যপূর্ণ ফর্ম্যাটিংয়ের চেয়ে বেশি গুরুত্বপূর্ণ This এটি স্বয়ংক্রিয় সরঞ্জামগুলির একটি সুবিধা))

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


5
একক বহির্গমন পয়েন্ট? কিছু স্টাইলের নীতি রয়েছে যার সাথে আমি সত্যই একমত নই। (যদি একাধিক প্রস্থান সমস্যা হয়, তবে ফাংশন / পদ্ধতিটি প্রথম স্থানে অনেক দীর্ঘ ...)
ডোনাল ফেলো

@ ডোনালফেলো, চেকস্টাইল আমাদের একটি রেফারেন্স পয়েন্ট দিয়েছে যার থেকে আমরা কমিটির পছন্দসমূহের দিকে যেতে পারি। প্রকৃতির অনেক উদ্দীপনা ছিল, "কেন তারা এই স্ট্যান্ডার্ডটি রেখেছিল তা আমি দেখছি না!" ওপি ধারাবাহিক বিন্যাস সম্পর্কে জিজ্ঞাসা করার সময়, আমি মনে করি স্বয়ংক্রিয় সরঞ্জামটি অতিরিক্ত ব্যথা ছাড়াই অনেক কিছু দেয়।
রাজা 9

6

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

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

ব্যক্তিগত পছন্দগুলি কেবল এটি এবং খুব কমই উত্পাদন উন্নত হয়: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-differences-brace-forms

যদি এটি হয় তবে এটির উপর দিয়ে কিছু করুন।


6

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

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

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

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

আমি মনে করি যে এই উত্তরের থিমটি হ'ল, কোড পর্যালোচনা করুন এবং সংস্কৃতি থেকে পর্যালোচনা প্রক্রিয়া থেকে ফর্ম্যাট করতে দিন flow


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

3
ফিশিয়ে যেমন "অসঙ্গতিযুক্ত ইনডেন্ট" বা "নিজেই লাইন অন খোলা ব্রেস" এর মতো কোনও লাইনে কল আউট করার জন্য এটি অতিরিক্ত ক্লিক so সুতরাং, হ্যাঁ, এটি শূন্যের চেয়ে বেশি প্রচেষ্টা। তবে, যদি এটি কোড রিভিউগুলিকে আক্ষরিক 1 মিনিটের বেশি করে প্রসারিত করে তবে একটি গুরুতর সমস্যা আছে। দলটির নিজস্ব কোডটি পর্যালোচনা করার এক সপ্তাহ পরে, তাদের সবার "ভুল" কোডটি লক্ষ্য করা এবং এটির স্পর্শ করা খুব দ্রুত হওয়া উচিত।
স্যাম

4

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

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

বলা হচ্ছে, "ফাইলের / প্রকল্পে ইতিমধ্যে বিদ্যমান কোড কনভেনশন অনুসরণ করুন" এর একটি কঠোর নিয়ম ভাল good

তবে মনে রাখবেন যে কোডটি কীভাবে যুক্তিযুক্তভাবে সাজানো হয়েছে তার চেয়ে ফরম্যাটিংটি পাঠযোগ্যতার পক্ষে অনেক কম অবদান রাখে। আমি প্রচুর অপঠনযোগ্য স্প্যাগেটি কোড ডাব্লু / নিখুঁত বিন্যাস দেখেছি!


2

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

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

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

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


2

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

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

যদি আপনার সংস্থা সোর্স কোড বিক্রি করে তবে কোডিং স্টাইলটি আরও গুরুত্বপূর্ণ তবে আপনি যদি সংকলিত কোড বিক্রি করেন তবে এটি অনেক কম প্রাসঙ্গিক।

কোডিং শৈলীর প্রত্যাশা মূল কোডারকে কম স্বাতন্ত্র্যজনক করে তুলবে এবং অহং যুদ্ধগুলিকে রোধ করবে সেরা ক্ষেত্রে সবচেয়ে খারাপ এবং সবচেয়ে খারাপ ক্ষেত্রে সাদামাটা বোকা। দুর্দান্ত প্রোগ্রামাররা শৈলী নির্বিশেষে সর্বদা মার্জিত কোড তৈরি করবে।

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

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


2

তাদের সকলকে শাসন করার জন্য একটি ফর্ম্যাট ... এটি কি সর্বোত্তম?

এটি অন্য কারও গাড়ি চালানোর মতো ...

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

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

এখন পর্যন্ত উল্লিখিত সমস্ত সুবিধাগুলি +1 করুন, কিন্তু ...

স্বয়ংক্রিয় প্রয়োগকারী এমন ব্যয় নিয়ে আসে যা বিবেচনা করা উচিত:

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

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

ফর্ম্যাট করার নিয়ম রয়েছে তবে কিছু স্বাতন্ত্র্যকে সাধারণ জ্ঞান প্রয়োগের অনুমতি দিন।


2
আমি একেবারে একমত! অটোফর্মেটরগুলি বোবা।
asukasz উইক্টর

1

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

বিধি 1: ভেরিয়েবল / কার্সার / অবজেক্ট / পদ্ধতি / যাই হোক না কেন সংক্ষিপ্ত নাম দিন। দ্ব্যর্থহীন নাম যা আপনার কোডের অর্থ এবং বোঝাপড়া নিয়ে আসে।

বিধি 2: আপনার কোডের কাঠামো প্রদর্শন করতে ইন্ডেন্টেশন ব্যবহার করুন।

এটাই.


1
কেন আপনি বিষয়টি ব্যাখ্যা করতে পারেন ? প্রত্যেকটি বিকাশকারীকে কীভাবে কিছু শৈল্পিক লাইসেন্স দেওয়া (যা একই প্রকল্পের বিকাশকারীদের মধ্যে পৃথক হয়) তাদের সবার একই ফর্ম্যাট থাকার চেয়ে কীভাবে আরও ভাল ধারণা তৈরি করতে দেয়? আপনার সমস্যাগুলি সমাধান করে যে বিকল্পটি দেয় না? এবং বিপরীতভাবে?

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

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

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

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

0

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


-1

স্টাইল গাইডগুলি বিভিন্ন বিশ্লেষণামূলক উদ্দেশ্যে কোডের আরও সহজ প্রোগ্রামিং পার্সিং সক্ষম করে।

গুগল এই সম্পর্কে একটি কাগজ প্রকাশ করেছে যার নাম "বিল্ডিং tণ অনুসন্ধান করা: গুগলে প্রযুক্তিগত tণ পরিচালনার অভিজ্ঞতা"


-1

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


-2

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

ধারণাটি নিয়ে আমার সবচেয়ে বড় সমস্যাগুলি

  1. আমি যদি কোনও ফর্ম্যাটে কোড লিখছি এবং এটি স্বয়ংক্রিয়ভাবে পুনরায় ফর্ম্যাট করা আছে তবে সেই ফর্ম্যাটটি শিখতে কী উত্সাহ আছে?
  2. পূর্ববর্তী পয়েন্টটি অনুসরণ করে, আপনি যদি ফর্ম্যাটটি না শিখেন তবে অটোফর্ম্যাটিংয়ের পুরো পয়েন্টটি (কোড আরও সহজেই পড়তে এবং সংশোধন করতে) সম্পূর্ণরূপে হারিয়ে যায়। আপনি কোডটি পড়ছেন বলে ফর্ম্যাটটি বের করার জন্য আপনাকে এখনও সময় নিতে হবে কারণ আপনি সেই ফর্ম্যাটটি শিখেননি
  3. আমি মনে করি যে একদিন কোনও ক্লাস লিখতে, এটি বন্ধ করে দেওয়ার জন্য এবং পরের দিন ফিরে এসে একেবারে আলাদা see এর অর্থ হ'ল কেবল অন্যকে আপনার কোড শিখতে হবে না, আপনাকে নিজের কোড শিখতে হবে।
  4. এটি অলস কোডিংকে উত্সাহিত করতে পারে। ফর্ম্যাটটি শিখতে দেবকে চাপ দেওয়ার পরিবর্তে তারা সূর্যের নীচে যে কোনও ফর্ম্যাটে লিখতে পারেন এবং এটি স্বয়ংক্রিয়ভাবে অন্য সকলের মতো দেখতে পাবেন look এটি # 2 এ ফিরে যায় যেখানে আপনি স্টাইলটি শিখেন না এবং এখনও এটি সঠিকভাবে পড়তে পারবেন না।

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

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


+1: ভাল পয়েন্ট, যদিও আমি নিশ্চিত নই যে তারা স্বয়ংক্রিয় পুনর্নির্মাণের পক্ষে কারণগুলি ছাড়িয়ে যাবে। ডাউনভোট (গুলি) কেন?
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.