کاربر تایید شده
نویسنده آخرین فعالیت ٣ هفته پیش

@alive2212

پارس کلیکی از ١١ ماه پیش

تجربه

19500

  • ۴ هفته پیش نویسنده @alive2212 یک مقاله تازه به اسم استاندارد برنامه نویسی کنیم (PSR-2) نوشت.

    این مقاله در ادامه مقاله‌های قبلی در مورد درست برنامه نویسی کردن می‌باشد. در این مقاله می‌خواهیم در مورد PSR-2 بحث کنیم و این بحث در ادامه PSR-1 می‌باشد. (حتما اون رو هم یه نگاه بندازید)

    قبل از هر چیز باید بگم که این قوانین برای این نیست که کسی سود کنه، برای این هستش که کدها خوانا تر باشند و دیگران راحت تر از کد های شما سر در بیارن. (خلاصه چیزی تو جیب من یا اون سایته نمیره ;) ولی مطمئنن خیلی چیزها تو جیب شما میره)

    لیست استاندارد ها:

    • کدهای این استاندارد باید استاندارد قبلی PSR-1 رو رعایت کرده باشن(مثلا ‍شتری نوشتن یا Study Case‍ و نحوه نوشتن توابع و constant ها و ...

    • کدهای داخل یک فاکنشن باید با چهار اسپیس جلو تر بیان و تب زده نشود. (اگر از Php Storm استفاده میکنید نگران نباشید)

    • حتما نباید کد هاتون کمتر از ۱۲۰ کاراکتر باشه ولی سعی کنید این کار رو انجام بدید و به طور معمول سعی کنید طول یه خط کمتر از ۸۰ کاراکتر باشه. (اگه از Php Storm استفاده می‌کنید با زدن شورت کی روبرو خودش این کار رو انجام میده CTRL+ALT+L مثلا من این جا چند تا مثال میزنم که متوجه بشید. فرض کنید تابعی داریم مثل ذیل

      /**
       * @param Request $request
       * @param array $params
       * @param String $countryKey
       * @param String $provinceKey
       * @param String $cityKey
       * @param Closure $closure
       * @return mixed
       */
      public function testFunc(Request $request, Array $params, String $countryKey, String $provinceKey, String $cityKey, Closure $closure)
      {
          $result = [$params[$countryKey], $params[$provinceKey], $params[$cityKey]];
          $request->attributes["location_params"] = $result;
          return $closure($request);
      }

      فارغ از اینکه ورودی های این تابع زیاد هستند و باید طولش کمتر از این حرف ها باشه باید درست نگارش بشه برای نگارش صحیح اون باید بعد از پرانتز فانکشن اینتر بزنیم و اونها رو به ردیف کنیم یعنی مثل ذیل

      /**
       * @param Request $request
       * @param array $params
       * @param String $countryKey
       * @param String $provinceKey
       * @param String $cityKey
       * @param Closure $closure
       * @return mixed
       */
      public function testFunc(
          Request $request, 
          Array $params, 
          String $countryKey, 
          String $provinceKey, 
          String $cityKey, 
          Closure $closure)
      {
          $result = [$params[$countryKey], $params[$provinceKey], $params[$cityKey]];
          $request->attributes["location_params"] = $result;
          return $closure($request);
      }

      اینطوری وقتی کسی کد ما رو میخونه نمیخواد هی چپ و راست کنه اسکرول رو

    • قبل و بعد از namespace حتما باید یک خط فاصله وجود داشته باشد.

    • براکت بعد از فانکشن باید در یک خطر مجزا و همینطور در انها باید در یک خط مجزا باشید.

        /**
         * Display a listing of the resource.
         *
         * @param Request $request
         * @return Response
         */
        public function index(Request $request)
        {
            .
            .
            .
        }
    • Visibility برای تمام متغیر ها و تمام متد ها بایستی مشخص شود. اول از همه باید بگم که Visibility یعنی چی :) Visibility به عبارتی میگویند که پشت متغیر ها و یا متد ها قرار می‌دهیم تا سطح دسترسی به انها مشخص شود که آنها عبارتند از Public,Private,Protected که اگر یک متغیر محلی باشد یعنی اینکه از بیرون به آن دسترسی ای نیست اگر عمومی باشد از بیرون می‌توان به آن دسترسی داشت و تغییر داد و اگر حفاظت شده باشد می‌توان از بیرون به آن دسترسی داشت ولی نمی‌توان آن را تغییر داد. حالا ما اگر بخواهیم تابعی و یا متغیری رو تعریف میکنیم حتما باید قبلش مشخص کنیم که میزان دسترسی به اون چقدر هستش. در ذیل چند تا مثال آورده شده که بیشتر با این موضوع اشنا بشید.

      public $public = 'Public';
      protected $protected = 'Protected';
      private $private = 'Private';
      
      /**
       * Show the form for creating a new resource.
       *
       * @return Response
       */
      public function create()
      {
          //
      }

      چیزی که باید به اون هم پرداخت اینه که abstract و final باید قبل از visibility بیان و واژه static باید بعد از visibility بیاد. از اونجایی که میدونم زیاد استفاده نمیکنید آخر گفتم ;)

    ولی دوستان خواهش من اینه که به خودتون و کدی که میزنید احترام بگذارید و بعد از اون به فکر همکارانتون و یا انسانهایی که بعدا میان و دسته گل شما رو (ببخشید کد شما رو) میخونن، باشید.

    • دستورات کنترلی مثل if یا while باید با قسمت شرط یک فاصله داشته باشد. متد ها و فراخانی فانکشن ها بدون فاصله باید باشد.
      if (true) {
          ...
      }
    • برای دستورات کنترلی براکت شروع در همان خط و براکت پایان نیز بعد از متن آن در یک خط دیگر بایستی باشد. (مشابه مثال بالا)
    • داخل پرانتز دستورات کنترلی (مثل if بالا) هیچ فاصله ای قبل و بعد از پرانتز نباید باشد. (مشابه مثال بالا)

    در انتها باید تشکر کنم از دوستانی که زحمت می‌کشند و کدهای خوانا می‌نویسند و ازتون خواهش کنم که از PHP DOC در تمامی متد ها استفاده کنید.

  • ١١ ماه پیش نویسنده @alive2212 یک مقاله تازه به اسم استاندارد برنامه نویسی کنیم (PSR-1) نوشت.

    این مقاله در ادامه مقاله قبلی با عنوان استاندارد برنامه نویسی کنیم (مقدمه) می‌باشد. در این مقاله میخواهیم نگاه موشکافانه تری به PSR-1 داشته باشیم. خیلی خوب تا اینجا مساله ای مطرح شد که چگونه برنامه‌ای بنویسیم که دیگران هم بتونن اون رو به راحتی بخونن و در کنار هم تیمی های ما ماژول ها، کلاس‌ها و متد های ما کار کنند. پس از بررسی کارهایی که در دنیا انجام شده متوجه شدیم که این مساله خیلی از برنامه نویسان بوده در همین رابطه استانداردهایی در دنیا درست شده است که برنامه نویسان مختلف میتونن با خوندن اون راحت‌تر و بهتر برنامه نویسی کنند. برای زبان PHP این استاندارد ها با نام PSR مطرح شده‌اند که در مقاله قبلی به معرفی آن‌ها پرداختیم و در اینجا میخواهیم وارد جزئیات بیشتر آن‌ها شویم.

    PSR

    PSR-1

    این استاندارد شامل چندین بخش مختلف است که در ادامه به تفصیل هر کدام را توضیح خواهیم داد. فایل‌ها مجازند تنها تگ “<?php” و “<?=” رو داشته باشند. به نظر بنده بزرگترین ویژگی PHP این هستش که برنامه نویس در اون میتواند هر ملقی بزند بدون اینکه با خطایی برخورد کنند. مثلاً می‌شود ’1000’ رو به اون داد و با 1000 به صورت Integer مقایسه کرد. در صورتی که اگر این کار را بخواهید با JAVA بکنید میبینید که یک کافی با چوب از درون مانیتور در‌آمد و دنبال شما افتاد. یا اینکه میتونید به صورت استرینگ یک تابع خود را صدا بزنید. به مثال زیر دقت بفرمایید:

    class MyClass
    {
        public function myFunc()
        {
            return null;
        } 
    }

    حالا فرض کنید متد بالا را میخواهیم صدا بزنید. خب جند روش وجود دارد. که من تک تک اونها رو مینوسم. روش اول

    $object = new MyClass();
    $object->myFunc();

    روش دوم (فشرده)

    (new MyClass())->myFunc();

    روش سوم

    $myFuncName = ‘myFunc’;
    $object = new MyClass();
    $object->{$myFuncName}();

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

    همچنین میتونیم در PHP با استفاده از تگ <?= که در بالا به اون اشاره شد متن مورد نظرمون رو echo کنیم. خب این قابلیت به ما اجازه میده که وسط کدهامون یه تیکه از صفحه نهایی که به کاربر نشون داده میشه رو بسازیم.

    خب حالا همه این قابلیت‌ها رو فرض کنید که بخواهیم توی یک فایل بگونجونیم. چی میشه … به‌به عالی میشه. خب برای اینکه این اتفاق نیوفته اومدن و چند تا کار رو با هم انجام دادن. یکی اینکه اول از همه گفتن یا کد php یا خروجی برای UI. برای کد نویسی باید از UTF-8 without BOM استفاده شود. همون طور که خیلی از ما ها میدونم فایلهای استرینگ با فرمت های مختلفی هستند که در اون همه زبان‌ها گنجونده شده‌اند ولی فرمت های زیادی برای اونها وجود داره. مثلاً اون رو باید شاید وقتی در گذشته وارد یک سایت فارسی میشدید و میدیدید که همه چیز به زبان انگولاساکسون نوشته شده. در اون زمان بود که اون یک چپ کلیک و انتخاب encoding و UTF-8 اون به زبان فارسی برمیگشت، دیده باشید. برای اینکه هر کسی فرمت خودش رو نداشته باشه قرار شد که همه از فرمت فوق استفاده کنند. این فرمت به ما کمک میکنه که بتونیم توی فایل هامون حتی فارسی هم بنویسیم اما قطعاً و حتماً نباید فارسی رو توی کد ها بنویسیم حتی به عنوان کامنت.

    فایل‌ها یا باید برای تعریف سیمبول ها(کلاس ها و متدها و ...) باشند یا برای side-effect ها (مثلاً فایل‌های تنظیمات مثل setting) در اینجا به یکی از بزرگترین نکات این استاندارد اشاره شده.
    لطفاً کلاس‌ها جدا ، تنظیمات کلاس جدا این یعنی اینکه شروع کنیم فایلهای زیاد بسازیم و نترسیم از فایلهای زیاد ساختن بعد از این مرحله یاد گرفتیم که کلاً هر فایل برای یک کلاس باشه نه اینکه ۱۰ تا کلاس توی یک فایل باشد.

    نام محیط (namespace)فایل‌ها باید از یکی از استاندارد های PSR-0 (منسوخ شده) یا PSR-4 تبعیت کنند. برای اینکه به صورت اوتوماتیک در فایل php لود شوند. لازم به ذکره که namespace همون چیزی هستش که در بالای فایلها مینویستم که نشون بدیم این فایل مربوط به چه کسی و چه پکیجی هستش و در چ آدرسی قرار گرفته تا سیستم کامپوزر متوجه بشه و اونو اتوماتیک در پروژه require کنه. تمامی دوستانی که از فریم ورک استفاده میکنند میدونند که در پروژه ها پکیجی وجود داره به نام composer، این پکیج، کارش آینه که پروژه رو در با استاندار PSR-4 کنترل کنه و کلاس‌ها به صورت اتوماتیک در اون لود بشوند. برای اینکه این موضوع رو بهتر متوجه بشیم به مثال زیر دقت بفرمایید. فرض کنید بخواهیم یه فایل به نام index.php و یک فایل دیگر که در اون یک کلاس به نام MyClass.php که در بالا آورده شد، رو داشته باشیم. و نمای اونها در فولدر ما به شکل زیر باشه

    app/
    index.php
    resource/
    MyClass.php

    در اینجا میخواهیم متد myFunc رو در index.php صدا بزنیم.

    <?php
    require_once('../resource/MyClass.php');
    $object = new MyClass();
    $object->myFunc();
    ?>

    حالا فرض کنید پروژه شما از ۲۰۰ تا کلاس داشته باشه. باید ۲۰۰ بار require_once کرد. برای اینکه این اتفاق نیوفته پکیجی به نام کامپوزر طراحی شده کد ها از این شکل خارج شده. و تنها کافی هستش که آن‌ها را با استفاده از namespace که در فایل آن‌ها نویشته میشود، use کنیم. چون این مبحث مربوط به PSR-4 است اجازه بدید که در آنجا توضیحات بیشتر بدم.

    نام کلاس‌ها باید به صورت StudlyCaps نوشته بشوند. مثلاً اینجوری TestClass تمامی constants های یک کلاس باید به صورت حروف بزرگ و با خط فاصله underscore جدا شوند. مثلاً DEFAULT_VALUE همگی متد ها باید به صورت شتری :smile: (camelCase) نوشته بشوند. مثلاً testFunction خلاصه همگی موارد فوق رو در یک مثال توضیح میدیم.

    <?php
    namespace Resource;
    class MyClass
    {
        /**
        * This is version of this class
        */
        const VERSION = '1.0';
    
        /**
        * This is date of approved of this 
        */
        const DATE_APPROVED = '2018-08-04';
    
        /**
        * @param int $inputValue
        * @return int
        */
           public function myFunc(int $inputValue)
           {
                  if($inputValue>0){
                         return $inputValue;
                  }
                  return 0;
           }
    }

    همون طور که دیده می‌شود نام کلاس به صورت StudyCaps نوشته شده است. این یعنی اینکه حرف اول کلمات بزرگ شده و کلمات بدون فاصله پشت سر هم نوشته می‌شوند. نام متد یا فانکشن ها، نام متغیر ها به صورت camelCase نوشته شده اند. این یعنی اینکه دقیقاً مثل روش قبلی نوشته می‌شوند با این تفاوت که حرف اول کلمه اول باید کوچک باشد. و همچین موارد ثابت مانند constants ها باید به صورت under_score و بزرگ نوشته بشوند مانند:

    const VERSION = '1.0';
    const DATE_APPROVED = '2018-08-04';

    نکته ای که در اینجا میخوام بگم اینه که همون طور که میبینید قبل از متد و متغییرها یه چیزی وجود داره که با /** شروع شده و با * ادامه یافته و با */ تموم شده. اینها برای داکیومنتیش برنامه ای که مینویسیم هستن که در اینده بهتون یک پکیج رو معرفی میکنم که به صورت اوتوماتیک از تمام کدهای شما داکیومنت میسازد. در مقاله بعدی به استاندارد PSR-2 میپردازیم که به نحوه پیاده‌سازی مربوط هستش.

  • ١١ ماه پیش نویسنده @alive2212 یک مقاله تازه به اسم استاندارد برنامه نویسی کنیم (مقدمه) نوشت.

    توی این مقاله میخوام درباره اولین تجربه خودم در حوزه برنامه نویسی php که روی یک پروژه بزرگ کار میکردم باهاتون صحبت کنم.

    اولین روزهایی که ما دوستان برنامه نویس با هم برنامه نویسی رو شروع کردیم خیلی مهم نبود که استاندارد های برنامه نویسی رو رعایت کنیم اما بعد از گذشت ۶ ماه این موضوع کم کم جدی شد. طوری که برای تغییر دادن یک بخش کوچک که به نظر میرسید کار یک روز باشه ما مجبور بودیم که چند روز و بعضی وقت‌ها چند هفته وقت بگذاریم تا بتونیم اون کار رو انجام بدیم. لذا برنامه‌ای جدی گذاشتیم تا در اولین فرصت کد های خودمون رو ریفکتور کنیم تا هم همکارانمون بتونن متوجه کدهایی که ما زدن بشن و برعکس و هم اینکه با تغییر دادن یک بخش، بخش دیگری کرش نکنه.

    PSR

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

    خب اولین چیزی که متوجه شدیم این بود که باید اول کد زدنمون رو درست کنیم. این یعنی اینکه اسم کلاس‌ها، سیمبول ها، پراپرتی ها، توابع و … رو باید درست بنویسیم. پس گشتیم و گشیتم تا به سایت https://www.php-fig.org برخورد کردیم.

    در این سایت در بخش PSR استاندارد هایی رو که مورد تأیید قرار گرفته شده رو برای عموم گذاشتن تا همه بتونن از تجربیات افراد متخصص استفاده کنن و یک‌دست کد بزنن.

    وقتی وارد تب PSRs بشید میبینید که تاکنون ۱۱ استاندارد Accept شده و همچنین مقاله های بیشتری در حال بررسی هستند تا Accept شوند و جزء استاندارد ها قرار بگیرند.همچنین مواردی هستند که رها شده‌اند ABANDONED و همچنین موردی هست که دیگه استفاده نمیشه DEPRECATED چون که جای اون یه پکیج جدید وجود داره.

    در ادامه موارد ۱ تا ۷ ام رو به طور اختصار توضیح میدم.(البته مواردی که Accept هستند;

    1. Basic Coding Standard : PSR-1
    2. Coding Style Guide : PSR-2
    3. Logger Interface : PSR-3
    4. Improved Autoloading : PSR-4
    5. Caching Interface : PSR-6
    6. HTTP Message Interfaces : PSR-7

    استاندارد PSR-1

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

    • فایل‌ها مجازند تنها تگ <?php و <?= رو داشته باشند.
    • برای کد نویسی باید از UTF-8 without BOM استفاده شود.
    • فایل‌ها یا باید برای تعریف سیمبول ها(کلاس ها و متدها و ...) باشند یا برای side-effect ها (مثلاً فایل‌های تنظیمات مثل setting
    • نام محیط namespace فایل‌ها باید از یکی از استاندارد های PSR-0 (منسوخ شده) یا PSR-4 تبعیت کنند. برای اینکه به صورت اوتوماتیک در فایل php لود شوند. لازم به ذکره که namespace همون چیزی هستش که در بالای فایلها مینویستم که نشون بدیم این فایل مربوط به چه کسی و چه پکیجی هستش و در چ آدرسی قرار گرفته تا سیستم کامپوزر متوجه بشه و اونو اتوماتیک در پروژه require کنه.
    • نام کلاس‌ها باید به صورت StudlyCaps نوشته بشوند. مثلاً اینجوری TestClass.
    • تمامی constants های یک کلاس باید به صورت حروف بزرگ و با خط فاصله underscore جدا شوند. مثلاً DEFAULT_VALUE
    • همگی متد ها باید به صورت شتری camelCase نوشته بشوند. مثلاً testFunction
    • نکته مهم اینه که برای متغیر ها هیچ خط مشی ای مشخص نشده لذا هر طور که خواستید بنویسید که البته من همیشه به صورت camelCase مینویسم ولی شما میتونید از روش خودتون استفاده کنید. ولی نکته بسیار بسیار مهم آینه که همه جا از یک روش استفاده کنید نه اینکه یه جا camelCase و یه جای دیگه under_score و یه جای دیگه StudyCap بنویسید.

    استاندارد PSR-2

    این استاندارد در ادامه استاندارد قبلی است. و مواردی که در این استاندارد رعایت شود به صورت تیتر وار به قرار ذیل است:

    • باید استاندارد PSR-1 رعایت شود.
    • برای indentation باید ۴ اسپس زده شود. Indextion همان فاصله هایی است که کدهای زیر یک تابع یا حلقه نسبت به خط بالاسری دارد.
    • هیچ محدودیت hard limit ای برای طول خط ها وجود ندارد. اما soft limit برای هر خط ۱۲۰ کاراکتر هستش. یعنی طول خطوط اگر بیشتر از ۱۲۰ تا شد باید اینتر بزنید و در خط پایینی ادامش بدید.
    • تنها یک خط خالی بعد از namespace ویک خط خالی بعد از use ها باید باشد.
    • curly bracket بعد از کلاس و متد باید در یک خط باشد و در پایان هم همینطور.
    • برای تمام متد ها و پراپرتی ها باید Visibility مشخص شود. یعنی مثلاً مشخص شود که public هستش یا private یا برای پراپرتی ها (متغیر های داخل کلاس که عمومی هستن) protected, abstract و …
    • کنترل استراکچر ها یا همان If و switch case و …
    • باید بین شرط ها بعد از ویرگول یک اسپس زده شود.
    • پرانتز شرط ها بدون فاصله به آن‌ها میچسبد. curly bracket بازشونده در همان خط و curly bracket بسته شونده یک خط پایین‌تر از متن و در یک خط نوشته شود.
    • متنی که در هر شرط نوشته می‌شود باید بدون هیچ فاصله‌ای نسبت به خط بالایی نوشته شود.

    چون در این بخش صرفاً میخوام همه چیز رو معرفی کنم در اینجا فقط توضیح مختصری داده شده که در مقاله‌های بعدی کاملاً با نمونه کد تشریح خواهم کرد.

    استاندارد PSR-3

    نکته‌ای که باید اینجا بگم اینه که Interface در عنوان هر استاندارد به معنی مجموعه کدی در قالب یک پکیج است که به پروژه اضافه میشه و اون رو یکدست میکنه. به صورت خلاصه میتوان گفت که برای مرتب کردن نحوه لاگ کردن هستش که در قالب ۸ متد:

    1. debug
    2. info
    3. notice
    4. warning
    5. error
    6. critical
    7. alert
    8. emergency

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

    استاندارد PSR-4

    همون چیزی هستش که به خاطر اون در پروژه هامون از Composer استفاده میکنیم. اگه بخواهیم بدون استفاده از composer یک پروژه را درست کنیم در فایل index.php باید چند صد بار از require_once استفاده کنیم. اما با این روش فایل‌ها به صورت اوتوماتیک در پروژه لود می‌شوند و فقط کافی است که قبل از کلاسی که میخواهیم از آن استفاده کنیم اونها رو با namespace مربوطه use کنیم. مثال کامل و دقیق تر این استاندارد رو در یک مقاله کاملاً جدا خواهم نوشت تا دوستان به عمق composer پی ببرند چون خودم هم مدت‌ها نمیدونستم دقیقاً کار کامپوزر چی هستش.

    استاندارد PSR-6

    همون طور که از عنوان این استاندار پیداست این پیکیجی برای یک‌ دست شدن دیتا ها در سیستم Cache میباشد. در این پکیج برنامه نویسان میتوانند به صورت یکپارچه از سامانه Cache استفاده کنند که در آن با استفاده از کلید و زمان انقضا متغیر مورد نظر خودشون بر روی هارد دیسک و یا رم ذخیره کنند.

    استاندارد PSR-7

    در این پکیج نیز استانداردی برای بیان کردن پیغام های HTTP معرفی شد. تا قبل از این استاندارد با استفاده از متغیر هایی نظیر _SERVER و یا _GET پارامتر های ورودی ریکوئست را دریافت کرد. این پکیج شامل دو اینترفیس RequestInterface و ResponseInterface که به ترتیب برای دریافت پارامتر ها و برای ارسال پارامتر ها با استفاده از پروتکل HTTP Message می‌باشد.