הסרטון הזה מציג לינטרים ומעצבי קוד, שני כלים שאפשר להריץ בזמן שהסוכן משנה את הקוד שלכם. נראה מה כל אחד מהם עושה, נשתמש ב-diff קטן כדי לראות איך עיצוב אחיד מקל על הסקירה, ונריץ את שני הכלים בפייתון וב-TypeScript. אחר כך נתקן דיווח לינט אמיתי אחד, ונהפוך מוסכמה של הפרויקט לכלל לינט.
נתחיל בהפרדה בין שני כלים שבדרך כלל מוזכרים באותה נשימה. לינטר מחפש בקוד שלכם דפוסים חוקיים לגמרי, אבל חשודים. import שלא בשימוש, השוואה שתמיד יוצאת נכונה, משתנה שמסתיר בשקט משתנה אחר. באופן כללי יותר, לינטר מדווח על בעיות בקוד ועל הפרות של מוסכמות, לפי הכללים שהוגדרו לו. הוא מדווח על מה שהוא מוצא, וכברירת מחדל לא משנה כלום.
מעצב קוד עושה משהו הרבה יותר צר. הוא מאחיד את העיצוב של הקוד שלכם לצורה קנונית אחת, בלי לשנות את מה שהתוכנית עושה. הוא מחליט איפה נשברות השורות, כמה עמוקה ההזחה, האם יש רווח אחרי פסיק, ובאילו מירכאות מחרוזת משתמשת.
עיצוב אחיד משתלם כשעוברים על שינויים. הנה דוגמה ל-diff מפרויקט בלי עיצוב כזה. השינוי שביקשנו מעלה את שיעור המס, אבל הסוכן גם משנה את הרווחים בפונקציה. ה-diff מראה שלוש שורות שהוסרו ושלוש שורות שנוספו.
רק העריכה בשיעור המס, מ-0.17 ל-0.18, משנה כאן את ההתנהגות. כל השאר זה רווחים. diff שמוצף בשינויי פריסה מזמין דפדוף במקום קריאה, וקל יותר לפספס את השינוי המשמעותי.
השוו את זה לאותה עריכה בקובץ שכבר מעוצב. הקובץ בצורה קנונית לפני העריכה, וגם אחרי שמעצבים אותו שוב. בדוגמה הזאת, שינויי הרווחים נעלמים, ונשארות רק השורה הישנה והחדשה עם שיעור המס ששונה.
עיצוב אחיד מסלק הבדלי פריסה מיותרים, וכך קל יותר למצוא את העריכות המשמעותיות. זה עוזר כשסוכן מייצר diff גדול ואתם צריכים להבין מה השתנה.
לכל אחד מהכלים יש פקודה שאפשר להריץ בפרויקט. בפייתון, הריצו ruff check . ב-TypeScript, הריצו npx eslint . עם קובץ ההגדרות של ESLint בפרויקט. כל לינטר בודק את הקבצים שההגדרות שלו בוחרות ומדווח על הפרות של הכללים שהופעלו.
לשני הלינטרים יש דגל תיקון: ruff check --fix . או npx eslint --fix . הם מחילים את התיקונים האוטומטיים הזמינים ומדווחים על מה שנשאר. עברו על השינויים וטפלו במה שנותר.
כדי לעצב את הקוד, הריצו ruff format . בפייתון, או npx prettier --write . ב-TypeScript. כל אחד מהם כותב מחדש את הקבצים הנתמכים בפרויקט לצורה קנונית אחת, ומצמצם הבדלי עיצוב בסקירה הבאה.
הלינטר מסיים בקוד יציאה שונה מאפס כשיש שגיאות, כך שהכישלון גלוי גם לתוכנית, לא רק לבן אדם. מצב הכתיבה של מעצב הקוד מתקן את העיצוב. הפקודות ruff format --check . ו-npx prettier --check . נכשלות במקום זה כשהעיצוב צריך שינוי. השתמשו במצב הכתיבה בזמן העריכה. השתמשו במצב הבדיקה כשאתם רוצים שהפקודה תדווח על כישלון בלי לשנות אף קובץ. בקשו מהסוכן להריץ את הלינטר ואת מעצב הקוד לפני שהוא מדווח שסיים.
כך נראה דיווח לינט אחד. הקובץ billing.py מייבא את המודול os ולא משתמש בו. הפקודה ruff check . מדווחת שהכלל F401 הופר: os מיובא ולא בשימוש. היא מציינת את הקובץ, השורה והעמודה, ומציעה להסיר את ה-import. הפקודה מסיימת בקוד יציאה שונה מאפס, כך שהסוכן יודע שהבדיקה נכשלה.
הכוכבית בסוגריים מסמנת דיווח ש-Ruff יכול לתקן אוטומטית. הפקודה ruff check --fix . מסירה את ה-import שלא בשימוש, ומדווחת על שגיאה אחת שנמצאה, אחת שתוקנה, ואף אחת שנשארה.
הרצה חוזרת של הבדיקה מאשרת את התיקון. כל הבדיקות עברו, והפקודה מסיימת בקוד יציאה אפס. זו הלולאה שאתם רוצים שהסוכן יעבוד לפיה. לקרוא את הדיווח, לתקן את הסיבה, ולהריץ את הבדיקה שוב עד שהיא נקייה.
לינטר יכול לבדוק גם מוסכמות שבחרתם לפרויקט. גם טסטים וטיפוסים יכולים לבטא דרישות של הפרויקט. כללי לינט שימושיים כשאפשר לזהות את המוסכמה כדפוס בקוד. נניח שהפרויקט שלכם מרכז את כל הגישה למסד הנתונים בחבילה אחת, בשם db. רק החבילה הזאת רשאית לייבא את sqlite3. משפט בקובץ ההוראות מבקש מהסוכן לפעול לפי המוסכמה הזאת.
הפכו את המוסכמה לבדיקה שרצה. לינטר רואה כל שורת import, ולכן הכלל הזה הוא דפוס שהוא יכול לבדוק. ב-Ruff, השורה extend-select מפעילה את הכלל לייבוא אסור, וההגדרה banned-api מציינת את המודול האסור, כאן sqlite3. אז Ruff מדווח על כל קובץ שמייבא אותו, חוץ מהקבצים בחבילה db, שההגדרה per-file-ignores פוטרת. ב-ESLint, הכלל no-restricted-imports עושה אותו דבר. לינטרים יכולים לקבל גם כללים אחרים. בעצם, כל דבר שאפשר לתכנת כבדיקה על הקוד יכול להפוך לכלל לינט. המשפט מבקש מהסוכן לציית. כלל הלינט מדווח על כל הפרה, בכל פעם שהוא רץ.
יש מקרים שבהם לינטרים יכולים להזיק. דמיינו כלל שאוסר להדפיס, מופעל בכלי שורת פקודה שכל תפקידו להדפיס. כל שלוש השורות האלה מדווחות, ושלושתן נכונות.
הערות השתקה גורמות לדיווחים האלה להיעלם. השורות האלה כבר לא נבדקות לפי הכלל הזה.
אם הדפסה מתאימה לכל מודול שורת הפקודה, הגדירו את ההיקף במקום זה, בעזרת per-file-ignores של Ruff או override בהגדרות של ESLint. כאן, שתי שורות ב-pyproject.toml מכבות את כלל ההדפסה רק עבור cli.py. כל שאר הקבצים עדיין נבדקים.
כלל שמדווח כל הזמן על קוד תקין עלול להשאיר אתכם עם בלגן של הערות השתקה ועם פחות אמון באזהרות שלו. התחילו מההגדרות הסטנדרטיות במקום להפעיל את כל הכללים. השתמשו בדיווחים בעבודה אמיתית כדי להחליט אילו כללים עוזרים ואילו צריכים היקף צר יותר.
אז תנו למעצב הקוד לשמור על ה-diff ממוקד בהתנהגות. ותנו ללינטר לשאת את הכללים של הפרויקט. הוא תופס באגים סבירים ומוסכמות שהופרו תוך שניות, כך שהסוכן מתקן אותם עוד לפני שאתם קוראים את הקוד. התחילו מההגדרות הסטנדרטיות של הפרויקט, והן ישרתו אתכם היטב. תודה שצפיתם, נתראה בסרטון הבא.