Очень часто читаешь в книжках и статьях, что код должен быть удобочитаемым. Но вот вопрос для кого?
И тогда нам предлагают варианты.
1. Для других людей.
2. Для англоязычных пользователей.
А что насчёт того кто написал этот код, то есть для себя. Почему бы не выйти за рамки и не наплевать на чужие "стандарты".
От ассемблера до смартфона
Что общего у ассемблера и смартфона с точки зрения синтаксиса?
1. Ассемблер не обладает многоуровневым синтаксисом.
2. Экран смартфона в вертикальном положении узок.
На самом деле даже ассемблер в одной строчке содержит одну команду.
Вот я взял случайный код из интернета.
mov ah,9 ; номер функции DOS - в АН
Недостаток здесь в том, что при таком стиле нельзя прокомментировать каждую строчку отдельно.
Код так же получил возможность влезать в экран смартфона. Я говорю именно про код, а не комментарии к коду.
Комментарии к коду
Что касается комментариев, то они могут быть разнообразными.
1. Простыми строками. "я коммментарий".
2. Иерархическими тегами. "тег.иерархический".
Так же принадлежать к различным слоям описания конструкций.
1. Инструкции.
2. Шаблоны.
3. Архитектура.
Я не буду приводить конкретные примеры, так как это может привести к неправильному пониманию того, о чём я пишу. Ведь основной смысл не в том, что я навязываю какой-то свой "стандарт" как это делают другие. Я лишь показываю способ как можно писать то, что думаете именно вы, когда пишете код. Или я, если я это буду писать чисто для себя.
Метаредактирование кода
Хорошо, конечно, иметь идеи по метаредактированию кода, когда он остаётся прежним, но его вид меняется как на примере выше. Когда код преобразуется в массив элементов, который сериализуется и десериализуется, то есть по русски переводится в последовательность и наоборот.
Однако по факту имеем то, что имеем. Если человек не может понимать безумные простыни многоуровневого кода без подробных собственноручных объявлений, то что тогда. Мало того, что языки программирования придумали для тех, кто говорит на английском, так ещё и идёт последующее усложнение.
Фактически нет никаких команд типа mov из ассемблера или функции main из Си. Как нет, когда есть? А вот так, это не уровень компьютерной грамотности, в ней всё состоит из нулей и единиц, это уже упрощение сделанные для англичан, но вот русским такие "улучшения" никак не упрощают жизнь.
Логические приёмы
Опять же есть множество логических приёмов, таких как.
1. Анализ. Разложение.
2. Синтез. Сложение.
3. Сравнение.
И так далее, кому надо может почитать "Логика. Учебник для средней школы (1954). Виноградов. Кузьмин". То что я сделал это по сути разложение, которое так же может пригодиться при сравнении и сложении. Хотя стоит отметить, что сложение будет происходить не путём изменения стиля кода, а вставлением строк.
Почему код стал многоуровневым
На вопрос зачем пихать в одну строчку множество понятий я могу сделать предположение, что по привычке. В конце концов книги или их примитивные подобия существуют не одно тысячелетие. Да и речь не предназначена для логических приёмов. Подробнее я писал об этом в статье Словесный поток и чёткие структуры и её продолжении Конспектирование на смартфоне.
Что касается кода, то не смотря на огромное количество способов его писать, причём поддерживаемых компиляторами, люди пишут так как пишут. Нельзя даже сказать, что они пробовали что-то иное и потом поработав с одним и с другим выбрали лучшее. Нет, правда в том, что людям даже в голову не приходит, что можно иначе. В конце концов все мы учились по "одним учебникам".
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Хотелось бы услышать, какую задачу ты пытаешься решить и зачем.
На мои статьи такой вопрос был уже не раз. Для понимания возьмём метод от обратного. Будет ли такой код работать?
int main(void){puts("Hello, World!");return 0;}
Какую задачу ты или я решаем, когда пишем такой код? Очевидно это не функциональность, так как она что в топике, что здесь одинакова. Естественно дело в понимании, ведь логика в переводе на русский это мышление.
В целом я думаю, что современные программисты это систематическая ошибка выжившего, они и судят с той же точки зрения. Если им не пробило двигатель или топливную систему, то они делают вывод, что двигатель и топливная система не критические элементы.
Есть распространенное мнение, что код, в котором каждая строчка требует комментария (не говоря уже о каждом слове), никуда не годится.
Такое может быть востребовано на этапе обсуждения. И (фанфары) продвинутые инструменты code review позволяют это, комментировать любой произвольный участок текста и видеть, что и как прокомментировали другие.
Но в итоге, несколько общих комментариев к отдельным участкам кода + commit message должно быть достаточно, нет?
Здравствуйте, velkin, Вы писали:
V>Что касается кода, то не смотря на огромное количество способов его писать, причём поддерживаемых компиляторами, люди пишут так как пишут. Нельзя даже сказать, что они пробовали что-то иное и потом поработав с одним и с другим выбрали лучшее. Нет, правда в том, что людям даже в голову не приходит, что можно иначе. В конце концов все мы учились по "одним учебникам".
Что-то я так и не понял, что подразумевается под "иначе".
Кейс, который описан в сообщении — возможность комментировать "части" одной команды языка (statement). Но ведь современные языки это позволяют. Если выражение становится сложным — то разработчик вводит дополнительные переменные. Если код слишком сложный — выделяет код в функции/методы, в другие классы/пакеты. При необходимости, выделенные части комментирует.
И читаемость кода — ведь это не только про комментарии. Например, слишком "вертикальный" код (как представлено в сообщении) может стать слишком длинны (высоким) и его будет сложно читать/воспринимать,
разбиение кода на части позволяет устранить эту проблему. И, наоборот, код в одну строчку тоже трудно читать —
Здравствуйте, wildwind, Вы писали:
W>Есть распространенное мнение, что код, в котором каждая строчка требует комментария (не говоря уже о каждом слове), никуда не годится.
Это сильно упрощённый взгляд.
1. Код не описывает задумку, каждая реализация это лишь некий вариант из множества.
2. Комментарии могут относиться к разным слоям конструкций, о чём я написал в топике.
Для примера архитектурный слой будет выражать способ добавления глобальных конструкций программиста созданных из инструкций языка согласно заданным им правилам. Но ничто не мешает комментировать инструкции как другой слой. Или ещё один слой это функционал, то есть указание, что такая-то часть программы является определённой частью некой фичи.
По большому счёту речь здесь не в том чтобы убедить матёрых программистов делать вот так, а не иначе. Это описание быстрого старта для новичков у которых нет предубеждений. Причём без каких-либо дополнительных инструментов кроме простейшего редактора текста. Да и просто мысль, которую я записал на всякий случай, чтобы не забыть.
И, кстати, раз уж зашла об этом речь, те кто дают советы упускают кое-что очень важное, а именно работу собственного мозга. Представь что человек приходит первый раз в тренажёрный зал, а ему говорят, бери сотню килограмм и тягай. Он такой, но я не могу, все дела. И тогда качок берёт и легко отжимает сотню показывая, что всё правильно, так и надо было делать, пока глупый новичок препирался.
Программисты выдающие советы и считающиеся профессионалами переработали огромное количество кода. Они писали имена на своём родном английском языке. Они писали огромное количество всевозможных реализаций велосипедов. Недостающая часть описаний находится в их мозге. Им не нужны комментарии, когда у них в сознании прокручиваются способы работы алгоритмов.
А теперь берём новичка, который может быть даже профессионал, но в другой области программирования. Я уже много раз писал и ещё раз напишу, для исполнения кода достаточно компьютера, но для изменения кода нужно сознание программиста. Код сам себя не напишет.
Есть традиционная фантазия про Васю Пупкина развлекающегося с бабами на пляже, когда рядом лежит ноутбук и используя нейросеть делает за него работу. В противовес этого для понимания нужно понимать, и чем глубже понимание, тем лучше. Вопрос в том записать ли понимание на внешнем носителе, чтобы потом можно было его оттуда считать или понадеяться, что всё само как-то разрешится.
Здравствуйте, Буравчик, Вы писали:
Б>И читаемость кода — ведь это не только про комментарии. Например, слишком "вертикальный" код (как представлено в сообщении) может стать слишком длинны (высоким) и его будет сложно читать/воспринимать
Попробуй писать код на смартфоне, возможно твоё мнение о том, что вертикальный код это слишком радикально сильно изменится. Суть ведь не в том, вертикальный он или нет, а в том чтобы его прочитать. Взгляни практически на любую социальную сеть, там используется подгружающаяся лента. И миллиарды людей скажут, что это очень удобно.
Скажу даже больше, у людей сознание периодически отключается, именно поэтому так ценится состояние называемое потоком сознания. В моменты отключения люди всё пропускают. А мышление ещё и адаптируется, чтобы видеть что-то, а что-то пропускать. То есть создавая общую картину кода с одной стороны что-то выигрываем, а с другой очень сильно проигрываем.
Здравствуйте, velkin, Вы писали:
SVZ>>Хотелось бы услышать, какую задачу ты пытаешься решить и зачем.
V>На мои статьи такой вопрос был уже не раз. Для понимания возьмём метод от обратного. Будет ли такой код работать?
V>Какую задачу ты или я решаем, когда пишем такой код?
Какой "такой"? Что не так с этим кодом?
Он однострочный? Или на Сях или без комментариев? Или он не должен работать под z/OS в полнолуние?
Ты опять выдал целую статью, но так и не ответил на простой вопрос.
Если статья сводится к вопросу зачем нам комментарии и почему мы их не пишем, то мне нравится объяснение нашего математика:
"Комментарии должны объяснять алгоритм". Я бы расширил это трактование. Комментарии должны отвечать на вопрос "что здесь происходит" (частично эти комментарии можно заменить функциями и переменными с говорящими именами) и "зачем это здесь". Вот последнее т.н."самодокументирующий" код решить не в состоянии, поэтому комментарии писать надо!
Что касается страданий неанглоязычных писателей кода, то во-первых, никто не мешает писать на родном языке. компиляторы С++, к примеру, такое позволяют. Во вторых, это не даст ответа на вопрос "зачем это здесь" (см.выше). Так что мы опять приходим к необходимости писать комментарии.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ты опять выдал целую статью, но так и не ответил на простой вопрос.
Я ответил, просто тебя не устраивает такой ответ. Но вообще всё гораздо проще, я, ты или кто-либо другой или используют, что я описал в статье или нет. Если ты не хочешь это использовать, то и смысла рассуждать особого нет. Лично я это ещё не использовал, пока записал лишь как мысль на будущее.
Пока что нет сексес стори, где благодаря секретной вундер технике программирования дурачок Вася Пупкин превратился в продвинутого хакера взламывающего пентагон с помощью пары консольных команд. А теперь и ты запишись на курсы, где тебя обучат непобедимому стилю оформления кода всего за 99'999 долларов сэшэа.
Здравствуйте, velkin, Вы писали:
V>Пока что нет сексес стори, где благодаря секретной вундер технике программирования дурачок Вася Пупкин превратился в продвинутого хакера взламывающего пентагон с помощью пары консольных команд.
Очевидно потому, что для саксесса необходимо знание предметной области. И тут никакие ухищрения в наборе кода дурачку Васе не помогут.
Попытки изобрести RAD'ы не увенчались успехом. Всё вернулось к старому доброму текстовому редактору.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Очевидно потому, что для саксесса необходимо знание предметной области. И тут никакие ухищрения в наборе кода дурачку Васе не помогут.
Но здесь есть такое явление, как стиль мышления. Предположим Вася Пупкин обучился в начальной школе числам и дальше он решил изучить музыку. Но вот незадача, там надо запоминать какие-то ноты вроде до ре ми фа со ля си.
Потом происходит ещё куча ненужных усложнений. А ведь можно было бы просто пронумеровать клавиши и длину удержания так же задавать числами и не парить людям мозг.
Однако известный композитор Василио Пупкинелло скажет, что всё это чушь. Он с детства учился играть по нотам и это абсолютно идеальная система, которая подходит всем и каждому.
А в итоге на пути мы потеряли огромное количество Васей Пупкиных, которые не смогли. И вот я задаюсь вопросом, это Пупкинелло так гениален, или система образования устроена не через то место.
Шагнув в будущее мы вообще видим, как синтезатор сам подсвечивает клавиши куда нужно нажать. А нужен ли в таком случае человек для исполнения. Для исполнения может быть уже и не так нужен, а для сочинения вполне.
Имеет ли одна форма записи преимущества перед другой? И я скажу однозначно да, имеет, хотя так же зависит от знаний и способностей людей. Но если можно пойти по лёгкому пути, то зачем идти по сложному. Можно записывать ноты с помощью песка на доске, и следить чтобы песок не сдуло ветром и доска не перевернулась, но зачем.
Взять ту же математику, кто придумал все эти символы и почему. Идеальна ли математическая запись. А ведь формулы в коде порой читаются гораздо проще. Почему, к примеру, square root сократили до sqrt.
А если бы это был русский язык, то квадратный корень звучал бы как квкн. И по миру бы потом внедряли квкн, квкн. Собирались бы толпы англоязычных пользователей и с пеной у рта доказывали, что русский язык идеален, а квкн это полностью заслуживающее доверие сокращение.
И самое главное ведь всё понятно, а кому не понятно пусть идут учить русский. Кто-то может даже скажет, что я тут устроил фарс. Но когда мы переворачиваем ситуацию где стандарт это sqrt у людей вдруг становятся серьёзными лица, а сами они превращаются если и не в великих учёных, то как минимум в образованных людей.
Моя не понимать, вот почему я пишу подобные топики. Особенно если вспомнить, что компьютеры работают с нулями и единицами. По крайне мере программистам не нужно думать об электрических зарядах и прочем. Но если за абстракциями не видно реального формата данных, то и понимание затруднено.
О чём главный топик? По сути он об оформлении кода, но он так же и о написании кода и понимании кода. Влияет ли оформление кода на понимание кода? Но я уже привёл пример выше, что Пупкинелло действующий гениальный композитор плевал на бред про то, что можно нумеровать клавиши, а то и вовсе использовать их свечение.
Ему вообще на это класть, все должны играть по классическим нотам, только так они добьются сексеса или умрут пытаясь его достичь. И именно так он будет учить написав учебник или записав свои произведения. А вокруг летают самолёты с пробитыми крыльями и фюзеляжем, зато двигатель и бак не пробиты, следовательно проблема не в них.
Здравствуйте, SkyDance, Вы писали:
SD>Все-таки у большинства экраны в высоту куда меньше, чем в ширину, зачем разбивать одну строку на пять — непонятно.
1. Чтобы можно было комментировать каждый терминал и не терминал.
2. Повысить восприятие сознанием каждого элемента не давая мозгу его пропустить.
Но тут нужно понимать, что хотя программа для компилятора абсолютно та же самая, для человека это совсем не так. Вот если бы тебя с детства учили программировать именно так, то думаю вопросом могло бы быть то, зачем делать что-то иначе. С такими мыслями, что это ведь так неудобно писать команды в одной строке, это невозможно читать, не удаётся сосредоточиться.
Здравствуйте, velkin, Вы писали:
V>2. Повысить восприятие сознанием каждого элемента не давая мозгу его пропустить.
Предлагаю тогда писать так, что "повысить восприятие сознанием каждого элемента не давая мозгу его пропустить"
П // Тут очень важный комментарии про значимость этой буквы и почему с заглавной, и что очень важно, нужно и комментарии так же писать
р // еще один комментарии о том, почему р идет вторым после П и почему это важно
е // дальше сам додумай
д
л
а
г
а
ю
т
о
г
д
а
п
и
с
а
т
ь
V>С такими мыслями, что это ведь так неудобно писать команды в одной строке, это невозможно читать, не удаётся сосредоточиться.
1. Если к какому то коду требуется большое количество комментариев, то уже есть т.н. literate programming, который более менее широко используется например в Haskell. Вообще похоже подобный подход распространен в языках с большой смысловой нагрузкой в пересчете на отдельный символ, где за банальным do может скрываться целый мир
2. Я не хочу ни читать, ни писать код с смартфона
3. Если данный подход повышает читаемость, то почему сама статья написана традиционно? Предлагаю переверстать
Среди того же автоматического форматирования кода из нескольких программ был выбран Artistic Style. На изображении я вижу деобфускацию и опять же это тема тоже не про неё, как и не про автоматическое форматирование кода так как всё придётся делать самим.
Обычное русское слово можно разделить по слогам, а можно по составу. И более того, по слогам слова делятся не однозначно, есть разные варианты. Тоже самое есть и в коде, это то, что я назвал слоями. В одном случае код можно разделить на инструкции языка, это имеет отношение к синтаксису.
В другом случае программист может создавать особые виды собственных конструкций из инструкций самого языка, которые могут относиться к шаблонам проектирования или архитектуре. Ещё один вариант разделить код по функциональному назначению.
У меня есть ранние размышления на эту тему, хотя там всё и примитивнее так как я тогда ещё не вышел за рамки мышления почерпнутого из книг и примеров.
С одной стороны кажется, что описывать все слои конструкций избыточно. Что тот же программист помнит для чего нужны определённые конструкции. Но человеческая память в принципе ненадёжна.
По идее у меня была мысль создать метаданные, которые не меняют исходный код, но позволяют в специальном редакторе рядом отображать дополнительные слои различных описаний.
И вот я подумал, а что если использовать существующие возможности. Да, в комментариях сразу в коде есть огромный минус, с чужим кодом в этом случае без переделки работать не получится.
Но есть и плюсы, с таким кодом можно работать хоть в графическом редакторе, хоть в консольном. Это будет именно что код, который люди пишут, то есть писанина за которую так ратуют известные динозавры кодостроения.
Вывод у них может и другой, а вот предпосылка та же самая. Вроде как программист должен читать код как хороший роман. Но есть большая разница читать ли код с нуля или читать и использовать уже существующие в своей голове знания.
Пока что теория в этом топике не проверена. По идее надо как-то собраться и попробовать создать программу на её основе. Тогда станет понятно насколько она эффективна.
А то пока что я, что другие комментаторы могут судить лишь чисто умозрительно о том сработает это или нет. Скорее я бы назвал этот подход непривычным, если прочесть сотни типичных книг по программированию.
Здравствуйте, velkin, Вы писали:
N>>Уже любой код можно превратить в удобочитаемый:
V>Эта тема о понимании кода посредством его многократного описания. Я когда-то писал про инструменты C++.
Моя мысль в другом. Если прогресс нейросетей будет таким же, как сейчас, то будет БЕЗ РАЗНИЦЫ, как писать код. Ты хочешь в столбик и с комментариями? Условный ChatGPT_Next отформатирует его именно так. Кто-то другой с другим мышлением, знаниями и привычками возьмёт код, попросит отформатировать его в Win32 style with Camel case и будет читать свою версию твоего кода. Ты не читал описание по ссылке? У нейросети уже есть токенизатор и ей не важно, как именно написан код. Можно попросить перевести комментарии на русский. Можно сделать так, чтобы при наведении мыши на строку генерировалось описание того, что там делается и зачем. Это можно вот практически уже сейчас сделать. В будущем можно ожидать, что нейросеть вырастет с условного junior до senior, начнёт меньше ошибаться, глубже анализировать и входить в контекст всего проекта, меньше ошибаться.
не знаю. Где подвох?
