MasterScripter

PHP – לכתוב את זה נכון

כמו בכל שפה שהיא, ישנם חוקי תחביר, אבל כל אחד מפתח עם הזמן סגנון כתיבה משלו.
וכמו שאני שואף לכתוב עברית תקינה ככל האפשר, כך גם כאשר אני כותב בשפת תכנות, אני שואף לכתוב בצורה הנכונה ביותר. ואני לא היחיד:
PHP-FIG (ראשי תיבות: PHP Framework Interop Group) הינו יוזמה שמטרתה לפתח סטנדרט כתיבה אחיד בין סביבות העבודה, כדי לאפשר להן לעבוד אחת מול השנייה , ותנאי הכניסה למיזם (למעט יוצאים מן הכלל) הוא קשר רלוונטי לפיתוח סביבת עבודה נפוצה.
בין היתר ניתן למצוא שם נציגים של סביבות העבודה ZEND Framework, AWS, Joomla, Prestashop ועוד רבים וטובים.

עם יציאת PHP 7, זו הזדמנות מעולה לעשות בדק בית.
הפוסט הבא מתבסס על סגנון הכתיבה שלי, שאימצתי במהלך השנים ממקורות שונים, העיקריים שבהם הם PHP-FIG ו – PHP PEAR – מאגר מחלקות שמיישמות פונקציונליות נפוצה.

ולמרות שהמטרה שלהם היא לא להגיד לנו איך לכתוב ולסגנן קוד, בהחלט קיימת שם התייחסות לנושא ואפשר בהחלט לאמץ את סגנון הכתיבה.
לפני שנתחיל אדגיש שקטונתי מלקבוע מהי הדרך הנכונה לכתוב PHP (או כל שפה אחרת), וכל מה שרשום במאמר הוא בגדר המלצה ולפי ניסיוני בלבד.

אם אתה מפתח בקוד פתוח, היצמדות לכללי סגנון כתיבה הינם בגדר חובה, אך אם את מפתחת בקוד סגור – יש מקום ואף רצוי לפתח סגנון כתיבה שיביא אותך (ואת הצוות שלך) לפרודקטיביות מלאה.

בין אם תאמצו את סגנון הכתיבה המוצע ובין אם לא, הדבר החשוב ביותר הוא להיות מודעים לכך שסגנון כתיבה אחיד ככל הניתן יוצר סדר ומשפר פרודקטיביות.

 

פתיחת קוד PHP

כל סקריפט ייפתח בדרך הבאה:

כל יתר הקיצורים עשויים לגרום בעיות בעקבות הגדרות שרת כאלה ואחרות,
אם כי ברוב המקרים לא תיווצר בעיה. אבל למה לקחת את הסיכון?

סגירת קוד PHP

סגירת סקריפט איננה חובה מבחינת מעבד הקוד של השפה.
מעבר לכך שזה לא חובה – זה לא מומלץ, מכיוון שיכולות להיווצר בעיות פלט בעקבות תווים ריקים לאחר הסגירה, לדוגמה: סקריפט ששולח Headers (שכידוע, נדרשים להישלח לפני הפלט).
כמובן שזה תקף רק כשמדובר בקבצים שמכילים PHP בלבד.

קידוד תווים

כל קובץ PHP צריך להישמר בקידוד תווים UTF-8 WITHOUT BOM.
ההמלצה הזו תקפה במיוחד (אך לא רק) למתכנתי ה – PHP בארץ שמשתמשים בשפות שמיות. ימנע לכם הרבה כאב ראש בניסיון להבין למה יוצא ג'יבריש.

הזחה

מי מכם שישים לב לפרטים הקטנים, יגלה שבפוסט השתמשתי בהזחה של 4 רווחים.
כל מתכנת מכיר את הבלאגן שנוצר במעבר מעורך לעורך – כשההזחות לא אחידות.

הפתרון לכך דיי פשוט – השתמשו בהזחה של ארבעה רווחים. ברוב העורכים ניתן להגדיר את כמות הרווחים בכל הזחה.

שמות ארוכים ואורך שורה

כאשר שמות משתנים/פרמטרים/פונקציות ארוכים, מומלץ להפרידם באמצעות שורה חדשה, כדי לשמור על קריאות.
אורך שורה מומלץ הוא בין 75-85 תווים. עם זאת, לספור זה לא באמת אפשרי ולכן אמת המידה צריכה להיות של המפתח:
שורה צריכה לאפשר למתכנת "לעבד" את משמעות השורה במהירות מיטבית.

הנה דוגמה לדרך בה נפריד באמצעות שורה חדשה:

שמות

באופן כללי, חשוב להקפיד על מתן שמות רלוונטיים ובעלי משמעות ככל הניתן.

שמות מחלקה

שם מחלקה יתחיל תמיד באות גדולה ויתאר את העצם שהמחלקה בונה.
לדוגמה:

כאשר שם המחלקה מכיל יותר משתי מילים, נפריד באמצעות קו תחתון, כאשר כל מילה מתחילה באות גדולה:

 

שמות קבועים (contstants)

שמות של קבועים ייכתבו באותיות גדולות בלבד.

שמות משתנים

בכל הנוגע לשמות משתנים, אני לא חושב שיש דרך אחת 'נכונה יותר',
כל עוד שומרים על עקביות. הפרדת מילים באמצעות קו תחתון או באמצעות אות גדולה,
אותיות קטנות או גדולות – הכל הולך – כל עוד שומרים על פורמט זהה לאורך כל הפרוייקט.

בקרי שליטה (Control Structures)

if-elseif-else

אתה לא מתכנת עד ששרפת שעתיים (לכל הפחות) בניסיון לאתר שגיאה, ולבסוף מצאת סוגריים שלא סגרת.
פקודות if/else עשויות להיות מורכבות לעיתים, ולכן הסדר והאחידות בהן הוא קריטי.

המקרה הבא, שהוא ה"מסובך" ביותר מבחינת if/else, מדגים איך לסדר את פקודות התנאי ליצירת קריאות אופטימלית:

ב – PEAR ממליצים אפילו לפרק פקודות if מורכבות למס' שורות.

Switch

בפקודת Switch מומלץ לשמור על היררכיית מקרים, ע"י שימוש בהזחה:

שימו לב, שבמקרה בו נחזיר ערך במהלך ריצת ה – switch, אין צורך ב – break:

זאת מכיוון שהפקודה return מפסיקה את הריצה של הפונקציה, ולכן אין חשש מהמשך הריצה של פקודת ה – switch.

לולאות (while, do..while, for, foreach)

do..while

while

for

foreach

מחלקות, תכונות ופונקציות

extends,  implements

הרחבה (extends) ויישום (implements) יוכרזו באותה שורה עם הכרזת שם המחלקה.

במקרה של יישום ממשקים מרובים, ניתן לרשום את שמות הממשקים בשורה חדשה, עם הזחה אחת:

תכונות מחלקה

אולי הקטגוריה בה קיימות הכי הרבה דרכי כתיבה, בעיקר בגלל הגמישות של PHP שמאפשרת את ריבוי הדרכים במקרים רבים.

מבנה הכרזה על תכונת מחלקה יכלול תמיד את נגישות התכונה ושם התכונה בלבד.

  • אין להשתמש בפקודה var
  • יש להכריז על תכונה בשורה חדשה
  • שם תכונה לא יתחיל בקו תחתון כדי לסמן תכונה שהיא private או protected

בנוסף, יישום ערך של תכונת מחלקה יבוצע בפונקציית הבנאי ולא בעת ההכרזה על תכונת המחלקה:

פונקציות מחלקה

כמו בתכונות מחלקה, גם בפונקציות מחלקה נכריז תמיד על נגישות הפונקציה ועל שמה:

  • הסוגריים המסולסלים שפותחים ושסוגרים את הפונקציה יהיו בשורה נפרדת
  • שם פונקציה לא יתחיל בקו תחתון כדי לסמן פונקציה שהיא private או protected

בכל הנוגע לפרמטרים של הפונקציה, נרשום אותם כך שפרמטרים עם ערך ברירת מחדל תמיד יהיו בסוף,
מכיוון שלא תמיד נרצה להעביר ערך שונה לפונקציה:

  • כמו בשפה העברית, גם כאן אחרי כל פסיק יבוא רווח ורק לאחריו הפרמטר הבא

מקורות

  1. Coding Standards – מתוך מאגר PEAR
  2. Coding Style Guide – מתוך יוזמת FIG

לסיכום

סגנון כתיבה הוא נושא שנוטים לזלזל בו. אני מעודד אתכם לעבוד על סגנון הכתיבה שלכם ולהגיע לנוסחה שמתאימה לכם.
השיפור באיכות הקוד, יעילות ומהירות הכתיבה יורגשו כמעט מיד – על זה אני מתחייב!

אשמח לשמוע מכם תהיות, השגות והמלצות לשיפור סגנון הכתיבה 🙂

אם הגעת עד לפה, הגיע הזמן להירשם לניוזלטר!

Summary
Article Name
PHP - לכתוב את זה נכון
Description
הסבר מקיף על החשיבות שבבניית סגנון כתיבה אחיד ומסודר, כולל המלצות ודוגמאות לכתיבה נכונה יותר ב - PHP של: משתנים, פונקציות, מחלקות ועוד
Author
Publisher Name
Masterscripter
Publisher Logo
אודות 
hello world! אני יונתן, מתעסק בתכנות ופיתוח WEB פלוס מינוס מאז שאני זוכר את עצמי. ב2013 הקמתי את קבוצת סיזן ביחד השותף היקר שלי - שלומי שלומקה זק. ביום מתעסק בפיתוח ועיצוב אתרי אינטרנט ואפליקציות, עיצוב חוויית משתמש, הקמת מיזמים, ועוד..אבל מה שלא ידעתם עליי - זה שבלילה אני באטמן. אל תגלו לאף אחד!

5 תגובות

  1. אורי וולפוביץ

    15 ביוני 2016 - 12:28
    תגובה

    יצא לי לראות בהרבה מקורות (אחד מהם לדוגמא, היה ספרו המעולה של Larry Ullman) שכאשר מכריזים על משתנה מסוג private נהוג לשים קו תחתון בתחילת השם.

    private $_id
    private $_name

    אני מבין מכאן שאתה מתנגד לזה?

    • יונתן נקסון

      15 ביוני 2016 - 12:51
      תגובה

      מתנגד בהחלט 🙂
      קו תחתון לפני משתנה/פונקציה מסוג private זה הרגל רע שנשאר מהיישום הרע של תכנות מונחה עצמים ב – PHP4, כשלא היו סוגי גישות שונות, אלא רק public, ולכן כדי לסמן פונקציות מסוג private השתמשו בקו תחתון.

  2. רוני שרר

    16 ביוני 2016 - 13:02
    תגובה

    אהבתי. כתוב טוב וברור.
    שכחת לציין שחשוב שתכונת מחלקה לעולם לא צריכה להיות PUBLIC.

    • יונתן נקסון

      16 ביוני 2016 - 21:15
      תגובה

      הערה נכונה וחשובה, אבל בפוסט הזה התרכזתי יותר בסגנון כתיבה והשתדלתי לא להתפזר לנושאים אחרים,
      אבל רשמתי לעצמי להקדיש פוסט ל – magic methods ושם אתייחס לכך 🙂

  3. Yavin

    4 ביולי 2016 - 21:58
    תגובה

    אחלה מאמר, למדתי 🙂

השאר/י תגובה ליונתן נקסון

לבטל

האימייל לא יוצג באתר. שדות החובה מסומנים *