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

[BITNEVIS]

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

[olampiad]

سلام
تشکر بابت تاپیک فوق العادتون
عالیه

[BITNEVIS]

با سلام و کسب اجازه از اساتید  مجدد اولینش رو مینویسم 

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

for($i =0; $i < count($array);$i++){
echo 'This is bad, my friend';
}
 

$total = (int)count($array);
for($i =0; $i < $total;$i++){
echo 'This is great, my friend';
}

در مثال بالا مدر حلقه اول هر سری در هر بار اجرای حلقه شرط حلقه با  تابع count() اجرا میشه که خود اجرا شدن count() زمان بره ولی در حلقه پایینی یک بار خانه های آرایه رو با تابع count() خونده ایم و ان رو در متغیر گذاشتیم پس دیگه در هر بار اجرای حلقه برای بررسی شرط نیاز نیست یک تابع اجرا بشه.

[BITNEVIS]

تا جایی که ممکنه برای چک کردن اینکه مقدار بازگشتی ما غیر صفر هستش بهتره که که از isset بجای توابع

count( )
strlen( )
sizeof( )

زیر استفاده کنیم
بطور مثال فرض کنیم که ما تابعی داریم که آرایه ای را یا با داشتن مقادیری و یا Null بر میگرداند.
حالا ما میخوایم بررسی کنیم که آرایه return شده null هست یا نه ؟

if(isset($returnValue)){
  // do something here
}

روش بالایی از روش پایینی بهینه تر می باشد.

if(count($returnValue) > 0){
  // do something here
}

[BITNEVIS]

استفاده از echo به جای Print برای نمایش متن
سرعت echo نسبت به print بالاتره و دلیل این امر هم ساده است ،  دستور print علاوه بر نمایش متن دلخواه شما مقداری بازگشتی رو مبنی بر انجام شدن یا نشدن درخواست رو برمیگرداند در صورتی که echo فقط متن مورد نظر رو چاپ میکنه و پردازش بیش تری رو انجام نمیده.
پس (در صورتی که می خواهید متنی رو نمایش بدهید و نیازی به مقدار بازگشتی مبنی بر انجام  شدن یا نشدن نمایش متن مورد نظر  خود را ندارید از echo استفاده کنید.)

منبع : https://ilia.ws/archives/12-PHP-Optimiza...ricks.html

[BITNEVIS]

همون طور که میدونید ما به چهار روش میتونیم مقدار متغیر خودمون رو یک واحد افزایش یا کاهش بدیم 

$i++;
$++i
$i+=1;
$i = $i + 1;

ظاهراَ استفاده از ++$i حدود ده درصد از $i++ سریع تره (منبع : http://www.hackingwithphp.com/18/1/8) 





استفاده از === به جای == 
همون طور که میدونیم عملگر === شرط برابر بودن مقدار عملوند ها رودر صورت هم نوع بودن آنها صحیح میدونه (بازه کمتر در شرط مساوی بودن نسبت به ==) ولی عملگر == فقط بررسی میکنه که مقدار دو عملوند مساوی هستند (بدون در نظر گرفتن نوع آنها ) این یعنی بازه بیشتری رو برای مقایسه باید در نظر بگیره . 

if("1" == 1)
   echo "true";
else
   echo "false";

خروجی بالا true هست .

if("1" === 1)
   echo "true";
else
   echo "false";

خروجی بالا false هست.

پس در صورتی که میدونیم دو عملوند ما نوعشون برابر هست اگر از === استفاده کنیم سرعت بیش تری نسبت به == داریم.

[BITNEVIS]

کم کردن تعداد دفعات اتصال به دیتابیس و جداول

<?php
  $con=mysqli_connect("localhost","username","somepassword","anydb");
  
  if (mysqli_connect_errno())
  {
    echo "Failed to connect to MySQL" ;
	mysqli_connect_error(); 
  }

  function insertValue( $val ){
    mysqli_query($con,"INSERT INTO tableX (someInteger) VALUES ( $val )");
  }
  
  for( $i =0; $i<999; $i++){
    //  Calling function to execute query one by one 
    insertValue( $i );
  }					
  // Closing the connection as best practice		
  mysqli_close($con);

?> 

کد پایین از کد بالا خیلی سریع تر اجرا میشه 

<?php
  $con=mysqli_connect("localhost","username","somepassword","anydb");
  if (mysqli_connect_errno())
  {
  	echo "Failed to connect to MySQL" ;
  	mysqli_connect_error(); 
  }
   
  function insertValues( $val ){
     // Creating query for inserting complete array in single execution.
    $query= " INSERT INTO tableX(someInteger) VALUES .implode(',', $val)";      
    mysqli_query($con, $query);
  }
  
  $data = array();
  for( $i =0; $i<999; $i++){
    // Creating an array of data to be inserted.
    $data[ ]  =   '(" ' . $i. '")' ;
  }
  // Inserting the data in a single call
  insertValues( $data );
  // Closing the connection as a best practice
  mysqli_close($con);

?> 

[BITNEVIS]

ارسال از طریق مقدار Arguments passed by value   
ارسال از طریق آدرس Arguments passed by reference 

فرستادن مقادیر به صورت ارجاعی &  ( Pass reference ) درصورتی که با منطق برنامه سازگاری داشته باشه .
دلیل : بطور مثال در صورتی که ما بخوایم یک متغیر رو به صورت ارجاعی به تابع بدیم  در حقیقت ما اومدیم و آدرس خود متغیر رو دادیم به تابع و هم هر تغییراتی رو که دوست داره میتونه مستقیماً روی متغیر انجام بده ولی در روش غیر ارجاعی ما میایم و یک کپی از متغیر رو به تابع میدیم که همین عمل کپی گرفتن از متغیر و در صورت نیاز return مقدار نهایی  خودش نیاز زمانی و همچنین حافظه ای رو برای ما بوجود میاره .

[Eshpilen]

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

در موارد دیگر، سرعت و راحتی کدنویسی، کاهش حجم و پیچیدگی برنامه، و خوانایی، اولویت اکید دارن.

دلیلش رو بگم خودتون ببینید معقول هست یا نه.

مثلا یک اسکریپت PHP شما 0.1 ثانیه زمان صرف میکنه.
شما فکر میکنید از این 0.1 ثانیه چه مقداری چه درصدی از اون چه کسری از اون سر اینطور عملیات پایه مثل افزایش مقدار متغییرها یا حتی اجرای count در قسمت شرط حلقهء for صرف میشه؟ فکر میکنم بتونید موافقت کنید که این درصد بسیار کوچک است! چون پردازشهای خیلی بیشتر و زمانبرتری در بخشهای دیگر برنامه صورت میگیرن که عمدهء پردازش و زمان برنامه توسط اونها مصرف میشه. پردازشهایی مثل اتصال و کوئری های دیتابیس، خوندن و دستکاری فایلها، عملیات رمزنگاری و غیره. اصولا برنامه ای که چنین پردازشهای بزرگی نداشته باشه، معمولا هیچ مشکل پرفورمنس نداره و مثلا در یک 0.01 ثانیه اجرا میشه. چنین برنامه ای معمولا نیاز به هیچگونه بهینه سازی نداره.

خب فرض کنید از اون 0.1 ثانیه زمان کل اجرا، 0.01 ثانیه اش متعلق به موارد عملیات پایه ای است که ذکر کردید (مثل افزایش مقدار متغییرها و count). من فکر کنم تخمین عاقلانه ای باشه!
حالا شما این 0.01 ثانیه رو نهایت چقدر میخواید بهینه سازی کنید کم کنید؟ هیچوقت بیشتر از کل این زمان، یعنی 0.01 ثانیه، نمیتونید دستاوردی بدست بیارید. غیر از اینه؟ در بهترین حالت در بالاترین حد بهینه سازی ممکن، شما میتونید این 0.01 ثانیه رو تقریبا به صفر برسونید، که در این حالت سرعت کلی برنامهء شما تنها 0.01 ثانیه افزایش پیدا میکنه و بجای 0.1 میشه 0.09 ثانیه، و این یعنی 10% افزایش سرعت. و البته بخاطر اینکه سرعت کلی برنامهء شما قبل از بهینه سازی هم بقدر کافی خوب بوده، این 10% افزایش سرعت به احتمال زیاد در عمل برای کسی آنچنان محسوس نخواهد بود و سود خاصی برای سایت شما نخواهد داشت!

من میخوام بگم در بهینه سازی، این فقط اختلاف های نسبی سرعت روشهای انجام یک کار نیستن که مهم هستن، این به تنهایی مهم نیست که سرعت فلان تابع از تابع دیگر 100 برابر بیشتره، بلکه باید دید عملیاتی که با این توابع انجام میشن چه کسری از کل پردازش و زمان صرف شده توسط برنامه هستن، و بازهم نکتهء دیگر که در عمل تاثیرگذاره اینکه سرعت برنامه همینطوریش آیا در حد مناسبی هست یا نه، چون برنامه ای که داره در 0.01 ثانیه اجرا میشه عمدتا نیاز به بهینه سازی نداره و اگر شما بیاید با صرف کلی وقت و انرژی سرعت اون رو دوبرابر بکنید زمان اجرا رو به 0.005 ثانیه برسونید بازم در خیلی موارد عملا سودی نخواهد داشت! کسی نه متوجه میشه و نه احتمالا ترافیک شما اونقدری بالا هست و منابع پردازشی اشباع شده که این افزایش سرعت بتونه مشکلی از مشکلاتی رو که واقعا وجود داشتن حل بکنه! تازه اینجا بحث bottleneck رو هم داریم، بدین معنا که خیلی و براحتی ممکنه در چنین شرایطی بخشها و عملیات خاصی از برنامه مبدل به bottleneck های جدید و جدی بشن که در نتیجه اجازه نمیدن سرعت برنامهء شما از یک حدی بیشتر بشه. مثلا ممکنه در اون ترافیک بالا، دیتابیس به مشکلات قابل توجهی برخورد کنه و متوجه بشید این همه بهینه سازی که کردید عملا سودی نداره چون حالا دیتابیس و ساختارهای دیگری هست که از محدودهء بهینه بودن و کارایی و طراحی خودشون خارج شدن و باید عوض بشن تا برنامه بتونه نفس بکشه! مثل اینکه شما اتومبیل پورشه سوار باشید ولی مجبورید توی خیابانهای معمولی شهر با ترافیک سنگین حرکت کنید و بارها و مدت زمان زیادی پشت چراغ قرمز توقف کنید، در این صورت شتاب و سرعت اتومبیل پورشه هرچقدر هم که باشه ولی عوامل دیگری هستن که سرعت شما رو محدود میکنن و هیچوقت نمیتونید از اون شتاب و سرعت سود قابل توجهی ببرید. bottleneck به قسمتهای محدود کننده در برنامه گفته میشه. چه اهمیتی داره شما بقیهء عملیات و پردازش برنامه رو در 0.0001 ثانیه انجام داده باشید، وقتی یک بخش دیگه 2 ثانیه باید زمان صرف بکنه؟ شما باید از اول بجای صرف اون همه وقت و انرژی روی اون بخشهایی که افزایش سرعتشون درحد صدم های ثانیه بود، روی بهینه سازی اون بخشهای چند ثانیه ای تمرکز میکردید. غیر از اینه؟

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

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

فکر نمیکنم هیچ برنامه نویسی اونقدری بیکار باشه وقت و انرژی اضافه داشته باشه که بخواد صرف بهینه سازیهایی اینقدر جزیی بکنه، با وجود این همه کار مهمتر این همه نقص و چیزهای مهم و کاربردی برای یاد گرفتن و برنامه ها و کدهای بیشتر برای نوشتن و پول بیشتر برای درآوردن!

تازه خیلی وقتا به دلایل متعددی، چیزها اونطور که شما فکر میکنید عمل نمیکنن و جواب نمیدن! این براحتی میتونه پیش بیاد. و بگم این مسائل در عمل اونقدر شاخ و برگ داره و پیچیده و گسترده است و از محیط به محیط ممکنه تفاوت بکنه که خیلی به سختی میشه تمام مواردش رو دونست و حضور ذهن داشت و پیشبینی و تحلیل کرد. گاهی حتی غیرممکنه!
مثلا این بحث ارسال آرگومانها به توابع با رفرنس یا مقدار رو من یک زمانی قدیمتر ها که زبان سی یاد میگرفتم و کار میکردم زیاد میخوندم و افرادی بارها مطرح میکردن. یک روز من گفتم خودم برم تست کنم ببینم این قضیه رو که ساده هست و سریع میشه تست کرد عملا ثابت کنم و اختلاف سرعتش رو هم محاسبه کنم. خلاصه من رفتم یه تستی زدم یک تابع نوشتم یک بار با روش ارجاعی و یک بار با روش مقدار، و هر دو رو توی یک حلقه با تعداد زیاد گذاشتم و time گرفتم ازشون، و میدونید، عملا هیچ برتری سرعتی در روش ارجاعی ندیدم، و حتی روش ارجاعی یک مقدار جزیی زمان بیشتری هم صرف میکرد! من هرچی فکر کردم شاید مشکلی در تست و کد من هست و احتمالات مختلف رو تست کردم و کد رو به شکلهای دیگری نوشتن دیدم نه تغییر خاصی حاصل نمیشه. اینجا فهمیدم اینکه میگن سعی نکنید هوشمند بازی دربیارید برای کامپایلر و بهینه سازیهای جزیی انجام بدید درسته. چون کامپایلرهای امروزی خودشون هوشمند هستن و خیلی الگوریتم های پیشرفته و بهینه سازیهای جزیی رو پشت پرده انجام میدن، و گاهی شما که خودتون میخواید این بهینه سازیهای جزیی رو با روشهای هوشمندانه انجام بدید عملا با روشها و پیشفرض های کامپایلر تداخل میکنه و هیچ سودی نداره حتی گاهی باعث ضرر و معکوس شدن نتایج مورد نظر هم میشه. و این مسئله فقط هم بخاطر هوشمندی کامپایلرها نیست، بلکه میتونه به دلایل دیگری هم باشه، که دونستن و تحلیل اینا نیاز به سواد و تحقیق و تست زیادی داره باید بدونید دقیقا پشت پرده چی میگذره با تمام جزییاتش حتی تا آخرین سطح که سخت افزار و CPU و RAM هست. بهرحال من در اون مورد نتیجه گرفتم که خب اصلا من چرا فکر کردم سرعت پاس کردن آدرس یک متغییر بیشتر از سرعت پاس کردن مقدارش هست، در حالیکه آدرس متغییر هم خودش توی یک متغییر پاس میشه و حجمش همونقدر یا نزدیک حجم مقدار نوع متغییر هست!! بعد اومدم و این بار بجای متغییرهای معمولی مثل int و char، از یک آرایه استفاده کردم، و خلاصه یکسری ایده ها و تغییرات و کدها و تست های دیگر، ولی باز اینم جواب نداد، و خلاصه آخرش کلافه شدم فهمیدم در عمل خیلی چیزها میتونه اونطور نباشه که پیشبینی شده. یعنی اصولا در مسائل پایه و بهینه سازیهای جزیی خیلی وقتا اینطوره. فهمیدم این مسائل درشت تر و عملیات با حجم و پیچیدگی بیشتر هستن که چون خود کامپایلر و محیط اجرا مستقیما باهاشون در سطح بالا و کلیت درگیر نیست و نمیتونه پیشبینی و مدیریت کاملی بکنه، برنامه نویس میتونه نسبت به اونا دید و کارایی و مدیریت و بهینه سازی خوبی داشته باشه و پیشبینی هایی که میکنه در این باب، احتمال صحت و موفقیت به مراتب بیشتری دارن. مگر اینکه ما اصولا داریم در سطح بسیار پایینی برنامه نویسی میکنیم، مثلا برنامه نویسی سیستمی مثلا هستهء سیستم عامل یا حتی کدنویسی در زبان اسمبلی، و مگر اینکه شرایط خاص باشه که اون بهینه سازیهای جزیی مهم باشن و ما داریم با این هدف اصلی کد مینویسیم. مثلا فکر کنید یک عملیات پایه که خیلی سریع اجرا میشه مثلا در 0.001 ثانیه، این نیاز به بهینه سازی نداره، ولی همین عملیات اگر توی یک حقله قرار داشته باشه که این حلقه در هر بار اجرای برنامه میخواد 10000 بار اجرا بشه، 0.001*10000 میشه 10 ثانیه، بنابراین اگر شما بتونید سرعت این عملیات پایه رو 50% افزایش بدید، 5 ثانیه از زمان اجرای کلی برنامه کم میشه، که این 5 ثانیه میتونه در عمل کاملا محسوس و مفید باشه.

[ADMIN]

(10-07-1394، 11:47 ق.ظ)Eshpilen نوشته: خب فرض کنید از اون 0.1 ثانیه زمان کل اجرا، 0.01 ثانیه اش متعلق به موارد عملیات پایه ای است که ذکر کردید (مثل افزایش مقدار متغییرها و count). من فکر کنم تخمین عاقلانه ای باشه!

خیر نیست، اگه عملاً تست کنید میبینید که در یک حلقه که فرضاً اطلاعات 1000 کاربر داخلشه، سرعت اجرا حدود 40 برابر میشه (بسته به سیستم ممکنه کمی تغییر کنه ولی چیزی از عمل فاجعه کم نمیکنه). دقت کنید که توی وب مثل برنامه دسکتاپ نیست که بگیم اختلافش برای یک کاربره و زیاد محسوس نیست. اگه ضربدر تعداد کاربران همزمان بشه، کلی بار اضافه روی سرور داره میگذاره و ممکنه با انواع و اقسام خطاها مثل Max connection reached توی MySQL یا Maximum allowed memory reached و Request timeout و... مواجه بشین.

تازه بهینه سازی فقط مختص سرعت نیست. برای مثال با فعالسازی gzip تونستیم توی یک سایت پر بازدید، روزانه 2 گیگابایت در ترافیک مصرفی صرفه جویی کنیم و قطعاً در جریان قیمت بالای ترافیک در ایران هستین!

[ADMIN]

لطفاً کدها رو توی تگ PHP بگذارین. لینک Syntax Highlighter های انجمن توی امضام هست.

[Eshpilen]

یه نگاه به این مثال بکنیم:

$var="something $var1 someotherthing $var2 somethingelse $var3"

$var='something '.$var1.' someotherthing '.$var2.' somethingelse '.$var3

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

حالا شما میگی چی؟ حرف حسابت چیه؟  
میگی نه حتما باید همیشه از حالت دوم استفاده کنیم چون بهینه تره؟
پس شکل اول رو واسه چی گذاشتن؟
اصلا شما چرا داری با PHP کد مینویسی؟ اگر هر اندازه بهینه سازی و افزایش سرعت به هر قیمتی صرف میکنه، خب چرا نمیری با زبانهایی مثل C که PHP هرگز پرفورمنسش به اونا نمیرسه کد بنویسی؟ اونوقت میتونی صدها برابر این بهینه سازیهای جزیی بهینه سازی کنی و افزایش سرعت بدست بیاری (تازه RAM کمتری هم مصرف میکنه  )
یک علت وجودی اصلی این زبانهای برنامه نویسی سطح بالا و چنین امکانات راه دستی، همینه که میزان جزییات و فرعیاتی رو که برنامه نویس باهاشون درگیر هست (چه از نظر فکری چه از نظر عملی)، به حداقل برسونن و کاهش بدن، تا برنامه نویس بتونه سریعتر و راحتتر و کدهای امن تر و خواناتری بنویسه، برنامه ها رو سریعتر درست کنه، برنامه های بیشتری بنویسه، برنامه هایی با باگهای کمتر.

[BITNEVIS]

با عرض سلام مجدد خدمت دوستان عزیز

 دو تا سایت هستن که به نظرم مقایسه های خوبی رو انجام دادن .

امیدوارم براتون مفید باشن. 



اولیش : http://www.phpbench.com/




دومیش : http://net-beta.net/ubench/

[ADMIN]

(11-07-1394، 01:17 ب.ظ)Eshpilen نوشته: حالا شما میگی چی؟ حرف حسابت چیه؟  
میگی نه حتما باید همیشه از حالت دوم استفاده کنیم چون بهینه تره؟

خیر کسی نگفته از حالت اول استفاده نکنید! دقت کنید که داریم میگیم اگه توی متن شما متغیری وجود نداره، توی کوتیشن جفت نگذارین.

[Eshpilen]

(12-07-1394، 12:23 ب.ظ)ADMIN نوشته: خیر کسی نگفته از حالت اول استفاده نکنید! دقت کنید که داریم میگیم اگه توی متن شما متغیری وجود نداره، توی کوتیشن جفت نگذارین.

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

اوه تازه یه چیزی! اگر بخوایم مثلا از ‎n توی رشته استفاده کنیم، این توی کوتیشن تکی کار نمیکنه اصلا!

کلا بنظر من برنامه نویس باید با برنامه نویسی راحت باشه به خودش بابت چیزهای جزیی فشار نیاره وقت و انرژی سر مسائل پیش پا افتاده تلف نکنه. هرچیزی بجاش وقتی ارزشش رو داشته باشه نیاز بشه باید بهش پرداخت. اینقدر مسائل و چیزهای گنده تر جالب تر مهمتر توی ذهن من هست اینقدر ذهنم درگیر صدها جزییات و روابط و پیچیدگی ها و الگوریتم های سطح بالاتر هست که دیگه وقت و انرژی و اولویت زیادی برام باقی نمیمونه  عاقلانه هم نیست بخوام صرف جزییات کم اهمیت بکنم. ضمنا از اون طرف مثلا یه امنیت اصولی رو میخوای رعایت کنی کلی کد اضافه مینویسی، مجبوری یعنی، از روشهای امن رمزنگاری  از الگوریتم های درست و حسابی استفاده میکنی، هزار برابر این جزییات مجبوری چاره ای نداری پردازش به برنامه تحمیل کنی! پس طبیعی هست که دیگه پرداختن به این جزییات در نظرت بیهوده باشه. مثل اینکه وقتی هزار تومن پول میدی بابت یه چیزی پونصد تومن بیشتر در نظرت میاد ولی وقتی یک میلیون تومن پول بابت چیزی داری میدی از 5 هزار تومن هم راحت میگذری بنظرت ارزش چک و چونه و فشار آوردن به خودت و دیگران رو نداره. البته بعضیا که ماشالا میلیاردی هم دارن و معامله میلیاردی میکنن از همون 5 هزار تومن هم نمیگذرن! ولی بنظر منکه این عاقلانه نیست. امروزه روز زمانی نیست که آدم توی فکر این چیزهای اینقدر جزیی باشه. گفتم بازم میگم که اصلا ارزش نداره حتی به این چیزا فکر کرد ذهن و تمرکز رو مشغول کرد. پرداختن به اینطور چیزهای جزیی موقعی هم که به علتی خاصی شرایط خاصی نیاز بشه مهم بشه آدم خودش معمولا پیشاپیش یا بعدا میفهمه و از بین 100 مورد حالا گیریم 1 مورد هم اینطور شد، اولا زیاد هم کار سخت و زمانبری نیست کشف علت و رفعش و خیلی ها زیادی این مسائل رو گنده میکنن، دوما بهرحال صرف نمیکنه بخاطر اون یک مورد بیای و در 99 مورد دیگه این همه دقت و صرف وقت و انرژی بکنی.
حالا اینا که تازه بهینه سازیهای خیلی جزییه. در بهینه سازیهایی به مراتب بزرگتر هم من همینطور عمل میکنم و اون توصیه ایی که بزرگان کردن هم اتفاقا راجع به خیلی از این بهینه سازیهای بزرگتر هم هست و نه فقط بهینه سازیهای در سطح چند فرم دستور و چند تابع مشابه. ولی به موقعش جایی که ببینم بهینه سازی واقعا درشته و احتمال اینکه در عمل تاثیرش دیده بشه زیاده، و انجامش هم هزینهء زیادی نداره زیاد سخت نیست وقت و انرژی اونقدری نمیبره که واضحا از سود احتمالیش بیشتر باشه، خب انجام میدم. در این زمینه ظاهرا بین علما هم اختلاف هست که بعضیا میگن اینطور بهینه سازیها رو باید از اول موقع طراحی و کدنویسی انجام داد و بعضیا میگن نه بازم نیاز نیست. البته درمورد برنامه هایی که برای اولین بار داره آدم مینویسه و بیشتر حالت آزمایش و نمونه اولیه دارن و به احتمال زیاد کدهای نهایی و نسل های عملیاتی برنامه تغییرات زیادی خواهند کرد یا اصلا بطور کامل بازنویسی میشن، حتی اون بهینه سازیهای درشت رو هم اکثرا نیاز نیست که انجام بدیم چون میدونی که این کدها در نهایت از بین خواهند رفت و معلوم نیست الگوریتم ها و کدها و بهینه سازیهای نهایی به چه شکلی باشن.