অনুভূমিকভাবে স্ক্রোল করা কোড কম পাঠযোগ্য?


12

আচ্ছা, তাই না? এটা খারাপ অভ্যাস হিসাবে বিবেচনা করা হয়?

আইএমও, এটি কম পাঠযোগ্য। আমি ডানদিকে স্ক্রোল করতে ঘৃণা করি, তারপরে পিছনে বাম, ডান, বাম এবং আরও কিছু। এটি কোডিংকে আরও বেদনাদায়ক করে তোলে এবং মাঝে মাঝে আমাকে বিভ্রান্ত করে।

উদাহরণস্বরূপ, যে কোনও সময় আমি একটি দীর্ঘ স্ট্রিং কোডিং করছি, আমি নিম্নলিখিতটি করব ...

bigLongSqlStatement = "select * from sometable st inner join anothertable at" +
"on st.id = at.id" +
"and so on..." +
"and so on..." +
"and so on..."

15
হ্যাঁ এটা করে. (এবং ছড়িয়ে পড়া লাইনগুলিতে প্রবেশ করতে ভুলবেন না)
জাভিয়র

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

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

ওভারওয়াইড কলামগুলি যে কোনও কিছু কম পঠনযোগ্য করে তোলে। এটি অনেকবার নির্ধারিত হয়েছে।
ডেভিড থর্নলি

2
আমি রাজী. আপনার সম্পাদককে কত বিস্তৃত করতে হবে সে সম্পর্কে সকলেই একমত হচ্ছেন সমস্যা। অতিরিক্ত প্রশস্ত কোডে আমি সাধারণত আমার কাছে র্যাপটি সেট করে রাখি যদি এটিতে একটি টন পড়তে হয়।
কার্ল বিলেফেল্ট

উত্তর:


19

হ্যাঁ, প্রকৃত অর্থে এটি আক্ষরিক অর্থে এবং সাধারণ অর্থেও রয়েছে।

আমি পাশাপাশি-পাশের কোডগুলি আলাদা করতে পছন্দ করি এবং খুব প্রশস্ত লাইনগুলি আরও শক্ত করে তোলে:

http://i.stack.imgur.com/fWVuz.jpg

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


11

হ্যাঁ, আমি মনে করি প্রতি লাইনে 80 টি অক্ষর যুক্তিসঙ্গত এবং সাধারণত ব্যবহৃত হয়।


6

এটা আমার কাছে সত্যিই গুরুত্বপূর্ণ প্রশ্ন! আমি একটি 13 "সহকর্মীদের সাথে 24" ডেস্কটপ মনিটরের সাথে ল্যাপটপে 7 মাস পরিশ্রম করেছি এবং আমি পঠনযোগ্য কিছু শেষ করতে নিজেকে অনেক সময় ব্যয় করতে দেখলাম।

80 টি কলামগুলি প্রচুর ক্ষেত্রে কিছুটা ছোট (যদি আপনি কেবলমাত্র vi এর সাথে টার্মিনালে কাজ করছেন তবে); তবে ~ 150 ডলারের বেশি বেশি (নীচে দেখুন)।

এটি খাঁটি 'পঠনযোগ্যতা' প্রশ্নের জন্য।

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

CGPoint point = CGPointMake(someOtherView.frame.origin.x + someOtherView.frame.size.width, someOtherView.frame.origin.x + someOtherView.frame.size.height);

অনুগ্রহ করে নোট করুন 3 টি মাত্রিক ভেক্টর বা ম্যাট্রিক্সের সাথে কাজ করার সময় এটি আরও নিকৃষ্ট হয়ে উঠতে পারে।

লিখিত উদাহরণ:

CGRect frame = someOtherView.frame;
CGPoint origin = frame.origin;
CGSize size = frame.size;
CGPoint point = CGPointMake(origin.x + size.width, origin.x + size.height);

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


4

সর্বদা না।

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

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

সব বলার পরেও আমি অবশ্যই খুব বেশিবার অনুভূমিকভাবে স্ক্রোল করতে চাই না, তবে এই প্রশস্ত স্ক্রীন মনিটরের দিনগুলিতে আমি এটিকে কমই খুঁজে পাচ্ছি।


2
আমি জানতাম না যে কিছু প্রোগ্রামের বিট অন্যদের চেয়ে গুরুত্বপূর্ণ। আমি আমার উত্পাদনশীলতাটি সেভাবে উন্নত করার চেষ্টা করব: কেবলমাত্র গুরুত্বপূর্ণ বিটকে কোডিং।
mouviciel

1
@ মউভিসিয়েল, এটি কোডের বাম দিকটি বেশি গুরুত্বপূর্ণ তা নয়, তবে শব্দার্থে কোডটির বাম পাশটি কোডের লাইনটি ডানের চেয়ে কী করে তা বোঝার ক্ষেত্রে আরও তাত্পর্যপূর্ণ। আপনি কোডটি স্ক্যান করার সাথে সাথে, আপনি প্রায়শই লাইনের শুরুতে পড়েন এটি বুঝতে পরবর্তী পদক্ষেপে যাওয়ার আগে এটি কী করে।
ক্রিস নাইট

1
আমার জন্য, কোনও পদ্ধতিতে দেওয়া আর্গুমেন্টগুলির পদ্ধতির নামের মতো তাত্পর্য রয়েছে। এই তথ্যটি রেখে কোড অনুধাবন করার চেয়ে আরও বেশি কী করে তা অনুমানের দিকে নিয়ে যায়।
mouviciel

1

হ্যাঁ এটা করে.

ঘটনাচক্রে একটি টিপ। যদি আপনি একাধিক-লাইন স্ট্রিং (কার্যত সমস্ত স্ক্রিপ্টিং ভাষাগুলি তাদের থাকে) ব্যবহার করে এবং দীর্ঘ এসকিউএল অন্তর্ভুক্ত করে থাকেন তবে এটি এসকিউএলটির জন্য সামঞ্জস্যপূর্ণ ফর্ম্যাটিং নিয়মগুলি ব্যবহার করে এসকিউএলকে একটি বহু-লাইন স্ট্রিংয়ে রাখতে পঠনযোগ্যতাটিকে সত্যই সহায়তা করে। আমি যে ফর্ম্যাটিং শৈলীটি ব্যবহার করি তার জন্য http://bentilly.blogspot.com/2011/02/sql-formatting-style.html দেখুন ।


1

না, তা হয় না।

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

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

হিসাবে প্রদর্শিত

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
    labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco 
    laboris nisi ut aliquip ex ea commodo consequat.

অথবা বর্তমান ভাষার জন্য যে কোনও ইন্ডেন্টেশন স্তরটি ডিফল্ট হিসাবে সেট করা আছে।

আমার স্ক্রিনের চেয়ে বৃহত্তর রেখাগুলি কখনও ম্যানুয়ালি লাইন-মোড়ক-ইনডেন্ট কোডের তুলনায় কোডকে কম পঠনযোগ্য করে না।

সম্পাদনা: ooooh, আমি জানতাম এই উত্তরটি অপ্রিয় হবে :)


2
তোমার জন্য ভালো. তবে আপনি যদি এমন কোনও সম্পাদককে যেতে চান যা এই বৈশিষ্ট্যটি নেই?

1
@ ডানসমোরব: আপনি এমন কোনও সম্পাদককে কেন সরে যাবেন যা এতটাই পুরানো যে এটি এমনকি শব্দ মোড়ানো সমর্থন করে না (যদি না আপনি ত্রিশ বছর আগে লিখিত উত্স কোডটিতে কাজ করেন এবং এমন কোনও লিগ্যাসি প্ল্যাটফর্মে কাজ করেন যেখানে আপনার কোনও সঠিক পছন্দ নেই) সম্পাদক)?
আর্সেনি মোরজেঙ্কো

মাইনমা, আমি আপনার লাইন মোড়ানোর ইন্ডেন্টেশন বৈশিষ্ট্যটি উল্লেখ করছি।

@ ডানসমোরব: নিখুঁতভাবে বলতে গেলে, লম্বা রেখাগুলি যদি অস্বাভাবিক হয় তবে কেবল কথার মোড়কই যথেষ্ট যথেষ্ট
আমারা

7
কেবলমাত্র আপনার সম্পাদক কোনও লাইন মোড়ানো করতে পারে, তার অর্থ এই নয় যে এটি পাঠযোগ্যতার জন্য সবচেয়ে যুক্তিসঙ্গত জায়গা এটি মুড়ে ফেলবে।
ক্রেইজ

0

অবশ্যই হয়। সংবাদপত্র এবং ম্যাগাজিনগুলি কলামগুলি ব্যবহার করার একটি কারণ রয়েছে। পঠনযোগ্যতা একটি তাৎপর্যপূর্ণ বিষয়। পড়ার সময় আমাদের চোখ তুলনামূলকভাবে সামান্য পাশের চলাচল করে স্ক্যান করুন। এর প্রভাব হ'ল আমরা যা পড়ছি তা দ্রুত আমাদের স্ক্যান করতে দেয় to

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

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

বৃহত্তর রেখাগুলির জন্য একাধিক বিন্দুর সাথে শনাক্তকারী কোডিং কৌশলগুলি নির্দেশ করে যা সংশোধন করা উচিত।


0

মাউস-চাকাগুলি উল্লম্বভাবে দ্রুত স্ক্রোল করা সহজ করে তোলে ... তুলনায় তুলনামূলকভাবে আনুভূমিকভাবে স্ক্রোল করা খুব ব্যয়বহুল।


0

অনুভূমিক স্ক্রোলিং এড়ান।

~ উইন্ডোজ ব্যবহারকারীর অভিজ্ঞতার ইন্টারঅ্যাকশন নির্দেশিকাগুলি পৃষ্ঠা 112

হ্যাঁ.

ইংরেজরা বাম থেকে ডানে পড়ত ফলে কনস্ট্যান্ট স্ক্রোলিং = অ-উত্পাদক হয়

এই কারণে আমি সর্বদা আমার আইডিইতে ভিজ্যুয়াল লাইনের গ্লিফগুলি সহ শব্দ মোড়ানো সক্ষম করি।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.