PDA

View Full Version : نام متغییر بسیار طولانی!!!



eshpilen
شنبه 07 دی 1392, 08:06 صبح
اخیرا این نوع جدید از نام متغییر را در پروژهء خویش افتتاح نمودیم:


‎$dont_enforce_autoloign_age_sever_side_when_cha nge_autologin_key_upon_login_is_zero


خوب بید؟ :لبخند:

راستش نام متغییر اینقدر طولانی در ادیتور برنامه نویسی هم یخورده مشکل سازه، ولی من اسم دیگری که بقدر کافی پرمحتوی و خوانا باشه و با رویه ای که در نامگذاری بقیهء متغییرهام پیروی کردم سازگاری کافی داشته باشه، به ذهنم نرسید.
اینطوری حداقل خود نام متغییر رو هرکجا که میبینم اطلاعات درموردش در خودش وجود داره و راحت و سریع میشه فهمید و به یاد آورد که داستان چی بوده.
ولی شاید یخورده دیگه زیادی طولانی باشه :متفکر:
از طرف دیگر باید پرسید حالا اشکالش چیه مگه!

MMSHFE
شنبه 07 دی 1392, 09:24 صبح
اشکالی نداره ولی بهتره camelCase یا PascalCase بگذارین و از Underscore استفاده نکنید. مثال:
‎$dontEnforceAutologinAtSeverSideWhenChangeAutol oginKeyUponLoginIsZero

qartalonline
شنبه 07 دی 1392, 09:35 صبح
نام متغییر تو حافظه فضا اشغال نمیکنه؟

MMSHFE
شنبه 07 دی 1392, 09:37 صبح
نه به اونصورت، چون یکبار جدول متغیرها ساخته میشه و از اون به بعد، نام متغیر موقع اجرای برنامه با مقداری که از آدرسش خونده میشه، جایگزین میشه.

eshpilen
شنبه 07 دی 1392, 10:11 صبح
اشکالی نداره ولی بهتره camelCase یا PascalCase بگذارین و از Underscore استفاده نکنید. مثال:
‎$dontEnforceAutologinAtSeverSideWhenChangeAutol oginKeyUponLoginIsZero
مهندس این طولش یخورده کوتاهتره ولی خوندنش بنظرم دشوارتر باشه.
ضمنا چون من در تقریبا تمام پروژم از آندرلاین استفاده کردم دیگه فکر نمیکنم درست باشه در یک مورد از استاندارد متفاوتی استفاده کنم.

eshpilen
شنبه 07 دی 1392, 10:13 صبح
نام متغییر تو حافظه فضا اشغال نمیکنه؟
ببین بیماری «وسواس در بهینه سازی» خیلی راحت ایجاد میشه.
ویروسش بدجوری مسریه :لبخند:

حالا گیریم که یخورده حافظه هم مصرف کرد؛ بیخیال بابا مهم نیست اصلا مگه چقدره چه تاثیری میذاره در عمل؟
شونصدتا متغییر اینطوری داشته باشی تازه اونوقت شاید اثرش در برنامه دیده بشه. تازه اونم شاید فقط با بنچمارک بشه مشخصش کرد.

MMSHFE
شنبه 07 دی 1392, 10:20 صبح
مهندس این طولش یخورده کوتاهتره ولی خوندنش بنظرم دشوارتر باشه.
ضمنا چون من در تقریبا تمام پروژم از آندرلاین استفاده کردم دیگه فکر نمیکنم درست باشه در یک مورد از استاندارد متفاوتی استفاده کنم.
از اونجا که معمولاً توی محیط کدنویسی از فونتهای Monotype و Fixed Width استفاده میشه، خوانایی لازم رو پیدا میکنه و ازطرف دیگه استانداردهای camelCase و PascalCase بصورت جهانی پذیرفته شده هستن و اکثراً توصیه میکنن از _ استفاده نشه. سفارش من هم بخاطر سازگاری بیشتر و عادت کردن به سبک کدنویسی استاندارد بود تا هم پروژه شما توسط سایرین راحتتر مورد استفاده قرار بگیره (در کارهای تیمی و مواردی که یکنفر بخواد جایگزین شما توی پروژه بشه) و هم خودتون وقتی بهش عادت کنید، سورسهایی که از اینترنت دریافت میکنید راحتتر قابل کار و درک خواهد بود. درنهایت تصمیم با خودتونه چون اون چیزی که شما باهاش راحتترین، تا وقتی که مشکل خاصی ایجاد نکنه، بهترین گزینه است.

qartalonline
شنبه 07 دی 1392, 10:21 صبح
ببین بیماری «وسواس در بهینه سازی» خیلی راحت ایجاد میشه.
ویروسش بدجوری مسریه :لبخند:

حالا گیریم که یخورده حافظه هم مصرف کرد؛ بیخیال بابا مهم نیست اصلا مگه چقدره چه تاثیری میذاره در عمل؟
شونصدتا متغییر اینطوری داشته باشی تازه اونوقت شاید اثرش در برنامه دیده بشه. تازه اونم شاید فقط با بنچمارک بشه مشخصش کرد.

من که بدجور وسواس هستم و همین عامل باعث شده بخوبی پیشرفت نکنم.

MMSHFE
شنبه 07 دی 1392, 10:28 صبح
نام متغییر تو حافظه فضا اشغال نمیکنه؟
ببینید، توی وب بطور خاص، همیشه کل برنامه شما در حافظه نیست. شاید از یک پروژه چند ده مگابایتی یا حتی چند صد مگابایتی (منظورم حجم سورس کدهاست)، در هر درخواست کاربر 5 تا یا 10 تا از کل فایلهای اسکریپت که شاید نهایتاً 2 الی 3 هزار خط بشه (در اکثر موارد) توی حافظه بارگذاری بشه و توی این حجم کد هم معمولاً بطور متوسط حدود 100 تا 150 تا متغیر تعریف میشه که اونهم براش جدول Lookup توی حافظه ساخته میشه و مواردی مثل اسامی طولانی (ولی خوانا) تأثیر آنچنانی روی Performance ندارن وگرنه اینهمه توصیه نمیشد که از اسامی خوانا و طولانی استفاده بشه و IDEهای پیشرفته هم بطور خودکار اسامی متغیرهای طولانی رو با تایپ چند حرف اول، ظاهر نمیکردن که انتخاب کنید. منظورم اینه که چنین قابلیتهایی که در IDEها گنجونده شده و توصیه هایی که توسط افراد خبره در این زمینه مطرح شده رو اگه در کنار هم بگذاریم، به این نتیجه میرسیم که استفاده از این روش، توسط عموم و علی الخصوص متخصصین این حرفه تأیید شده است. وگرنه دلیلی نداشت که ویژگی Auto Complete توی IDEها اضافه بشه و کلی براش کدنویسی کنن چون متغیرهای کوتاه نیازی به این قابلیت ندارن و به راحتی میشه بارها تایپشون کرد.

eshpilen
شنبه 07 دی 1392, 10:43 صبح
آره اصلا یکی از مواردی که توی منابعی که خوندم اشاره شده اینه که کامپایلرها، مفسرها، و زبانهای امروزی خودشون اینقدر لایه ها و روشها و الگوریتم های هوشمند بهینه سازی و تشکیلات دیگه دارن که نمیشه براحتی رفتار و بهینه سازی اونا رو تشخیص داد و بهینه کرد.

بخاطر همین توصیه میشه برنامه نویسان از حدس و تصور و اصولا فکر کردن زیاد و انگولک کردن برنامه هاشون بابت بهینه سازی های غیرضروری (بخصوص بهینه سازیهای جزیی) خودداری کنن، مگر اینکه اطلاعات کافی و موثق و اطمینان داشته باشن از تمام فرایند و نتیجهء اون و واقعا هم در عمل بقدر کافی لازم یا حداقل مفید باشه این کار.

گفته شده خیلی موارد هست که برنامه نویسان به خیال خودشون چیزی رو بهینه میکنن، اما در عمل اون بهینه سازی تقریبا هیچ تاثیری نداره و حتی ممکنه برعکس در عمل بجای اینکه بهینه بشه از بهینه بودن فاصله بگیره! یکی از علتهاش هم همینه که ممکنه بهینه سازی برنامه نویس در سطح کد خودش با الگوریتم و روشهای بهینه سازی و پیشفرضهای خود زبان و کامپایلر و مفسر و محیط اجرا دچار تضاد و ناسازگاری بشه.
مثلا چون خیلی ساختارها و روشهای بهینه سازی هستن که بر اساس آمار و احتمالات طراحی شدن و موقعی طراحی گفتن مثلا بیشتر برنامه ها/برنامه نویسان چنین چیزی و چنین نیاز و شرایطی در برنامشون میاد و فلان نوع کدها و داده ها با فلان شرایط میخواد به فلان خاطر و فلان طور استفاده و اجرا بشه، پس ما بر اساس این حالت و انتظار و احتمالات و آمار بهترین بهینه سازی رو که میتونیم انجام میدیم که در بیشتر موارد محتمل هست بهترین بازدهی رو داشته باشه. در نتیجه بهترین بهینه سازی یا الگوریتم استاندارد در داخل کامپایلر/مفسر و/یا زمان اجرا بر اساس اون پیشفرض ها کار میکنه. حالا شما میاید اون پیشفرض ها رو با وسواس در بهینه سازی و حدس و تصور خام خودتون بهم میریزید، در نتیجه ممکنه نتیجهء معکوس بگیرید! چون دیگه در برنامتون اون پیشفرض ها از نظر آماری و احتمالاتی نرمال و مورد انتظار نیستن و با الگوریتم های استاندارد و روشهای بهینه سازی خود مفسر و محیط اجرا سازگاری کمتری دارن یا حتی در تضاد هستند.

زبان سطح بالا انتظار داره شما طرز تفکر و عمل سطح بالا هم داشته باشید و تفکر و عمل سطح پایین و بهینه سازیهای جزیی رو به عهدهء زبان گذاشته باشید. اصلا این مستقیما برگرفته از علت وجودیش نیست مگه؟!

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