Каковы Ваши доводы за неиспользование транслита в коде?

Есть у меня один программист. Неплохой в общем-то парень, трудолюбивый, обязательный. Но со своими тараканами и упёртый до жути. Не могу его отучить использовать транслит в коде для названий переменных, классов и т.п. Так, например, вместо простого "backcall" пишет "zakaz_obrt_zvonok_otk". Я каждый раз бешусь, пытаюсь объяснить, привожу разные доводы, рассказываю про стандарты, но всё бесполезно. «Мне так удобно, я так привык, я не знаю английский...». Накидайте, пожалуйста, списочек ваших доводов, может быть я найду в них что-то новое для его переубеждения :) Спасибо!
  • Вопрос задан
  • 811 просмотров
Пригласить эксперта
Ответы на вопрос 12
OnYourLips
@OnYourLips
Лишите его премии за игнорирование стайлгайдов (чтобы не плевал на команду).
Ответ написан
2ord
@2ord
продвинутый чайник
Отправьте на курсы английского
Ответ написан
Комментировать
IonDen
@IonDen
JavaScript developer. IonDen.com
Заставьте несколько раз сделать рефакторинг названий. А дальше сам начнет)
Ответ написан
Комментировать
@Dvvarreyn
Я не знаю транслита и не видел курса по нему, а английский можно выучить. (здесь я, наверное, немого лукавлю, но и программист тот вряд ли совсем уже не знает английского)

Я читаю транслит гораздо медленней, чем английский. (и это чистая правда, транслит читаю по слогам, мне проще незнакомые романские языки читать, чем транслит)

На транслит много стандартов, каждый пишет, как ему захочется. С английским проще.

Названия ключевых слов и прочего в языке программирования на английском, и английские же названия переменных и функций сморятся более эстетично foreach object in list: validate(object), чем рунглиш.
Ответ написан
Комментировать
Пускай программирует на 1С, если не знает английского.
Ответ написан
ppokrovsky
@ppokrovsky
Код пишется не для удобства одного разработчика, а для того чтобы реализовывать бизнес-задачи. Рефакторинг и простота поддержки кода это бизнес-задача. Соглашением является именование методов и переменных на английском, так как, как выше уже сказали, такие названия органично смотрятся при чтении кода. Равно как завтра, например, код может пойти на международный рынок и разработка окажется за рубежом. Нерусскоязычный разработчик не сможет работать с таким кодом.

Если программист изобрел собственный стайлгайд и не желает следовать общепринятому - его право открыть собственную компанию и реализовывать там в команде свой стайлгайд. В противном случае в другой команде он мешает выполнению основной задачи кода - поддержке бизнеса. То есть делает противоположные своим прямым обязанностям вещи.

Мне кажется здесь нужно поставить вопрос ребром - никакие супер-компетенции не должны идти на поводу прихотей. В крайнем случае если разработчик сверхчеловек - отправьте его на курсы языка.
Ответ написан
Комментировать
angrySCV
@angrySCV
machine learning, programming, startuping
это у вас в голове тараканы, и какие-то непонятно откудо взятые догмы.
ну сколько можно насиловать разработчиков и заставлять их думать на английском, где скажите мне GDE сказано, что нужно обязательно на английском название переменных делать?
если вы неебаться там транснациональная корпорация типа гугла -> тогда да, можете объяснять за культуру использование "международного" языка в "международной" команде,
но если вы в России живёте и разрабатываете продукт в русскоговорящей команде -> не мучайте их, не заставляйте думать на английском, пускай они описывают смыслы и идеи на родном языке (транслите), использование английских переменных вам ничего кроме мучения и снижение производительности не даёт.
Ответ написан
Denormalization
@Denormalization
Покажите этому "нехочухе" код на французском или на японском\китайском транслите, и пусть он попытается разобраться в нем и отрефакторить.
Гнать взашей таких нехочух.
Ответ написан
Комментировать
laska
@laska
PHP/JS разработчик
Очень многие языки программирования поддерживают название переменных прямо в Юникоде - поэтому можете не стесняется, и писать прямо заказ_обрт_звонок_отк. Ничего прям страшно плохого в этом нет, как я понимаю, это тот случай, когда код за пределы чисто русскоязычной компании не выйдет. А русские буквы смотрятся даже лучше транслита, как по мне (привет, 1С).

Но есть нюанс. Все в компании должны писать одинаково. С одинаковыми принципами наименования переменных. С одинаковым количеством пробелов/табов. В общем, много таких микро вопросов.

Соберитесь, выберете всей компанией стандарт, если у тимлидера нет авторитета сделать это в одиночку. И обязательно контролируйте это на уровне системы контроля версий. Код не по стандарту не должен быть закоммичен!
Ответ написан
Adamos
@Adamos
Есть технический вариант: внедрите в используемом IDE проверку синтаксиса и сделайте ее "чистоту" обязательной. Транслит не пройдет, а заодно уменьшите количество опечаток. Особенно актуально для языков с неявным объявлением переменных типа пыха с жабоскриптом.
Ответ написан
Комментировать
1. Пусть этот упёртый человек так и остаётся примером программиста с недостатками.
2. Как вариант, купите ему ABBYY Lingvo, пусть играет с буфером обмена.
Ответ написан
gbg
@gbg Куратор тега Программирование
Любые ответы на любые вопросы
Kod vigladit ochen debil'no, budto ego sms-kami nabirali s mobilnika bez russkogo.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
ГК «НЕОФАРМ» Москва
от 130 000 до 180 000 ₽
Gara.Capital Москва
от 500 000 до 800 000 ₽
Метр квадратный Санкт-Петербург
от 150 000 до 350 000 ₽
06 дек. 2021, в 09:20
50000 руб./за проект
06 дек. 2021, в 07:23
1000 руб./за проект
06 дек. 2021, в 07:18
1000 руб./за проект