один програміст, багато мов - дилема імені

Під час роботи на декількох мовах програмування виникла проблема ...

Дійсне ім’я (ідентифікатор) в одній мові недійсне в іншій. Наприклад...

var new function this- це ключові слова в JavaScript, але ви можете їх вільно використовувати в Python. Аналогічно list dict defможна без проблем використовувати в JavaScript.

Це дуже поширене явище, і програмісти зазвичай швидко знайомляться, коли вони програмують на декількох мовах.

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

Отже, моє питання полягає в тому, які стратегії ви приймаєте ...

• просто з’єднайте всі зарезервовані слова, присутні на всіх мовах, якими ви користуєтесь, роздайте список усім і утримайтеся від їх використання?
• прийняти різноманітність та докласти додаткових болів при "переключенні контексту"
• прийняти проміжну основу, де одна мова може використовувати іншу, але не навпаки

(Примітка. У цьому питанні я кажу лише про Python та JavaScript ... але будь ласка, дайте відповідь ширше)

- ОНОВЛЕННЯ -

Дякую за всі відповіді. Отже, загальний консенсус, який я бачу, полягає в тому, щоб дозволити програмістам використовувати будь-яке ім’я незалежно від того, що вони роблять іншими мовами - доки імена описові, це не зашкодить.

Програмувавши на декількох мовах протягом 30+ років мого досвіду, я б сказав, що намагання знайти стандарти іменування, які працюватимуть на будь-якій мові, - це, мабуть, ідея пирога в небо.

На початку свого досвіду я намагався використовувати макроси #define в C, щоб створити речі, які зробили б мій код C схожим на код Паскаля, який я використовував до цього. Мене так звикли програмувати в Паскалі, що я зрозумів, що, якщо я можу просто змусити C працювати як Pascal, це зробить мене більш продуктивним. Невдовзі я виявив, що помиляюся.

Що зробило мене більш продуктивним - це вивчати С та не намагатися використовувати синтаксис Паскаля на іншій мові лише тому, що це зробило мені більш комфортно.

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

Якщо ви обмежите свої умови іменування лише тим, що має сенс пояснювати використання змінної, ви, мабуть, створите хороший код будь-якою мовою.

Ви не повинні називати речі "список", "новий", "вар", "це" в першу чергу, оскільки вони недостатньо описові на будь-якій мові.

Перехід від, скажімо, javascript до python вже є контекстним перемикачем. Я не думаю, що це погано, якщо імена змінних змінюються, особливо якщо зміни в імені є ідіоматичними з мовою. Можна навіть стверджувати, що складніші комутатори контексту можуть допомогти в цьому випадку, оскільки це сприяє посиленню "чувак, ти пишеш javascript не python зараз".

Я думаю, що якщо ви використовуєте описову змінну, називання проблеми, яку ви описуєте, має бути мінімальною. Зважаючи на це, якщо воно мінімальне, то прийняття зміщення контексту, викликане іменними змінними між мовами, також стає мінімальним.

Більшість застережених слів (будь-якою мовою) є досить загальними. Я вважаю за краще імена змінних / функцій, які є більш описовими, і це означає, що я майже ніколи не стикаюся з цією проблемою. Я повинен визнати, що був заражений Чарльзом Симоні за його первісною схемою іменування - це було в Xerox наприкінці 70-х років, до того, як його навіть називали угорською нотацією - і це також означає, що імена є чимось, ніж ніяким здоровим людиною коли-небудь використовуватиме як зарезервовані слова

Ви не повинні витрачати свій час на написання рекомендацій, поки ви не виявите, що це справжня , а не гіпотетична проблема.

Я можу подумати, де це може стати проблемою, коли ви поділитесь структурами даних між мовами програмування. Наприклад, якщо у вас є клієнтський об’єкт на стороні клієнта, який відображається в об’єкті Python на стороні сервера, і ви, природно, хочете, щоб вони мали однакові імена для своїх членів. У цьому випадку правило просте: не використовуйте імена, які є зарезервованими словами на жодній із мов. Це воно. Напишіть це в інструкціях, якщо хочете. Тепер переходимо до більш важливих завдань.

До речі, ні список, ні диктат не є застереженим словом у Python. Їх можна використовувати як імена змінних, хоча і досить вразливі.

На мій досвід, виправленням цього є створення широких конвенцій про іменування, які застосовуються до всіх мов. Будь то JavaScript, C # або якась інша дивна мова, те, як названі змінні та класи можуть стати еталоном у кодовій базі, як я зазвичай бачу вирішення цієї проблеми. Конвенції можуть бути узгоджені консенсусом кожного, просто більшість бажає керівних принципів, керівництво говорить: "Ось як ми це робимо", або кілька інших можливостей, які я собі уявляю.

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

Я не бачу, як це може колись бути проблемою, якщо ви не плануєте переміщення коду з однієї мови на іншу. Якщо ви особисто схильні забувати, які імена змінних є дійсними, тоді не використовуйте ім’я змінної, якщо ви особисто не впевнені, що це дійсно. Але якщо інші користувачі використовують недійсні імена змінних, їх код не компілюється та не запускається. Тож якщо ви працюєте над чужим кодом, і вони називали щось "var", ви можете бути впевнені, що це дійсне ім'я на будь-якій мові, якою вони користуються.

Якщо ви можете планувати переміщення коду з однієї мови на іншу, вам може знадобитися список заборонених імен. Наприклад, мій документ із методом кодування C забороняє використовувати новий або клас як змінну, оскільки це ускладнює код для порту на C ++. У цьому випадку доцільно встановити правила, які полегшують цю роботу, якщо це стане необхідним,

Просто дотримуйтесь CamelCase, що веде за малі регістри. Це працює скрізь. Це називається пошук найнижчого загального знаменника між несумісними системами, і ви виявите, що це робите часто!