نوشته‌شده در

بدون نظر ، تا به حال! نظرات در کد از گذشته است | توسط Rinat Ussenov | نوامبر ، 2020

Rinat Ussenov
Joan Crawford در Mommie Dearest، 1981

نظرات در مورد کد مربوط به گذشته است

آیا هر بار که با روشی یا عملکردی روبرو می شویم ، کمی کوچک نمی شویم یا کلاسي که بالاي آن نظر طولاني و آزاد داشته باشد؟ خوب ، دلیل آن این است که بیشتر آن نظرات طولانی مدت عبارتند از: ) ؛

  • یک نسخه دقیق از کد زیر آن ، فقط با عبارت "طبیعی تر" (وقت گذران وقت) نوشته شده است ؛

    • ] با کد خود ارتباط برقرار کنید (نه نظرات) ، با بررسی کد ارتباط برقرار کنید ، منابع داخلی (فردی) را که برای نظر اختصاص داده اید سرمایه گذاری کنید تا خوانایی کد را بهبود بخشد. این سرمایه گذاری در آینده نتیجه خوبی خواهد داشت.

    https://stackoverflow.com/questions/184618/ بهترین-نظر-کد-منبع-کدام-هرگز-با-برخورد نکرده اید-(19659026]) نظرات خنده دار اما مرتبط نیز قابل قبول است. توسعه نرم افزار لازم نیست خشک و کسل کننده باشد. بالاخره همه ما انسان هستیم.

    نوشته‌شده در

    آیا نوع اجبار در جاوا اسکریپت یک چیز خوب است؟ – یادداشت های مهندس

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

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

    بیایید نگاهی به کار نمونه، رویکرد سنتی و رویکرد با نوع اجبار

    وظیفه

    ما باید تغییر دینامیک عرض عناصر DOM در یک ظرف بسته به تعداد عناصر وجود دارد، تا اطمینان حاصل شود که آنها تمام عرض کانتینر را جمع می کنند.

    حداکثر عناصر 3. اگر ما فقط 2 عنصر داشته باشیم، پس هر یک از آن ها نیاز به عرض 50٪، اگر ما 3 عنصر داشته باشیم، عرض هر عنصر باید 33٪ باشد. البته عنصر تک باید 100٪ عرض را داشته باشد.

    ما می دانیم که عنصر توسط پرچم مربوط Boolean وجود دارد.

    راه حل CSS زیبا ترین خواهد بود، درست است؟ اما به عنوان مثال، اجازه می دهد تا تصور کنید CSS در سال 1996 گیر کرده است.

    رویکرد سنتی

    این در مورد زشت است!

    آنجا شما بروید: 

     بولی  FIRST_ELEMENT؛ 
     بولین  SECOND_ELEMENT؛ 
     بولی  THIRD_ELEMENT؛ 
     رشته  عرض؛ 
     // اگر تمام عناصر موجود باشد 
     اگر  (FIRST_ELEMENT && SECOND_ELEMENT && THIRD_ELEMENT) {
     width = '33٪ '؛ 
    } 
     // اگر 2 عنصر موجود باشد 
     اگر  (FIRST_ELEMENT && SECOND_ELEMENT &&! THIRD_ELEMENT) {
     width = '50٪'؛ 
    } 
     
     اگر  (FIRST_ELEMENT &&! SECOND_ELEMENT && THIRD_ELEMENT) {
     width = '50٪؛ 
    } 
     
     if  (! FIRST_ELEMENT && SECOND_ELEMENT && THIRD_ELEMENT) {
     width = '50٪ '؛ 
    } 
     // اگر تنها یک عنصر وجود داشته باشد 
     اگر  (! FIRST_ELEMENT &&! SECOND_ELEMENT && THIRD_ELEMENT) {
     width = '100٪'؛ 
    } 
     
     اگر  (FIRST_ELEMENT &&! SECOND_ELEMENT &&! THIRD_ELEMENT) {
     width = '100٪'؛ 
    } 
     
     if  (! FIRST_ELEMENT && SECOND_ELEMENT &&! THIRD_ELEMENT) {
     width = '100٪'؛ 
    }

    این کد کار را انجام می دهد. اما آه پسر .. چیزی که درون من افتاد وقتی وارد آن شدم.

    آیا می توانیم با رویکرد سنتی بهتر عمل کنیم؟ من هم اینچنین فکر میکنم. به طور پیش فرض و خلاص شدن از آخرین 3 شرایط: 

     رشته  width = '100٪'؛ 
     // اگر همه عناصر حضور داشته باشند 
     اگر  (FIRST_ELEMENT && SECOND_ELEMENT && THIRD_ELEMENT) {
     width = '33٪ '؛ 
    } 
     // اگر 2 عنصر موجود باشد 
     if  (FIRST_ELEMENT && SECOND_ELEMENT &&! THIRD_ELEMENT {19459019] width = '50٪ '؛ 
    } 
     
     if  (FIRST_ELEMENT &&! SECOND_ELEMENT && THIRD_ELEMENT) {
     width = '50٪؛ 
     
     
     اگر  (! FIRST_ELEMENT && SECOND_ELEMENT && THIRD_ELEMENT) {
     width = '50٪ '؛ 
    }

    این کد هنوز بوی خاصی دارد. ما می توانیم با «بهینه سازی» بیشتر، XOR بیتی را معرفی کنیم، منطق بیشتری اضافه کنیم، مقدار شرایط را کاهش دهیم. سوال این است: آیا قابل خواندن است؟ یا این یکی از آن چیزهایی است که شما را مجبور به نظر دادن برای نسل های آینده می کند تا بدانند که در واقع چه اتفاقی می افتد؟ هنوز هم به نظر می رسد بد است

    اکنون اجازه می دهد یکی از ابزارهای موجود در جعبه ابزار ما را ببینید و ببینید که آیا آن را می تواند مفید باشد در اینجا: نوع کوک.

    Type Coercion

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

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

    تبدیل غلط به 0؛

    تبدیل واقعی به 1؛ [19659041] این چگونگی آن در این مثال خاص مفید است: 

     رشته  width = '100٪'؛ 
     اینتر  TOTAL_ELEMENTS = FIRST_ELEMENT + SECOND_ELEMENT + THIRD_ELEMENT؛ 
     if  TOTAL_ELEMENTS == 2) {
     width = '50٪ '؛ 
    } 
     
     if  (TOTAL_ELEMENTS == 3) {
     width = '33٪'؛ 
     }

    قابلیت خوانایی به طور قابل توجهی بهبود یافته است

    این روزها زمانی که قابلیت خواندن و درک سریع از کد نوشته شده توسط OT آن ها یکی از مهمترین و مهمترین مواد تشکیل دهنده عملکرد تیم است، ما باید از هر ترفندی که ما باید آستین خود را برآورده کنیم استفاده کنیم. نوعی اجبار به وضوح یکی از آن است.

    بر خلاف قانون Betteridge از سرفصلها، این را نمی توان با کلمه "نه" پاسخ داد.