اسامی صحیح کاراکترها

خیلی‌ها کاراکترها رو با کاربردشون میشناسن مثلا علامت مجموعه‌ها ولی نکته اینجاست که اسامی با کاربرد کاراکترها در اون حوزه منطبق شدند و در حوزه‌های دیگه ممکنه کاراکترها کاربردهای مختلفی داشته باشند پس بهتره مواقعی که می‌خوایم از اسم کاراکترها نام ببریم اون رو با توضیح کاربردش توی اون حوزه تشریح نکنیم و از اسم خود کاراکتر استفاده کنیم. اسامی درست یکسری از کاراکترهای پر کاربرد در برنامه‌نویسی رو لیست می‌کنم تا حواسمون بیشتر روی این موضوع باشه:

 

`	Backtick
~	Tilde
;	Semicolon
:	Colon
.	Period, Dot, Full stop, Point
-	Hyphen
_	Underscore
“	Double quotation
‘	Quotation
()	Parentheses
{}	Braces
[]	Brackets
< >	Right and Left angle brackets
@	At sign
|	Vertical bar
/	Slash
\	Back Slash
*	Asterix
?	question mark
!	Exclamation mark
♯	Sharp sign
#	Number sign, Hash, Pound sign

 

دریافت
حجم: 28.6 کیلوبایت

ویژگی فونت‌های monospaced

فونت‌هایی که برای کدنویسی استفاده می‌شوند یک ویژگی مشترک دارند اون هم monospaced بودن فونت است. این ویژگی توی خیلی از فونت‌ها مثل Courier هستش. فونتهای monospaced تمام کاراکترهاشون(حروف، اعداد و کاراکترهای ویژه) فاصله افقی هر کاراکتر از چپ‌ترین تا راست‌ترین باهمدیگه یکی هستش

این ویزگی خیلی به خوانایی کدها کمک میکنه چون کد به خاطر یکی بودن فاصله افقی هر ۲ سر کاراکترها یه حالت جدولی پیدا میکنه چون دقیقا کاراکترها زیر همدیگه قرار می‌گیرند و برای همین چشم خیلی  راحتتر حروف رو دنبال میکنه

اگه می‌خواین برای شخص یا گروهی توی تلگرام کد بفرستید از سه تا کاراکتر بک تیک (backtick) استفاده کنید سرور تلگرام متن شما رو با فونت monospaced نشون میده

The Zen of Python

حدودا ۱۵ سال پیش مهندس نرم‌افزار Tim Peters به طور خلاصه راهنمایی را جهت آشنایی با فلسفه پایتون منتشر کرد که در ابتدا قرار بود ۲۰ مورد باشد که ۱۹ تای آن نوشته شد.

تائوی برنامه نویسی

استاد برنامه نویس بدین گونه به سخن درآمد: «هنگامی که سه روز بدون برنامه نویسی سپری شود، زندگی معنای خود را از دست خواهد داد.»

نویسنده جفری جیمز، مترجم آیدین غریب نواز

دریافت پی دی اف تائوی برنامه نویسی
حجم: 201 کیلوبایت

>>> import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!