লিন্টিং হল সম্ভাব্য সমস্যার সন্ধানে কোড স্ট্যাটিকভাবে বিশ্লেষণ করার প্রক্রিয়া।
এই ক্ষেত্রে কী সমস্যা তৈরি করে, এই ক্ষেত্রে, প্রোগ্রামিং ল্যাঙ্গুয়েজ জুড়ে বা একই ভাষার মধ্যে প্রজেক্ট জুড়ে পরিবর্তিত হতে পারে৷ আমি এই সমস্যাগুলিকে কয়েকটি ভিন্ন বিভাগের অধীনে রাখব:
- প্রোগ্রাম্যাটিক
- নিরাপত্তা
- শৈলীগত
- পারফরম্যান্স
আসুন প্রতিটির কয়েকটি উদাহরণ দেখে নেওয়া যাক।
শৈলীগত সমস্যা
স্টাইলিং কোডের কোন বস্তুনিষ্ঠভাবে সঠিক উপায় নেই, কারণ এটি সবই পাঠকের পছন্দ সম্পর্কে। মূল যদিও ধারাবাহিকতা. বিতর্কের সাধারণ বিষয় অন্তর্ভুক্ত:
- ডাবল-কোট বনাম একক-উদ্ধৃতি
- ট্যাব বনাম স্থান
- সর্বাধিক লাইন দৈর্ঘ্য
- মাল্টিলাইন কলের ইন্ডেন্টেশন, যেমনটি নীচে দেখানো হয়েছে:
# always single-line
foo(:a, :b, :c)
# aligned with first argument
foo(:a,
:b,
:c
)
# aligned with function name
foo(
:a,
:b
)
এগুলি সম্পূর্ণরূপে বিষয়ভিত্তিক, কিন্তু সমগ্র কোডবেসকে সামঞ্জস্যপূর্ণ রাখতে প্রতিটি নির্দিষ্ট প্রকল্পের জন্য একটি স্ট্যান্ডার্ডে একমত হওয়া সাধারণত উপকারী৷
প্রোগ্রামেটিক সমস্যা
আমি এখানে এই ধরনের সমস্যাগুলি অন্তর্ভুক্ত করছি:
- অত্যন্ত দীর্ঘ মেথড বডি, যা পঠনযোগ্যতা এবং রক্ষণাবেক্ষণের সমস্যাগুলির দিকে নিয়ে যায়
- সাইক্লোমেটিক জটিলতা, একটি মেট্রিক যা সাধারণত কোড জটিলতা পরিমাপ করতে ব্যবহৃত হয়
- শর্তের মধ্যে অ্যাসাইনমেন্ট। সম্ভবত, আপনি যদি
if x = true
টাইপ করেন , আপনি আসলেif x == true
বোঝাতে চেয়েছেন . এবং এমনকি যদি আপনি একটি অ্যাসাইনমেন্ট বলতে চান, এটি এখনও একটি কম-স্বজ্ঞাত পদ্ধতি
নিরাপত্তা সমস্যা
কিছু ফাংশন বা অনুশীলনের সম্ভাব্য নিরাপত্তা সমস্যা রয়েছে যা বিকাশকারীরা সচেতন নাও হতে পারে৷
উদাহরণস্বরূপ, রুবিতে, Kernel#open
একটি নমনীয় ফাংশন যা ফাইল বা বহিরাগত URL খোলার অনুমতি দেয়। কিন্তু এটি open("| ls")
এর মতো অদ্ভুত কলগুলির সাথে নির্বিচারে ফাইল সিস্টেম অ্যাক্সেসের অনুমতি দেয় .অতএব, এটি সম্পর্কে ডেভেলপারদের সতর্ক করা বুদ্ধিমানের কাজ যাতে তারা হয় নিরাপদ পদ্ধতি ব্যবহার করতে পারে (File#open
, IO.popen
, URI.parse#open
), অথবা আচরণটি তাদের নিজস্ব ঝুঁকিতে রাখার জন্য স্পষ্টভাবে সিদ্ধান্ত নিন।
পারফরম্যান্স সমস্যা
রুবির অভ্যন্তরীণ কাজ সম্পর্কে অনেক বিশদ বিবরণ রয়েছে যা প্রেক্ষাপটের উপর নির্ভর করে কিছু বিকল্পকে অন্যদের তুলনায় আরও কার্যকর করে তোলে।
আমাদের প্রোগ্রামের কিছু বিশদ বিবরণ অপ্টিমাইজ করার সময় তাদের সম্পর্কে আমাদের সতর্ক করে দেওয়া একটি লিন্টার আমাদের পথে শিখতে সাহায্য করে৷
উদাহরণস্বরূপ, রুবি 2.5 String#delete_suffix
চালু করেছে যা একটি স্ট্রিং এর শেষ থেকে সাবস্ট্রিং মুছে দেয়। এই দুটি লাইন সমতুল্য, কিন্তু পরেরটি আরও কার্যকরী কারণ এটি একটি জেনেরিক স্ট্রিং রেজিক্সম্যাচের উপর নির্ভর করে না:
str = 'string_with_suffix'
# bad
str.gsub(/suffix\z/, '')
# good
str.delete_suffix('suffix')
অটো ফিক্সিং
লিন্টারগুলির একটি গুরুত্বপূর্ণ দিক হল কিছু বা সমস্ত পাওয়া সমস্যাগুলি স্বয়ংক্রিয়ভাবে ঠিক করার তাদের ক্ষমতা৷ লাইনের দৈর্ঘ্যের মতো স্টাইলিং দিকগুলি সহজেই স্বয়ংক্রিয় হয়, তাই এটি বিকাশকারীর কাছ থেকে সেই বোঝা অপসারণ করার জন্য বোধগম্য হয়৷ অন্যান্য সমস্যাগুলি বিষয়গত হতে পারে বা মানুষের হস্তক্ষেপের প্রয়োজন হতে পারে, যেমন একটি বড় পদ্ধতি asrefactoring. এই ক্ষেত্রে, কোন অটোমেশন সম্ভব নয়।
কনভেনশন বা কনফিগারেশন
একটি সম্প্রদায় বা প্রকল্পের মধ্যে প্রায়ই ভারী বিতর্ক হয় যার উপর নিয়মগুলি গুরুত্বপূর্ণ।
ঐতিহ্যগত সমাধান হল প্রতিটি দলকে তাদের নিজস্ব স্বাদ অনুযায়ী লিন্টিং নিয়মগুলি কনফিগার করার অনুমতি দিয়ে তাদের সদস্যদের মধ্যে বিতর্কের সমাধান করার অনুমতি দেওয়া৷ যাইহোক, সাম্প্রতিক বছরগুলিতে, একটি একক সম্মেলনের মানসম্মত করার জন্য বেশ কয়েকটি ভাষা জুড়ে চাপ দেওয়া হয়েছে৷ t সর্বত্র প্রয়োগ করা হয়, সাধারণ ধারণা হল স্টাইলিং কোড করার সময় থিমেন্টাল ওভারহেড ডেভেলপারদের সম্পূর্ণরূপে অপসারণ করা। কোন লাইনের দৈর্ঘ্য সবচেয়ে ভালো কাজ করে তা নিয়ে আলোচনা করার পরিবর্তে, সবাই শুধু সম্প্রদায়-সম্মত নিয়মগুলি ব্যবহার করে৷
৷রুবিতে, এটি কমবেশি দুটি বিদ্যমান লিন্টারে অনুবাদ করে:রুবোকপ, যা সম্পূর্ণ-কনফিগারেশন এবং স্ট্যান্ডার্ডআরবিকে অনুমতি দেয়, যা বিপরীত পদ্ধতি গ্রহণ করে এবং একটি সাধারণ মানকে সংজ্ঞায়িত করে।
রুবোকপ
নিয়মাবলীর একটি নথিভুক্ত সেট প্রদানের স্বাভাবিক পদ্ধতি ব্যবহার করে, যার প্রত্যেকটি একটি নির্দিষ্ট সমস্যার জন্য দেখায়। বিকাশকারীরা তাদের নিজস্ব প্রকল্পের মধ্যে কিছু নিয়ম অক্ষম বা পরিবর্তন করতে সক্ষম:
# configure max allowed line length
Layout/LineLength:
Max: 80
# disable cyclomatic complexity
Metrics/CyclomaticComplexity:
Enabled: false
এটি ইতিমধ্যেই বুদ্ধিমান ডিফল্টগুলি অন্তর্ভুক্ত করে, তাই কনফিগারেশন শুধুমাত্র নির্দিষ্ট নিয়মগুলির জন্য প্রয়োজন যা আপনি পরিবর্তন করতে চান৷
bundle exec rubocop
চলছে রুবোকপ সম্পূর্ণ কোডবেস বিশ্লেষণ করবে এবং এতে পাওয়া সমস্ত সমস্যা তালিকাভুক্ত করবে:
# test.rb
def badName
if something
return "inner result"
end
"outer result"
end
$ bundle exec rubocop
Inspecting 1 file
C
Offenses:
test.rb:1:1: C: [Correctable] Style/FrozenStringLiteralComment: Missing frozen string literal comment.
def badName
^
test.rb:1:5: C: Naming/MethodName: Use snake_case for method names.
def badName
^^^^^^^
test.rb:2:3: C: [Correctable] Style/IfUnlessModifier: Favor modifier if usage when having a single-line body. Another good alternative is the usage of control flow &&/||.
if something
^^
test.rb:3:12: C: [Correctable] Style/StringLiterals: Prefer single-quoted strings when you don't need string interpolation or special symbols.
return "inner result"
^^^^^^^^^^^^^^
test.rb:6:3: C: [Correctable] Style/StringLiterals: Prefer single-quoted strings when you don't need string interpolation or special symbols.
"outer result"
^^^^^^^^^^^^^^
1 file inspected, 5 offenses detected, 4 offenses auto-correctable
তারপর আপনি bundle exec rubocop --auto-correct
চালাতে পারেন , এবং আপনার বেশিরভাগ সমস্যা আপনার কনফিগারেশন অনুযায়ী ঠিক করা হবে।
bundle exec rubocop
সেট আপ করা হচ্ছে আপনার CI পাইপলাইনের অংশ হিসাবে প্রথমে লিন্টিং নিয়মগুলি পূরণ না করে কোনও কোডজেট নিশ্চিত করবে না৷
স্ট্যান্ডার্ডআরবি
একটি আরও সাম্প্রতিক প্রকল্প, যা আসলে হুডের নীচে RuboCop ব্যবহার করে৷ StandardRB-এর মূল লক্ষ্য একটি সম্পূর্ণ আলাদা লিন্টার তৈরি করা নয়, তবে এমন একটি স্ট্যান্ডার্ডে পৌঁছানো যা সবাই তর্ক করার পরিবর্তে ব্যবহার করতে পারে৷
লাইটনিং টক যেখানে এটি প্রথম ঘোষণা করা হয়েছিল তা অনুপ্রেরণা সম্পর্কে বেশ স্পষ্ট:যদি লোকেরা সিনট্যাকটিক বিশদ সম্পর্কে তর্ক করতে কম সময় ব্যয় করে এবং একটি সম্প্রদায়-ব্যাপী চুক্তির সিদ্ধান্তগুলিকে অনুসরণ করে, তাহলে আমরা সকলেই যা গুরুত্বপূর্ণ তা করতে আরও বেশি সময় ব্যয় করতে পারি:দুর্দান্ত পণ্য এবং লাইব্রেরি তৈরি করা৷
যেহেতু RuboCop নীচে ব্যবহার করা হয়েছে, আপনি যে আউটপুট পাবেন তা আসলে একই ফরম্যাটে। পার্থক্য হল যে আপনি কোনো নিয়ম কাস্টমাইজ করতে পারবেন না।
স্ট্যান্ডার্ডআরবি সম্প্রতি 1.0.0-এ পৌঁছেছে, যার মানে কোন নিয়মগুলি ব্যবহার করতে হবে সে সম্পর্কে বেশিরভাগ আলোচনা ইতিমধ্যেই তাদের সমস্যা পৃষ্ঠায় হয়েছে৷ আপনি যদি কোনও নির্দিষ্ট নিয়মের বিষয়ে যত্নবান বা অসম্মত হন তবে সম্ভাবনা রয়েছে যে আপনি সেখানে এটি সম্পর্কে একটি সম্পর্কিত আলোচনা দেখতে পাবেন৷
যদিও শেষ পর্যন্ত, আপনি আত্মবিশ্বাসী হতে পারেন যে এটি কিছু গভীরতার সাথে আলোচনা করা হয়েছে৷ একটি সমগ্র সম্প্রদায়ের পক্ষে সমস্ত পয়েন্টে 100% একমত হওয়া অসম্ভব৷ এই পদ্ধতির দর্শন হল যে লোকেরা নমনীয় এবং দ্বিমত করতে পারে এবং সিদ্ধান্তে প্রতিশ্রুতিবদ্ধ হতে পারে।
চূড়ান্ত চিন্তা
অতীতের প্রকল্পগুলিতে লিন্টিং নিয়মগুলি নিটপিক করার জন্য আমি গর্বিত হওয়ার চেয়ে বেশি সময় ব্যয় করার পরে, আমি অবশ্যই স্ট্যান্ডার্ডআরবি-এর পদ্ধতির মান দেখতে পাচ্ছি এবং যখনই সম্ভব আমি এটি ব্যবহার করার পরামর্শ দিই৷
বেশিরভাগ নিয়মের স্বয়ংক্রিয় সমাধান সহ আলোচনার ওভারহেড মুছে ফেলার সময় সামঞ্জস্যের সমস্ত সুবিধা বজায় রাখা আমাদেরকে আরও দক্ষতার সাথে আরও ভাল সফ্টওয়্যার সরবরাহ করতে এবং সত্যিই গুরুত্বপূর্ণ বিষয়গুলিতে ফোকাস করতে সহায়তা করে৷
অন্যান্য ভাষা অনুরূপ কম-কনফিগারেবিলিটি কোড ফরম্যাটার গ্রহণ করছে। mix formatter
এলিক্সিরে, এবং rustfmt
মরিচা উভয়ই কিছু কনফিগার করার অনুমতি দেয়, তবে সম্প্রদায়টি আশ্চর্যজনকভাবে স্ট্যান্ডার্ডের মধ্যে রেখে অনবোর্ডে রয়েছে।
এটা বলার সাথে সাথে, আপনি যদি এই অনুভূতির সাথে একমত না হন তবে রুবোকপ এখনও একটি সম্পূর্ণ বৈধ বিকল্প৷
পি.এস. আপনি যদি রুবি ম্যাজিক পোস্টগুলি প্রেস থেকে বের হওয়ার সাথে সাথে পড়তে চান তবে আমাদের রুবি ম্যাজিক নিউজলেটারে সাবস্ক্রাইব করুন এবং একটি পোস্টও মিস করবেন না!