Розбіжності

Тут показані розбіжності між вибраною ревізією та поточною версією сторінки.

--- codingguidelines [2023/08/01 11:35]
nightfly
+++ codingguidelines [2025/09/26 15:14] (поточний)
pautina
@@ Рядок 61: / Рядок 61: @@
 ==== PHP-теги ====
-PHP-код обов'язково слід розміщувати в повній версії (<?php ?>) тегів або в скороченій (скорочений запис echo) версію (<?= ?>) тегів і неприпустимо поміщати в жодні інші різновиди тегів типу (типу <%).
+PHP-код обов'язково слід розміщувати в повній версії (<?php ?>) тегів або в скороченій (скорочений запис echo) версію (<?= ?>) тегів і неприпустимо поміщати в жодні інші різновиди тегів типу (типу <%). Закриваючий тег (?>) можна пропускати.
@@ Рядок 88: / Рядок 88: @@
 Щодо скорочених AND (&&) OR (||) все залишається на вашій совісті, але загалом економія одного байта у випадку AND та економія нуля байт у випадку OR може не коштувати погіршення читабельності та самоочевидності вашого коду.
-На тему табів, відступів та іншого - більшість розробників використовує IDE NetBeans і рефлекторно натискає **Alt+Shift+F** для автоматичного форматування коду.
+На тему табів, відступів та іншого - більшість розробників використовує IDE NetBeans та Visual Studio Code і рефлекторно натискає **Alt+Shift+F** для автоматичного форматування коду.
 ==== Іменування змінних та констант ====
@@ Рядок 124: / Рядок 124: @@
 </code>
-Винятком для односкладового і простого іменування змінних є загальноприйняті і містечково прийняті імена змінних для типових операцій, які використовуються у нас здебільшого під час перебору масивів. Прикладами таких допустимих змінних можуть бути:
+Винятком для однобуквового і простого іменування змінних є загальноприйняті та місцево прийняті імена змінних для типових операцій, які використовуються у нас здебільшого під час перебору масивів. Прикладами таких допустимих змінних можуть бути:
 <code php>
@@ Рядок 145: / Рядок 145: @@
 }
 </code>
+А ось взагалі дуже [[https://www.youtube.com/watch?v=-J3wNP6u5YU|чудове та пізнавальне відео]] про те як іменувати штуки в коді.
 ==== Іменування класів та об'єктів ====
@@ Рядок 258: / Рядок 260: @@
 **Щодо збереження легасі на рівні передбачуваності поведінки системи**: якщо ви робите функціонал, який змінює поведінку системи за замовчуванням, пам'ятайте, що робите ви його передусім не для себе, а для купи мереж, які сподіваються, що після оновлення поведінка їхньої системи буде передбачуваною та звичною, а дівчатка-касирки не почнуть писати заяви про звільнення паралельно з системними адміністраторами, які викидаються з вікон. Якщо для реалізації запланованого вами функціоналу потрібно змінити поведінку системи, цей функціонал потрібно вимкнути за допомогою файлів конфігурації та відключити за замовчуванням. Погодьтеся, ви не будете радіти тому, що після оновлення під час спроби потрапити до профілю користувача, ви замість нього побачите фотку цицьок, нехай навіть дуже гарних. Кожного разу, коли вам хочеться зробити "для всіх" щось, що здається вам дуже крутим, подивіться для [[http://stats.ubilling.net.ua/graph/|скількох]] мереж ви хочете зробити життя "веселішим" і адекватно оцініть шанси на потрапляння цього в мейнстрім.
-**З приводу збереження легасі на рівні коду**: на даний момент, ми змушені підтримувати працездатність Ubilling від PHP 5.3 до PHP 7.4 та PHP 8.2 (так, це можливо і зовсім не складно), через велику кількість старих установок, які міняти та перевстановлювати на проді, ніхто не буде, так як вони успішно працюють роками. Тому утримайтеся як від використання нового синтаксису масивів із квадратними брекетами у вигляді
+**З приводу збереження легасі на рівні коду**: на даний момент, ми змушені підтримувати працездатність Ubilling від PHP 5.3 до PHP 7.4 та PHP 8.2 з PHP 8.3 (так, це можливо і зовсім не складно), через велику кількість старих установок, які міняти та перевстановлювати на проді, ніхто не буде, так як вони успішно працюють роками. Тому утримайтеся як від використання нового синтаксису масивів із квадратними брекетами у вигляді
 <code php>
@@ Рядок 451: / Рядок 453: @@
 ==== Документування змін ====
-Якщо у вас є доступ до редагування цієї wiki - документуйте зміни внесені вами. Як мінімум варто додати відомості про те, що ви щось зробили в [[changelog|Чейнджлог]]. Кінцеві користувачі повинні знати, як змінитися їхнє життя в майбутньому. Зміни, які не видимі кінцевому користувачеві і ніяк не впливають на його життя, в принципі, можна не описувати, хоча теж можна у вигляді "там-то проведено рефакторинг/чистка/оптимізація коду". Намагайтеся зробити це коротко і зрозуміло, бажано в один рядок. Хорошими прикладами можуть бути такі описи зроблених вами змін:
+Якщо у вас є доступ до редагування цієї wiki - документуйте зміни внесені вами. Як мінімум варто додати відомості про те, що ви щось зробили в [[changelog|Чейнджлог]]. Кінцеві користувачі повинні знати, як змінитися їхнє життя в майбутньому. Зміни, які не видимі кінцевому користувачеві і ніяк не впливають на його життя, в принципі, можна не описувати, хоча теж схвалюються, у вигляді "там-то проведено рефакторинг/чистка/оптимізація коду". Намагайтеся зробити це коротко і зрозуміло, бажано в один рядок. Хорошими прикладами можуть бути такі описи зроблених вами змін:
   * Модуль "Безвихідь": більше не викликає масової загибелі перламутрових їжаків.
@@ Рядок 460: / Рядок 462: @@
   * alter.ini: додано нову опцію CHAINSAW_ENABLED, призначену для ввімкнення техаської різанини бензопилою.
-Також у разі додавання нової опції, ви маєте задокументувати її на сторінках, присвячених відповідному файлу конфігурації, на кшталт таких для [[alteriniconf|alter.ini]] або [[userstats|userstats.ini]], де опції слід зазначати зі значеннями за замовчуванням, а також у [[relnotes|Рекомендаціях до оновлення]]. Також не забуваємо заповнювати опціями та їхніми значеннями за замовчуванням самі файли оновлень для поточного релізу в **content/updates/configs/**
+Також у разі додавання нової опції, ви маєте задокументувати її на сторінках, присвячених відповідному файлу конфігурації, на кшталт таких для [[alteriniconf|alter.ini]] або [[userstats|userstats.ini]], де опції слід її зазначати, зі значеннями за замовчуванням, а також у [[relnotes|Рекомендаціях до оновлення]]. Також не забуваємо заповнювати опціями та їхніми значеннями за замовчуванням самі файли оновлень для поточного релізу в **content/updates/configs/**
+У яких випадках, для вашого модулю, або чого б то не було, варто заводити окрему сторінку документації?
-У яких випадках, для вашого модуля, або чого б то не було, варто заводити окрему сторінку документації? Критерії дуже прості:
+Критерії дуже прості:
   - Ваш модуль вимагає конфігурації, відмінної від увімкнення/вимкнення
@@ Рядок 470: / Рядок 474: @@
   - Робить неочевидні сторонній людині штуки
-Не обов'язково писати покроковий мануал з картинками для домогосподарок. Ми сподіваємося, що нашим продуктом користуватимуться мінімально профпридатні системні адміністратори провайдерів (ну хоча б у майбутньому). Тому документацію ви пишете насамперед для себе - це дасть змогу в майбутньому вам без проблем самим же використовувати написаний вами функціонал, а також позбавить головного болю з підтримкою інших користувачів, які хочуть його використовувати, та заощадить ваш же час. Тикнути посиланням у документацію - завжди швидше і простіше.
+Не обов'язково писати покроковий мануал з картинками для домогосподарок. Ми сподіваємося, що нашим продуктом користуватимуться мінімально профпридатні системні адміністратори провайдерів (ну хоча б у майбутньому). Тому документацію ви пишете насамперед для себе - це дасть змогу в майбутньому вам без проблем самим же використовувати написаний вами функціонал, а також позбавить головного болю з підтримкою інших користувачів, які хочуть його використовувати, та заощадить ваш же час. Тикнути посиланням у документацію - завжди швидше і простіше ніж щоразу на пальцях пояснювати кожному "що" і "як?".
 ==== Великодки, відсилки та інший фансервіс ====
@@ Рядок 482: / Рядок 486: @@
 ==== Контрибуція в Ubilling ====
-Будь ласка, якщо ви хочете зробити свій внесок у розвиток проекту, робіть нормальні пуллреквести. Ніхто не хоче і не буде витрачати свій особистий час на построкове і побайтовое вивчення (ми це називаємо "очний diff") вашої писанини, надісланої на пошту, месенджери або розкиданої по форумах і пейстбінах.
+Будь ласка, якщо ви хочете зробити свій внесок у розвиток проекту, робіть нормальні пуллреквести. Ніхто не хоче і не буде витрачати свій особистий час на порядкове і побайтовое вивчення (ми це називаємо "очний diff") вашої писанини, надісланої на пошту, месенджери або розкиданої по форумах і пейстбінах.
 ==== Оформлення Пуллреквестів ====
@@ Рядок 503: / Рядок 507: @@
 git add CONTRIBUTING.md
 git commit -m "I add some line to CONTRIBUTING"
-git push —set-upstream my-fork master-some-fix
+git push -u my-fork master-some-fix
 </code>
@@ Рядок 509: / Рядок 513: @@
 {{ :faq-pr-create-pr.png?500 |}}
-Після створення пулреквесту - [[https://github.com/nightflyza/Ubilling|Github]] визначить, чи є конфлікт з офіційним кодом чи ні. Якщо конфлікту немає, то просто чекаємо поки його зморжать. Якщо конфлікт є - закриваємо пулреквест і робимо всі зміни по новій, тільки так, щоб не вийшли знову конфлікти.
+Після створення пулреквесту - [[https://github.com/nightflyza/Ubilling|Github]] визначить, чи є конфлікт з офіційним кодом чи ні. Якщо конфлікту немає, то просто чекаємо поки його змерджать. Якщо конфлікт є - закриваємо пулреквест і робимо всі зміни по новій, тільки так, щоб не вийшли знову конфлікти.
-Чекаємо, поки мейнтейнер усе смердить.
+Чекаємо, поки мейнтейнер усе змерджить.
 Головне, щоб ваші коміти не перетиналися з його змінами, інакше тоді доведеться все заново робити.
-Далі повертаємося в гілку master офіційного проєкту й оновлюємо вже змерзлий код:
+Далі повертаємося в гілку master офіційного проєкту й оновлюємо вже змерджений код:
 <code bash>
 git checkout master

Ubilling Wiki

Користувальницькькі налаштування

Налаштування сайту

Розбіжності

Налаштування сторінки