Англійська для розробників Perl

Розмови на Perl сильно залежать від точної термінології, тому що так багато з поведінки мови — як виглядає змінна, що значення оцінює, як збіг захоплюється — залежить від маленьких символів і ситуаційних правил, які легко пробурмотіти, але важливо правильно назвати при перегляді коду або зневаджування з товаришем по команді.

Ключовий словник

** Печатка ** — символ, який додається до назви змінної ($, @, %) і який вказує на її тип — скалярний, масивний або геш — і є обов’ язковим синтаксисом, а не декорацією. “Вада була в невідповідності символів — ви відкидаєте посилання на масив, але символи кажуть, що це скаляр, отже Perl бачить лише останній елемент.”

** Контекст (скалярний проти списку) ** — синтаксис навколишнього середовища, який визначає, чи буде вираз оцінено як одне значення або як список значень, змінюючи, які функції, наприклад, функція призначення масиву, повертатимуть результати. “У скалярному контексті масив повертає свою довжину, але у контексті списку він повертає кожен елемент — це все джерело вади.”

** Захопити групу ** — частина формального виразу, що містить у дужках підрядок, який витягується у пронумеровану або названу змінну для подальшого використання.

• “Оберніть частину дати у групу захоплення, щоб $1 дало вам лише рік замість всього рядка, який збігається.” *

** Модуль CPAN ** — пакунок для повторного використання, опублікований у Comprehensive Perl Archive Network, стандартному способі, за яким розробники Perl обмінюються і встановлюють сторонні бібліотеки. “Не створюйте аналізатор JSON вручну — використовуйте модуль CPAN, який вже використовують і якому довіряють всі.”

TIMTOWTDI (існує більше одного способу зробити це) — керівний принцип спільноти Perl, що мова навмисно підтримує декілька дійсних стилів для одного і того ж завдання, а не вимагає використання однієї ідіоми. “Не переписуйте їхню петлю тільки тому, що ви написали б її по-іншому — TIMTOWTDI є справжнім значенням дизайну тут, а не виправданням для непослідовності.”

Звичайні фрази

• Чи це сигільна помилка, чи змінна насправді має бути посиланням на масив?»
• «Чи ми в скалярному контексті чи контексті списку тут — це змінює те, що повертає ця функція»
• Чи ви назвали групу захоплення, чи ми покладаємося на $1 і сподіваємося, що порядок не зміниться?
• «Чи є модуль CPAN для цього вже, або ми дійсно пишемо його з нуля?»
• «Я знаю TIMTOWTDI, але чи можемо ми принаймні погодитися на один стиль для цієї кодової бази?»

Приклади висловлювань

Зневадження з колегою: “Спочатку перевірте сіґіл — якщо це має бути посилання на геш, то відкидання посилання на нього за допомогою @ безмовно дасть вам неправильну річ.”

Перегляд формального виразу у запиті на звантаження:

• “Додати групу захоплення навколо суфікса, щоб ми могли перевірити його окремо, замість того, щоб збігатися з всією назвою файла як з одним об’ єктом.” *

Пояснення командної угоди:

• “Ми знаємо, що TIMTOWTDI є ядром Perl, але для цієї спільної бібліотеки ми стандартизуємо один стиль, щоб нові працівники могли читати її швидше.” *

Професійні поради

• Діагностуйте вади, виразно назвавши sigil — « неправильний sigil » є швидшим, точнішим звітом про ваду, ніж « змінна виглядає не так. »
• Завжди запитувати про ** контекст **, якщо значення, що повертається функцією, здається непослідовним — контекст скалярного проти списку пояснює велику частину сюрпризів у Perl.
• Віддавати перевагу названим групам перед пронумерованими ** групами захоплення ** у зворотному зв’ язку перегляду коду — це запобігає пошкодженню чутливих посилань, таких як $1, під час зміни регулярного виразу.
• Посилання TIMTOWTDI при обговоренні дискусій щодо стилів, але поєднуйте його з нотаткою про командні конвенції — гнучкість на рівні мови не означає, що все може бути в спільній кодовій базі.

Практичні вправи

1. Поясніть різницю між скалярним і масивним сигілями, а також описайте ваду, яку може спричинити невідповідність сигіл.
2. Описує, яким чином скалярний контекст у порівнянні з контекстом списку може змінювати результат одного і того ж виразу.
3. Написати коментар перегляду коду, який пропонує названу групу захоплення замість покладання на $1.

Недоліки: Неможливість використовувати для передачі мовлення

Як розробники Perl, ми звикли до певного рівня свободи — прекрасно гнучкого синтаксису, який дозволяє нам створювати елегантні рішення. Але коли спілкуєшся з колегами, особливо з тими, чия перша мова не англійська, ця гнучкість може стати джерелом плутанини. Це не просто про знання слів; це про передачу намірів і розуміння з точністю. Багато не-рідних носіїв знаходять неявну природу Perl, особливо використання сигіл і контексту, що викликає труднощі в чіткому вираженні англійською мовою, що призводить до нерозуміння під час перегляду коду або при поясненні вибору дизайну. Тонкі підказки, які рідні англомовні люди легко підбирають - наприклад, важливість явного зауваження * чому * був обраний певний підхід - можуть бути втрачені на тих, хто все ще розвиває свою плавність. Це не про звинувачення когось; це про визнання когнітивного навантаження, пов’язаного з перекладом між мовами і забезпечення того, щоб всі були на одній сторінці. Сфокусування на ясній, описовій фразування стає найважливішим, особливо при детальному описі технічних проблем або запропоновані рішення. Пам’ ятайте, що неоднозначність * завжди * більш шкідлива, ніж трохи розгорнута, але досконало точна мова.

Поширений сценарій виникає під час перегляду коду. Рецензент може залишити коментар на зразок: « Декларацію my можна було б тут виключити; вона неявно обмежена. » Хоча намір — запропонувати спрощення — є ясним, нерідкомовець може негайно зрозуміти причини за пропозицією. Вони можуть просто відповісти: «Гаразд, я вилучу my. Але чи можете ви пояснити чому?» Ефективнішою відповіддю для рецензента було б: « Вилучення my тут покращує читабельність, оскільки явно визначає обсяг змінної і зменшує потенційні проблеми з затемненням — це допомагає запобігти несподіваній поведінці у більших модулях ». Таке пояснення надає не лише розв’ язок, але і контекст. Аналогічно, повідомлення Slack, що обговорює складну ваду, може отримати користь від додавання: «Я підозрюю, що це через умову гонки з одночасним доступом до гешів; нам потрібно реалізувати відповідні механізми блокування». Ясна згадка про «умову гонки» і «механізми блокування» підкреслює ключові технічні терміни, які були б незнайомі для когось з меншим досвідом.

Давайте розглянемо приклад, що ілюструє цю концепцію за допомогою awk. При усуненні проблем з продуктивністю, зазвичай використовується awk для перевірки потоків даних.

# Example:  Filtering log lines by severity level
awk '{ if (level == "ERROR") print}' my_log_file.txt

Рідний мовець відразу ж зрозуміє намір - фільтрування повідомлень про помилки. Однак, пояснювати це коротко для не-рідного мовця може включати в себе такі фрази як «Ця команда обробляє кожен рядок my_log_file.txt і друкує тільки ті рядки, де поле ‘рівень’ дорівнює ‘ERROR’». Додані подробиці надають важливу інформацію щодо дії програми і її взаємодії з вхідним файлом. Звернення уваги на ці нюанси не означає надмірної обережності; воно означає сприяння ясному спілкуванню і забезпечення того, щоб технічні обговорення були доступні для всіх, незалежно від їх рідної мови. Це простий зсув у перспективі: розгляньте, яку інформацію треба чітко вказати для максимального розуміння.