Продолжая наше увлекательное путешествие с юмором по миру программирования, мы окунемся в новую главу и продолжим исследование, перед прочтением обязательно прочитайте прошлую статью об инновационном паттерне.
В мире программирования одним из наиболее значимых аспектов является выбор имен для переменных. Одним из широко распространенных подходов является использование буквенно‑цифровых обозначений, таких как «a», «b» и т. д. Возможно, это может показаться несущественным или лишь вопросом стиля, однако на самом деле эта практика имеет глубокие основания и является важной составляющей программистской этики. В данной статье рассмотрим преимущества использования таких обозначений и почему они способствуют повышению читаемости и понимаемости программного кода.
Красота в программировании находится не только в его функциональности, но и в его эстетике
Какие преимущества у "a b c case"?
Абстракция и общая понятность:
Использование однобуквенных имен переменных способствует созданию абстракции, позволяя программисту фокусироваться на более широких аспектах кода. При работе с более глобальными концепциями, такими как циклы, условия и функции, использование общепринятых обозначений делает код более лаконичным и понятным. Такие обозначения уменьшают визуальный шум и позволяют программисту быстрее ориентироваться в коде.
Повышение читаемости:
Использование буквенно‑цифровых переменных способствует повышению читаемости программного кода. Однобуквенные обозначения в коротких фрагментах кода могут быть более компактными и легкими для восприятия. Когда переменные имеют ясное и краткое обозначение, становится легче отслеживать поток данных и взаимодействие между различными компонентами программы.Универсальность и переносимость:
Использование общепринятых обозначений, таких как «a», «b», «i» и т. д., делает код более универсальным и переносимым. В ситуациях, когда несколько программистов работают над одним проектом или когда код переносится на другие платформы, использование таких имен переменных упрощает понимание и поддержку кода другими разработчиками.Сокрытие сложности:
Однобуквенные обозначения переменных могут помочь скрыть сложность алгоритмов или математических выражений, упрощая код и делая его более легким для понимания. Когда сложные вычисления или логика представлены через простые обозначения, это упрощает процесс отладки и поддержки кода.
Что об этом думают люди?
«Знаете, я всегда был непримиримым противником сложных имен переменных. Они меня смущают, будто я стою перед головоломкой. Я предпочитаю простоту, чтобы не тратить время на распутывание узлов. Вот почему я перешел на однобуквенные переменные. Многие считают это глупостью, но я считаю это актом гениальности! Когда я видел переменные типа 'clientRepository' или 'getUserById', у меня в голове возникали вопросы: 'Кто этот клиент? Зачем мне его репозиторий? И почему мы ищем пользователя по ID?'. Теперь же, с моими 'a1', 'b2' и 'c3', я могу спокойно улыбаться и говорить: 'Это просто переменная, не более'. Моя жизнь стала легче, а код — понятнее. Я не вижу в этом ничего глупого, ведь гениальность часто затмевает все остальное!»
«Посмотрите на всех этих людей с их продуманными именами переменных, будто они рассказывают историю в каждом символе. А я? Я просто смеюсь над ними с моими 'x', 'y' и 'z'. Они считают меня глупым и вечно говорят про какой‑то camel case и snake case, но я вижу, как они запутываются и теряются в деталях. Душнилы, одним словом! А я? Я могу спокойно передвигаться по коду, не вникая в их интеллектуальные штучки. И что самое смешное, когда я прошу объяснить, почему они используют такие длинные имена, они начинают оправдываться словами, что это делает код более читаемым и понятным. Но я смеюсь в лицо этим оправданиям, потому что я знаю, что моя простота бьет их сложность на всех фронтах. Так что пусть они там продолжают считать себя умными, а я буду смеяться с моими 'a1', 'b2' и 'c3' в уголке, где нет места для их ненужной интеллектуальной нагрузки.»
Мы уже использовали a b c case в нашей прошлой статье о паттерне программирования MOPP, поэтому в этот раз обойдемся без примеров.
Что делать, когда закончатся буквы?
Используйте цифры:
a = ...
b = ...
.
.
.
a1 = ...
a2 = ...
.
.
.
a9999999999999999999999 = ...Просто, и, что самое главное, понятно, без всяких там «varForUserToGetIdFromMySQL»
Заключение
Вы можете называть переменные так, как вам удобно или как принято, но опытные программисты знают: использовать MOPP наряду с "a b c case" - путь к успеху.
Комментарии (36)
Crimento
11.07.2023 12:26+1Если имена переменных так важны, то почему переменные в деобфусцированном коде записаны именно в a b c case? Шах и мат, программисты!
raamid
11.07.2023 12:26переменные в деобфусцированном коде
Вы наверное хотели сказать "в обфусцированном коде". Т.е. после специального усложнения читаемости.
А так, в целом мысль поддерживаю. Система именования переменных должна упрощать понимание программы и "объясняющие" имена переменных в этом здорово помогают. Короткие имена переменных ограничены применением в качестве локальных в коротких функциях не более 20-30 строк ИМХО.
mayorovp
11.07.2023 12:26+1Именно в деобфусцированном. В обсфуцированном часто используются ещё более мозголомные способы именования переменных, которые при деобфускации приходится заменять на порядковые имена, чтобы их хотя бы сравнить друг с другом можно было.
datacompboy
11.07.2023 12:26+18Я считаю что самым важным навыком для изучения это Oo0 паттерн. Что может быть лучше?
int o, O, oo, oO, o0, Oo, O0, OO; for (o=oo; o<oO; o+=Oo) o0 += OO;
Neusser
11.07.2023 12:26+2Разве что I1I паттерн может немного посоревноваться
int I, I1, II1, I1I, II1I; I1I1;datacompboy
11.07.2023 12:26+3В смысле, Il1 ?
int I, l, II, Il, I1, l1, lI, ll;Тоже хороший способ, да. но, к сожалению, `int i` это нормально :(
red-cat-fat
11.07.2023 12:26+1Нужен блог ИА Панорамы на хабре для таких публикаций. Пролистал сначала по быстрому и начал предпринимать попытка осознать что происходит первые минуты 2. Это реально кто-то так считает и пытается аргументировать, или же это Панорама просочилась.
gpaw
11.07.2023 12:26кстати, именование, проверенное временем - запись в шахматах не даст соврать. e2-e4.
vvbob
11.07.2023 12:26+1Самое четкое что я видел в коде - это именование пакетов и классов с использованием номеров тикетов. Это же прекрасно!!! Ну что непонятного в названии класса: GHJ47558954511256687? Это же так просто - открыть тикет и посмотреть о чем он! (правда тикеты есть не все, многие куда-то пропали, но хороший программист и так разберется!)
Badimagination
11.07.2023 12:26Ну в принципе, чисто гипотетически, если разбить (при написании) программу так, что каждый метод будет умещаться максимум на 1-н экран монитора с HD-разрешением, то качественным именованием именно переменных можно будет и пренебречь почти без потери читаемости кода.
Gutt
11.07.2023 12:26будет умещаться максимум на 1-н экран монитора с HD-разрешением
Долго смотрел на эту фразу, пытаясь понять, как же это должно выглядеть при н > 0. Потом, кажется, понял.
middle
11.07.2023 12:26+3Корень ошибки в том, что вы решили, что переменные нужны. Пишите в бесточечном стиле, без переменных, и проблема отпадёт сама собой.
0xd34df00d
11.07.2023 12:26+2Ну там все равно имена есть, просто у функций. А вот если на SK-комбинаторах писать...
Colt045
11.07.2023 12:26+4Предлагаю творчески углубить эту замечательную идею.
Вместо объявления переменных как
int a1;
int a2;
int a3;
… и т.д.
использовать конструкции вида:
int[] a;
В этом случае, кроме повышения уровня абстракции (о чем так убедительно рассказано в статье), мы получаем дополнительные профиты:
1. Все переменные располагаются в памяти одним блоком, что повышает аккуратность использования памяти.
2. Легко запомнить, какой тип имеет переменная, исходя из имени массива.
3. При необходимости можно легко изменить тип всех используемых переменных (например, если вдруг выясниться, что размерности int не хватает, то можно быстро переправить на long).
4. Упрощается визуальный контроль за использованием в одном выражении только однотипных переменных, что сразу же позволит избавиться от труднообнаруживаемых ошибок неявного преобразования типов.
5. Появляется возможность легко создавать (и восстанавливать) дамп состояния программы (сохранить во внешний файл один массив проще и надежнее, чем писать кучу переменных и ничего при этом не забыть).
vvbob
11.07.2023 12:26Надо развить идею - void *a;
Круто ведь - лаконично, запихнуть можно все что угодно, никаких проблем с размером - надо больше, выделил больше памяти, и не надо думать какой там тип лежит, клади что хочешь - свобода!
datacompboy
11.07.2023 12:26еще полезно использовать:
void * O = malloc(1024*1024*8); void * O0 = O; void * o0 = O+75; for(*(int*)(o0-71)=0777000;*(char*)(o0-72);*(char*)(o0-72)++) static oo += ++*(char*)(o0-70);
vilgeforce
Короткие имена идентификаторов ускоряют чтение программы компилятором, а также сокращают размер программы в интерпретируемых языках, что особенно актуально для JS!
tenzink
И ещё экономят место на диске и уменьшают нагрузку на сеть при распределённой компиляции )) Пруф
WinIce
Пишите сразу на ассемблере, и скорость исполнения максимум, и сеть не занимает. А специалисты и так разгребут все ваши баги.
tenzink
Чтобы не запускать лишние приложения нужно сразу кодить в машинных кодах. Настоящие специалисты разберутся, а об остальных и беспокоиться не стоит
simenoff
И экономят электроэнергию!