কোডিং মানগুলি যে কোনও সফ্টওয়্যার ডেভলপমেন্ট সংস্থায় সাধারণ, তবে তাদের অনুসরণ করা কতটা গুরুত্বপূর্ণ? আমি কিছু ধারাবাহিকতার প্রয়োজনীয়তা বুঝতে পারি, তবে ব্রেসগুলির অবস্থান, লাইনের দৈর্ঘ্য ইত্যাদির মতো সাধারণ জিনিসগুলির সাথে কথা বলার সময় আমি নিশ্চিত নই যে অতিরিক্ত কঠোর মান সফ্টওয়্যার বিকাশে খুব বেশি অবদান রাখবে।
আপনার কোডটি পাঠযোগ্য, এর চেয়ে বেশি গুরুত্বপূর্ণ নয় যে এটি পূর্বনির্ধারিত মানের সাথে সঙ্গতিপূর্ণ? দেখে মনে হচ্ছে তারা যাই হোক না কেন ... নির্দেশিকাগুলির মতো।
উত্তর:
প্রত্যেককে একই মানক কোড ফর্ম্যাটিং গাইডলাইনটি 100% মেনে চলার অনুরোধ করা হ'ল প্রত্যেককে একই লেখার শৈলীতে 100 পৃষ্ঠার কাগজ লেখার জন্য আলাদাভাবে সহযোগিতা করতে বলার মতো।
আশা করি প্রত্যেকে ইংরেজিতে (বা একই ভাষা) কাগজটি লিখবেন, তবে বিভিন্ন স্টাইলটি স্পষ্ট হবে। কিছু এটি ভাল লিখবে, অন্যদের না। কেউ সংকোচনের ব্যবহার করবে, কেউ শব্দের পুরোপুরি বানান করবে (উদাহরণস্বরূপ: এটি হ'ল ভার্সু)। প্রভৃতি
আমি মনে করি আপনি সবচেয়ে গুরুত্বপূর্ণ পয়েন্টগুলিতে স্পর্শ করেছেন:
আপনি যদি কোডটি একই লেখার শৈলীতে কোনও কাগজের মতো একই বিন্যাসের সাথে মেনে চলতে চান তবে এটির সম্পাদনা এবং সংশোধন করা দরকার। কোডটি পরিষ্কার করা, পর্যালোচনা করা, পুনরায় ফ্যাক্টর করা ইত্যাদি দরকার হবে will
আমি কখনই এমন দোকানে যাইনি যেখানে আমি অন্য বিকাশকারীর কোডিং শৈলী বা ফর্ম্যাটিংয়ের সাথে পুরোপুরি খুশি ছিলাম (ন্যূনতম হলেও এটি আমার মতো নয়)। তবে আমি যদি তা পড়তে / বুঝতে পারি এবং এটি যদি সামঞ্জস্য হয় তবে আমি সন্তুষ্ট থাকব। বাকী সমস্ত কিছুই সিনট্যাকটিক চিনির উপর চিনি।
সুতরাং আপনার প্রশ্নের উত্তর দিতে: কিছুটা গুরুত্বপূর্ণ, তবে তারা যদি তা না করে তবে অবশ্যই এটি বিশ্বের শেষ নয়।
ফর্ম্যাটিং মানগুলির জন্য, আমি প্রত্যেকে যা যা করি তা অনুসরণ করি। যদি তারা সবকিছুর জন্য পাস্কেলকেস ব্যবহার করে থাকে তবে আমি পাস্কেলকেস ব্যবহার করি। যদি তারা _ ক্যামেলকেস ব্যবহার করে তবে আমি _ ক্যামেলকেস ব্যবহার করি। কেন? কারণ এটি আমার পুনরায় ফর্ম্যাট করার পরিমাণকে সীমিত করে এবং এটিকে "ভাল দেখায়" তৈরি করার জন্য অন্যেরা কী করতে হবে তা সীমাবদ্ধ করে। ফর্ম্যাটিং স্ট্যান্ডার্ডগুলি সাধারণত প্রত্যেকের জন্য জিনিসগুলি সহজ করার জন্য থাকে are
আমার বর্তমান চাকরিতে, আমার প্রথম কাজটি ছিল আমাদের বিকাশের গোষ্ঠীর কোডিং মান নিয়ে আসা।
আমার প্রথম প্রচেষ্টাটি প্রায় ষাট পৃষ্ঠাগুলি দীর্ঘ ছিল (এটি মাইক্রোসফ্টের ফ্রেমওয়ার্ক গাইডলাইনগুলির বেশিরভাগ অন্তর্ভুক্ত করেছে)। আমাকে এটিকে নেমে যেতে বলা হয়েছিল, এবং আমার পরবর্তী প্রচেষ্টাটি দশটি পৃষ্ঠার দীর্ঘ ছিল, বিভিন্ন ভাল উত্স থেকে ধারণাগুলি ব্যবহার করে। আমাকে আবার এটি কমিয়ে আনতে বলা হয়েছিল, এবং অবশেষে এটি তিন বা চার পৃষ্ঠায় নামিয়ে দেওয়া হয়েছে বলে মনে করি।
এটি কখনও গ্রহণ করা হয়নি।
কেন? কারণ আমি প্রচুর স্মার্ট লোকের সাথে কাজ করি, যারা ইতিমধ্যে সংবেদনশীল কোডিং স্ট্যান্ডার্ডটি সহজাতভাবে অনুসরণ করে।
আমার অংশ হিসাবে, আমি মাইক্রোসফ্ট থেকে সাধারণভাবে গৃহীত গাইডলাইন অনুসরণ করি এবং অন্যের সাধারণভাবে ব্যবহৃত শৈলীগুলি অনুকরণ করি (জাভাস্ক্রিপ্ট এবং জিক্যুরি C_ থেকে আলাদাভাবে ফর্ম্যাট করা হয় , যদিও এটি উভয় কোঁকড়ানো-ব্রেস ভাষা হলেও)। আমি সময়ে সময়ে নিয়মগুলিও ভঙ্গ করি, যখন এটি করা কোডটি আরও পঠনযোগ্য করে তুলবে।
যদি আপনি ব্যবহার করেন এবং আইডিই যা আপনার জন্য এটির মূল বিষয়গুলি করে (উদাহরণস্বরূপ ভিজ্যুয়াল স্টুডিও), আইডিইটিকে এটি করতে দিন এবং যা এখনও আপনার আইডিইটিকে এটি করার অনুমতি দেয় ততক্ষণ আপনার সংশোধন করা শক্ত মনে হয় পরবর্তী ব্যক্তি যে এটি স্বয়ংক্রিয়ভাবে ফর্ম্যাট করে তা যাইহোক এটি হত্যা করতে চলেছে।
এক ব্যক্তির কাছে যা সর্বাধিক পঠনযোগ্য তা সমস্ত লোকের পক্ষে হবে না।
আপনি যদি এই ধরণের আইডিই ব্যবহার না করেন তবে একটি পান। এমনকি 10 মিনিটেরও বেশি সময় এটি সম্পর্কে চিন্তা করা সম্পদগুলির অপচয় হ'ল আইএমএইচও।
আমি মনে করি কোড দ্রুত বুঝতে সাহায্য করার ক্ষেত্রে একটি নিরঙ্কিত সুবিধা রয়েছে। কোড ফর্ম্যাটিংটি কোনও প্রকল্প এবং সমস্ত বিকাশকারী জুড়ে আরও সমান, আপনি কোডটি দিয়ে কাজ করতে পারবেন সহজ (এবং আরও অবচেতনভাবে)।
আমি জুনিয়র বিকাশকারীদের বর্ধিত সময়ের জন্য এমনকি সাধারণ বাগগুলি মোকাবেলা করার চেষ্টা করার পরে আমার কাছে এসেছি। তাদের সাথে আমাদের কোড ফর্ম্যাটটি প্রয়োগ করতে কয়েক মিনিট সময় নেওয়ার পরে, তারা ত্রুটিটি যেটি এর আগে মিস করেছিল তা তাড়াতাড়ি দেখতে সক্ষম হয়েছিল।
যদিও পাঠযোগ্যতা অবশ্যই গুরুত্বপূর্ণ। যদি আপনার কোড বিন্যাসের মানগুলি ভালভাবে বিবেচনা করা হয় এবং সঠিকভাবে ব্যবহার করা হয় তবে আপনি দেখতে পাবেন যে আপনি কেবল কোডটি পড়তে পেরে এবং কোডটি আরও দ্রুত বুঝতে সক্ষম হয়ে যেতে পারেন।
আমাদের কোডিং ফর্ম্যাটগুলি বিকাশ বা আপডেট করার সময় আমি যে নির্দেশিকা ব্যবহার করি তা হ'ল জেস্টাল্ট নীতি গোষ্ঠীকরণ - http://en.wikedia.org/wiki/Gestalt_psychology# জেস্টাল্ট_লাউজ_ফ_গ্রুপিং
প্রত্যক্ষ ফলাফল হিসাবে / উদাহরণ হিসাবে আমাদের কোড ফর্ম্যাটিংয়ের প্রয়োজন যে কোনও ব্লক কোড (যদি, স্যুইচ, ইত্যাদি) পরবর্তী লাইনে খোলা ব্রেস থাকে, যাতে এটি বন্ধনী বন্ধনী সহ লাইন করে:
if(true)
{
}
সিমমেট্রি প্রিন্সিপালের মাধ্যমে এই যুক্তিটি সহ আপনার মন খোলার এবং বন্ধ হওয়া বন্ধনীগুলি দেখতে পাবে এবং আরও দ্রুত প্রাকৃতিকভাবে কোড ব্লকটি উপলব্ধি করতে সক্ষম হবে।
After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before.এটি নয় কারণ আপনার কোড ফর্ম্যাটটি তাদের বাগটি দেখতে সহায়তা করেছিল। এর কারণ কোডটি পুনরায় ফর্ম্যাট করার কাজটি তাদের কোডের দিকে সাবধানতার সাথে দেখতে বাধ্য করেছিল যে তারা কেবল আগে স্কিমিং করছে।
আপনি কোন ভাষা বা সরঞ্জাম ব্যবহার করেন না কেন, কিছু নিয়ে আসুন। আপনার আইডিই কনফিগার করুন এবং কনফিগারেশন ফাইলটি দেখুন।
যখন কেউ প্রকল্পটি পরীক্ষা করে দেখুন, তারা একই ফর্ম্যাটিং শৈলী ব্যবহার করবেন। শৈলী কী তা বিবেচনাধীন নয়, কেবল এটি সামঞ্জস্যপূর্ণ। স্পেস v। ট্যাবগুলির সাথে আমার নিজস্ব পছন্দ আছে এবং কোঁকড়ানো ধনুর্বন্ধনীগুলি কোন লাইনে চলেছে। তবে আমার নিজের পছন্দগুলির চেয়ে বেশি, আমি কেবল যত্ন নিই যে প্রদত্ত উত্স কোড ফাইলটি নিজের সাথে একমত হয়। এটি এটিকে এত বেশি পাঠযোগ্য করে তোলে যে এটি কোনও ফর্ম্যাট যুদ্ধের ফলে হওয়া মিশ্মাশ হওয়ার চেয়ে বেশি।
আমি এখন পর্যন্ত সবচেয়ে খারাপটির মুখোমুখি হয়েছি কোন কোডিং মান ব্যবহার করা। এবং কিছু কোড ব্লককে আরও পঠনযোগ্য করে তোলার জন্য আপনার নিষেধাজ্ঞা রয়েছে কারণ এটি বিভিন্ন সরঞ্জামগুলি ভেঙে দেয় ... কারণ আমরা পরিবর্তনগুলি প্রয়োগ করতে প্যাচগুলি ব্যবহার করছি (পরিবর্তন / বাগ ফিক্স অনুরোধ -> ফিক্স / পরিবর্তন -> প্যাচ -> প্যাচ "বিশ্বস্ত" ব্যক্তি প্রয়োগ করেছেন) -> প্রতিশ্রুতিবদ্ধ) আপনি চমত্কার মজাদার চেহারা উত্স কোড পেতে পারেন (দেখার পঠনযোগ্যতার দিক থেকে)। কমপক্ষে আমাদের কাছে দুটি বর্ণের ভেরিয়েবল (-) ব্যবহার করার দরকার নেই।
[ছদ্মবেশী] মজার বিষয় হ'ল সকলেই সম্মত হন যে আমাদের এটি পরিবর্তন করা দরকার। এমনকি বেশ কয়েকটি পুনরায় ফর্ম্যাট চেষ্টা ছিল (প্রতিশ্রুতি দেওয়ার সাথে সাথে স্বয়ংক্রিয়), তবে একক ক্ষুদ্রতর বিটসী বিন্যাস বিকল্পটি অনুপস্থিত - সমস্ত কিছুই সবেমাত্র পেরিয়ে গেছে। দর্শন ... [/ অভিজাত]
নির্দেশিকাগুলি কোডের মান উন্নত করতে সহায়তা করে:
লেখকের দৃষ্টিকোণ থেকে: অনেকগুলি নিয়ম বাগের প্রবর্তন হ্রাস করার লক্ষ্য করে। উদাহরণস্বরূপ, একটি নিয়ম যা উল্লেখ করে যে if()বা for(;;)কন্সট্রাক্টসগুলি অবশ্যই একটি ব্লক অনুসরণ করবে এবং একটি নির্দেশ নয়, প্রাথমিক কোডারকে সুস্পষ্ট করে তোলে এবং পরবর্তী কোডারগুলিকে এটি বজায় রাখতে সহায়তা করে।
পাঠক দৃষ্টিকোণ থেকে: সম্মত নির্দেশিকাগুলি অনুসরণ করে এমন কোডটি বিভিন্ন শৈলীর কোডের চেয়ে আরও দক্ষতার সাথে পর্যালোচনা করা হয়। সম্ভাব্য বাগগুলি কোথায় সন্ধান করতে হবে সেখানে কম চেষ্টা করে পর্যালোচক আরও ভাল জানেন।
একটি দল কী করা উচিত এবং কী করা উচিত তার কোনও সর্বজনীন মান নেই। কিছু দলকে কঠোর নির্দেশিকা অনুসরণ করতে হবে, কিছুকে তা মানবে না।
মুল বক্তব্যটি হ'ল আপনার দল হিসাবে একসাথে কাজ করা উচিত এবং আপনার দলের পক্ষে সেরা কি তা সিদ্ধান্ত নেওয়া উচিত । কোডটি পড়তে সহজ হওয়া উচিত, কারণ এটি লেখার চেয়ে আরও বেশি বার প্রস্থের অর্ডার পড়ে read আপনার দলের যদি পঠনযোগ্য কোড তৈরি করতে দিকনির্দেশের প্রয়োজন হয় তবে একটি কোডিং মানকে আটকে দিন। আপনি যদি না, না।
যা যা বলা হচ্ছে, আমি মনে করি বেশিরভাগ দলগুলি ভেরিয়েবল, ফাংশন এবং ক্লাস, পজিশন ব্রেস ইত্যাদির নামকরণের একটি স্ট্যান্ডার্ড পদ্ধতিতে একমত হওয়ার মাধ্যমে উপকৃত হবে। দল যদি এত সহজ কিছু নিয়ে একমত হতে না পারে তবে তারা কীভাবে একত্রিত হয়ে সত্যিকারের গুরুত্বপূর্ণ সিদ্ধান্ত নিতে পারে? এছাড়াও, আপনার দল চিরকাল একই লোকদের নিয়ে তৈরি হবে না - লোক চলে যায়, নতুন লোক নিয়োগ করা হয়। কোডবেস ছাঁটাই করা নতুন লোকের পক্ষে যত সহজ, তত দ্রুত তারা কোডের মান না কমিয়ে দলে অবদান রাখতে পারে।