পাইথনের জেন কী এবং এটি কীভাবে সম্ভাব্য জেন সি-কে অনুপ্রাণিত করে?

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

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

জেন আসলে কী (এবং জেন সি সম্পর্কে কথা বলার সময় কেন এটি গুরুত্বপূর্ণ)

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

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

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

বাস্তবে, যখন কেউ জেন সি-এর কথা উল্লেখ করে, তখন তারা সাধারণত একই ধারণাটি ধারণ করার চেষ্টা করে: স্পষ্ট এবং আরও রক্ষণাবেক্ষণযোগ্য সি কোড লিখতে সাহায্য করার জন্য কিছু নির্দেশিকা, যা পাইথনের জেন যা প্রচার করে তা দ্বারা অনুপ্রাণিত, যদিও C এর জন্য কোন অফিসিয়াল PEP 20 নেই, না এর মতো কোন ম্যাজিক মডিউল আছে import this.

কনসোলে পাইথনের জেন দেখতে কেমন?

পাইথনের সবচেয়ে পরিচিত কৌতূহলগুলির মধ্যে একটি হল যে আপনি যেকোনো ইন্টারেক্টিভ ইন্টারপ্রেটারে জেন প্রদর্শন করতে পারেন কেবল টাইপ করে import thisপাইথন ২.২.১ থেকে, ইন্টারপ্রেটার মডিউলটি অন্তর্ভুক্ত করেছে this.py যা আমদানি করা হলে, ইংরেজিতে উক্তিগুলি মুদ্রণ করে।

যে লেখাটি প্রদর্শিত হচ্ছে তা ১৯টি ছোট বাক্যের একটি সিরিজ যা পাইথনের নকশা দর্শনের সারসংক্ষেপ তুলে ধরে। বলা হয় যে পিটার্স ২০টি নীতির কথা বলেছিলেন, কিন্তু তিনি মাত্র ১৯টি লেখা রেখে গেছেন, বিংশ শতাব্দীকে একটি "ভৌতিক" উক্তি হিসেবে রেখে যা প্রতিটি ব্যক্তি ব্যাখ্যা করতে পারে বা মানসিকভাবে পূরণ করতে পারে।

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

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

১৯টি জেন ​​সূত্র এবং তাদের ব্যবহারিক তাৎপর্য

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

১. সুন্দর, কুৎসিতের চেয়ে ভালো

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

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

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

2. স্পষ্ট, অন্তর্নিহিতের চেয়ে ভালো

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

একটি খুব সাধারণ উদাহরণ হল এই ধরনের জিনিস এড়িয়ে চলা from math import *যা একটি মডিউলের সমস্ত বিষয়বস্তু বর্তমান নেমস্পেসে নিয়ে আসে, কোনটি ব্যবহার করা হচ্ছে তা স্পষ্ট না করে। এটি লেখা ভালো from math import sqrt, sin, cos এবং স্পষ্টভাবে কী প্রয়োজন তা বলা।

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

৩. জটিলের চেয়ে সরলতা ভালো

এখানে ধারণাটি হল, যখন আপনার কাছে বিকল্প থাকে, জটিল সমাধানের পরিবর্তে সহজ সমাধানটি বেছে নিন।এটি যেকোনো মূল্যে সমস্ত জটিলতা এড়ানোর বিষয়ে নয়, বরং মনে রাখার বিষয়ে যে কোড একবার লেখা হয় এবং বহুবার পড়া হয়।

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

উদাহরণগুলি প্রায়শই বাস্তবায়নের বিপরীতে থাকে যেখানে সবকিছু একটি একক রহস্যময় লাইনে কিছুটা দীর্ঘ সংস্করণের সাথে সমাধান করা হয়, কিন্তু স্পষ্ট এবং সু-সংজ্ঞায়িত লজিক্যাল ব্লকযা ব্যাখ্যা করা অনেক সহজ।

৪. জটিলের চেয়ে জটিল ভালো

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

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

অর্ডার করা পছন্দ সাধারণত সংক্ষেপে বলা হয় সরল > জটিল > জটিলঅন্য কথায়, যদি সম্পূর্ণ সরল হওয়া সম্ভব না হয়, তাহলে অন্তত জটিলতাটিকে কাঠামোগত হতে দিন এবং একটি অপাঠ্য বিশৃঙ্খলা নয়।

৫. বাসা বাঁধার চেয়ে সমতল ভালো

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

অন্তহীন বাসা এড়ানোর জন্য একটি সাধারণ কৌশল হল কোডের কিছু অংশ ছোট সহায়ক ফাংশনে বের করুনঅথবা আরও সরাসরি নিয়ন্ত্রণ কাঠামো ব্যবহার করুন (যেমন elif পরিবর্তে else: if ... (নেস্টেড)। আপনি জেনারেটর বা পিওর ফাংশনও ব্যবহার করতে পারেন যা আপনাকে লুপের মধ্যে লুপ ছাড়াই সংগ্রহ প্রক্রিয়া করতে দেয়।

পাইথনে, এর মধ্যে তিনটি নেস্টেড ফর লুপকে চেইনড জেনারেটর ফাংশনের একটি সিরিজে রূপান্তর করা জড়িত থাকতে পারে; সি-তে, খুব গভীর ফাংশনগুলিকে কয়েকটি চ্যাপ্টা ফাংশনে ভাগ করুন এটি প্রতিটি অংশের দৃশ্যমান এবং যৌক্তিক জটিলতা হ্রাস করে।

৬. ঘনের চেয়ে বিচ্ছুরিত ভালো

অত্যন্ত কম্প্যাক্ট কোড প্রথম নজরে মার্জিত মনে হতে পারে, কিন্তু এটি প্রায়শই একটি যার ভরণপোষণ করতে হয় তার জন্য কষ্টজেন শ্বাস-প্রশ্বাসের জায়গা ত্যাগ করতে উৎসাহিত করে: লজিক্যাল ব্লকগুলিকে বিভিন্ন লাইনে বিভক্ত করা, প্রয়োজনে স্পেস এবং লাইন ব্রেক প্রবর্তন করা।

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

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

৭. পঠনযোগ্যতা গুরুত্বপূর্ণ

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

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

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

৮. বিশেষ ঘটনাগুলি এতটা বিশেষ নয় যে নিয়ম ভাঙার প্রয়োজন হয়।

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

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

এই নীতিটি বিশেষভাবে প্রাসঙ্গিক যখন একটি বৃহৎ দলে API, ডেটা ফর্ম্যাট বা স্টাইল নির্দেশিকা ডিজাইন করা হয়, যেখানে প্রতিটি ব্যতিক্রমই একটি চ্যালেঞ্জের প্রতিনিধিত্ব করে। সকলের জন্য অতিরিক্ত জ্ঞানীয় বোঝা.

৯. যদিও বিশুদ্ধতার চেয়ে ব্যবহারিকতার জয় হয়

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

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

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

১০. ভুল কখনোই উপেক্ষা করা উচিত নয়।

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

জেন সুপারিশ করে যে, খুব ইচ্ছাকৃত সিদ্ধান্তের ক্ষেত্রে ব্যতীত, ত্রুটিগুলি দৃশ্যমান করা উচিত: কেবলমাত্র উদ্দেশ্যপ্রণোদিত প্রকারগুলি ধরে রাখা উচিত, সেগুলি রেকর্ড করা উচিত লগ, Que স্পষ্ট বার্তা পাঠান অথবা সিস্টেম যদি পুনরুদ্ধার করতে না জানে তবে কার্যকর করা বন্ধ করে দিতে পারে।

সি তে, পদ্ধতিগতভাবে রিটার্ন কোড উপেক্ষা করা বা নাল পয়েন্টার পরীক্ষা না করা এটি রক্ষণাবেক্ষণকে দুঃস্বপ্নে পরিণত করার একটি নিশ্চিত উপায়।

১১. যদি না তাদের স্পষ্টভাবে চুপ করা হয়

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

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

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

১২. যখন অস্পষ্টতার মুখোমুখি হন, তখন অনুমান করার প্রলোভন প্রত্যাখ্যান করুন।

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

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

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

১৩. এটি করার একটি মাত্র সুস্পষ্ট উপায় থাকা উচিত

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

একটি ক্লাসিক উদাহরণ হল সিকোয়েন্সের উপর পুনরাবৃত্তি। পাইথনে, একটি খুব নির্দিষ্ট পদ্ধতি প্রচার করা হয়: for elemento in secuencia:প্রয়োজন ছাড়া ম্যানুয়াল ইনডেক্সিং জোর করার পরিবর্তে, এটি পঠন লুপগুলিকে প্রায় তুচ্ছ করে তোলে।

সি-এর ক্ষেত্রে, এই মনোভাব দলগত পর্যায়ে গ্রহণের মধ্যে অনুবাদ হতে পারে, পুনরাবৃত্ত ক্রিয়াকলাপের জন্য স্ট্যান্ডার্ড প্যাটার্ন: প্রতিটি ডেভেলপার তাদের নিজস্ব স্টাইল আবিষ্কার করার পরিবর্তে অ্যারে অতিক্রম করার, মেমরি পরিচালনা করার বা ত্রুটি পরিচালনা করার একটি সাধারণ উপায়।

১৪. যদিও প্রথমে সেই পদ্ধতিটি স্পষ্ট মনে নাও হতে পারে (যদি না আপনি ডাচ হন)

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

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

যেকোনো অনানুষ্ঠানিক "জেন সি"-এর ক্ষেত্রেও একই রকম কিছু ঘটতে পারে: ভাষা অভিজ্ঞদের কাছে যা স্পষ্ট মনে হয় (কীভাবে পয়েন্টার ব্যবহার করতে হয়, কীভাবে শিরোনাম সংগঠিত করতে হয়, কীভাবে একটি প্রকল্প গঠন করতে হয়) তা এই বিষয়ে নতুন কারো কাছে খুব স্পষ্ট হতে পারে না।

১৫. এখন আগের চেয়ে ভালো, যদিও কখনও না থাকা প্রায়শই এখনকার চেয়ে ভালো।

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

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

আদর্শ পদ্ধতি হল সাধারণত সিস্টেমের বিবর্তনকে একটি হিসাবে বিবেচনা করা পুনরাবৃত্তিমূলক প্রক্রিয়া: পরিমাপিত পরিবর্তনগুলি প্রবর্তন করুন এবং তাদের প্রভাব মূল্যায়ন করুনপরিমার্জন করুন... এবং একটি স্পষ্ট করণীয় তালিকা বজায় রাখুন যাতে গুরুত্বপূর্ণ বিষয়গুলি "চিরকালের জন্য" ছেড়ে না যায়।

১৬. যদি বাস্তবায়ন ব্যাখ্যা করা কঠিন হয়, তাহলে এটি একটি খারাপ ধারণা।

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

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

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

১৭. যদি বাস্তবায়ন ব্যাখ্যা করা সহজ হয়, তাহলে এটি একটি ভালো ধারণা হতে পারে।

আগের কথার বিপরীত দিক হল, যখন আপনি একটি সমাধান স্পষ্ট, সংক্ষিপ্ত এবং সরল ভাষায় বর্ণনা করতে পারেন, তখন আপনি সম্ভবত সঠিক পথে আছেন। এটি গ্যারান্টি দেয় না যে ধারণাটি নিখুঁত, তবে এটি একটি ভাল লক্ষণ যে আপনি সঠিক পথে আছেন। জটিলতা নিয়ন্ত্রণে আছে.

এই নীতিটি "রাবার ডাক কৌশল"-এর মতো অনুশীলনের সাথে খুব ভালোভাবে সম্পর্কিত: আপনার কোড অন্য ব্যক্তির (অথবা একটি জড় বস্তুর) সাথে কী করে তা জোরে জোরে ব্যাখ্যা করলে অসঙ্গতিগুলি সনাক্ত করতে এবং যখন কিছু ভালভাবে চিন্তা করা হয় তখন নিশ্চিত হতে সাহায্য করে।

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

১৮. নেমস্পেস একটি দারুন আইডিয়া: আসুন এগুলো আরও বেশি করে করি।

শেষ উক্তিটি কোড সংগঠিত করার এবং সংঘর্ষ এড়ানোর জন্য নেমস্পেসের গুরুত্ব তুলে ধরে। পাইথনে, মডিউল, প্যাকেজ, ক্লাস এবং ফাংশন বিভিন্ন স্তরের সংগঠন প্রদান করে। দায়িত্বের পরিপূর্ণতা এবং পৃথকীকরণ.

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

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

স্প্যানিশ ভাষায় অনুবাদ এবং সাংস্কৃতিক সূক্ষ্মতা

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

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

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

পাইথনের জেন কি রসিকতা নাকি পবিত্র নিয়ম?

পাইথন সম্প্রদায়ের মধ্যেই জেনের সঠিক অবস্থা নিয়ে কিছু বিতর্ক রয়েছে। একদিকে, অনেক আনুষ্ঠানিক নথি (PEPs) এটিকে সিদ্ধান্তের প্রেরণা বা ন্যায্যতা, এবং মূল ডেভেলপারদের মেইলিং তালিকায় এটি নির্দিষ্ট প্রস্তাবের পক্ষে বা বিপক্ষে যুক্তি হিসেবে ব্যবহৃত হয়।

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

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

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

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