Comments 171
У меня почему-то душа не лежит к комментированию. Пользуясь вашей систематикой, я сразу подростком стал. Максимум комментирования, на который я способен: указание перед функцией данных, необходимых для генерирования документации. Во всех остальных случаях для меня комментарии – хранилище неиспользуемого в данный момент кода.
Скорее всего, бедные те, кто будут после меня, но сам я не испытываю проблем в чтении с листа вменяемого кода.
Скорее всего, бедные те, кто будут после меня, но сам я не испытываю проблем в чтении с листа вменяемого кода.
Ага, аналогично никогда особо не комментил код. Ну, только стрёмные оптимизации разве что, да пометки вроде FIXME, TODO, HACK да функции в общем (и то не все). В основном комментарии — это закомментированный код :) Код должен «читаться» и так. А если не читается, то что-то тут не так.
А это такая природа программиста — пока пишет на текущем уровне *ему* все понятно. Уж лучше бы порой сомневался комментами // I feel it smells but can't imagine better approach
Ну, вот в таких местах я ставлю // FIXME: description how to fix или // HACK: dirty hack to do smth если пока не представляю как по-нормальному сделать.
А насчёт всё понятно — описания классов и методов обычно хватает, или если сложный блок — особенно, если оптимизировано до состояние непонимания — тут да, по-любому надо.
А насчёт всё понятно — описания классов и методов обычно хватает, или если сложный блок — особенно, если оптимизировано до состояние непонимания — тут да, по-любому надо.
Комментированый код существовать не должен. Для этого существуют системы контроля версий.
Понимаете, есть теория, а есть практика. Да, в теории всё замечательно — DCVS вроде git или mercurial… а в реальности — svn. поэтому комментированный код будет. Особенно если идёт разработка вот сейчас — этот коммент будет удален до коммита, но пока — оно проще.
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.» (С) Стив Макконнелл
С такой точки зрения понимание где уместно ставить комментарии иногда достичь легче. :)
С такой точки зрения понимание где уместно ставить комментарии иногда достичь легче. :)
Действительно, разница в восприятии опыта у нас и на Западе различается.
А у нас 5-6 лет опыта — и уже сеньор/тимлид/архитектор.
[...] вдруг читаете в чьем-то резюме слова о “5-6 лет опыта разработки”, то знайте — их нельзя перевести как “опытный”. Это переводится так: чувствующий свою неуязвимость малолетка, с вероятностью 50 на 50 напишет вам кучу дерьма
А у нас 5-6 лет опыта — и уже сеньор/тимлид/архитектор.
UFO just landed and posted this here
Автор, Стив Йегг, вроде как разработчик с опытом лет в 20-25. Он видел появление плюсов, восход Джавы, появление Джаваскрипта как языка, и я лично видел его код в живых открытых проектах. Это не закостеневший зубр, а очень и очень толковый разработчик, быстрый, внимающий трендам. Это не считая того, что известный блоггер.
Что совсем уж редко — он так и не стал одним из этих консультантов.
Так вот. С его колокольни все мы здесь в лучшем случае начинающие :)
Что совсем уж редко — он так и не стал одним из этих консультантов.
Так вот. С его колокольни все мы здесь в лучшем случае начинающие :)
Хватит уже делить на «на запад» и «у нас». И там долбоебов хватает и тут. И у них есть крутые тимлиды и у нас.
А опыт тем более ничего не показывает. Все зависит от того, на сколько была агрессивной среда, в которой развивался специалист. Скажем, если человек попал стажором в Эбби, то за 5-6 лет он вполне может стать тимлидом, а продвинутым кодером будет точно. А вот если он попал в какой-нибудь шараш-монтаж, то возможны варианты.
А опыт тем более ничего не показывает. Все зависит от того, на сколько была агрессивной среда, в которой развивался специалист. Скажем, если человек попал стажором в Эбби, то за 5-6 лет он вполне может стать тимлидом, а продвинутым кодером будет точно. А вот если он попал в какой-нибудь шараш-монтаж, то возможны варианты.
Вопрос еще в том, что именно тут считается опытом…
Вот считается ли опытом участие в школьных олимпиадах по программированию, написание дома всякого софта разной степени бесполезности, обучение в универе по специальности наконец? ;-)
Вот считается ли опытом участие в школьных олимпиадах по программированию, написание дома всякого софта разной степени бесполезности, обучение в универе по специальности наконец? ;-)
Интересно… рад, что не я один люблю экономить на комментариях. А то начальник недавно попросил добавить побольше комментов к коду, дабы последующим было легче, так мне пришлось долго думать где же их впихнуть, так как везде имена функций и переменных говорящие, разве что ветки условных операторов обозначить и не очевидные места алгоритмов. Вообще, как по мне, так хороший код почти не надо комментировать.
А с моделированием главное вовремя остановиться. Я делаю просто: если после добавления классов я смогу забыть о том, что у них внутри — добавляю. Причем добавляю как можно меньше классов, которые полностью описывают какой-то кусок проблемы, но если можно проблему внутри разбить еще раз, будет на каждую подпроблему свой класс. Может правильные подход, может нет, но как-то работает:)
А с моделированием главное вовремя остановиться. Я делаю просто: если после добавления классов я смогу забыть о том, что у них внутри — добавляю. Причем добавляю как можно меньше классов, которые полностью описывают какой-то кусок проблемы, но если можно проблему внутри разбить еще раз, будет на каждую подпроблему свой класс. Может правильные подход, может нет, но как-то работает:)
«все правильно сделал»
en.wikipedia.org/wiki/SOLID_(object-oriented_design)
en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Don't try to model everything!Вот об это я уже спотыкался.
Для контраста, вот код, который я пишу сегодня:
…
В каком бы ужасе я находился, если бы я увидел этот код 20 лет назад.
Почему-то кажется, что в ужас нужно бы придти и сейчас… Код нужно писать для людей, а не для машин.
20 лет назад я не писал комментариев, так как 1) объемы носителей были малы и комментарии жрали драгоценное место и 2) я и так помнил наизусть все свои алгоритмы, а другим до них не было дела :)
Сейчас я не пишу комментариев, так как 1) я научился использовать простые алгоритмы и писать простые программы (не брезгуя использованием готовых библиотек) и 2) программы для меня — инструмент, часто одноразовый, нет нужды комментировать или даже просто хранить их. Надо будет — новые напишу, лучше прежних :)
Сейчас я не пишу комментариев, так как 1) я научился использовать простые алгоритмы и писать простые программы (не брезгуя использованием готовых библиотек) и 2) программы для меня — инструмент, часто одноразовый, нет нужды комментировать или даже просто хранить их. Надо будет — новые напишу, лучше прежних :)
Новичок, который комментирует каждую строчку хотя бы так — это уже идельный новичок. Обычно новички свой код вообще не комментируют.
UFO just landed and posted this here
Гоблин-аргументация: выдумать в статье подростка (который по психологическим причинам будет больше говорить об авторе, чем об оппоненте) и спорить с ним. Подросток при этом проигрывает, потому что подросток, ну это же очевидно, что тот, кто ужаснулся от кода автора — нуб, то ли дело блоггер-автор.
никогда не понимал чем люядм которые считают себя «папками или гуру» мешают развернутые коментарии.
Да я иногда например тоже коментирую каждую строку, и даже $i++ коментирую, никогда не понимал чем это плохо?
Да я иногда например тоже коментирую каждую строку, и даже $i++ коментирую, никогда не понимал чем это плохо?
Например — сложный алгоритм. Предпочтительнее видеть его на одном экране, чем размазанным на многих.
ну в сложном алгоритме имхо разобратся быстрее и проще если он отлично закоментирован, я конечно понимаю что хороший код не нуждается в коментариях но не всех у нас iq выше 120
Конечно все зависит от сложности алгоритма, но лично мне обычно коменты мешают разбираться в алгоритме. Отдельный случай (но это уже конечно клиника) — когда коменты не соответствуют коду.
Это не такая уж клиника, как может показаться.
Не каждый программист поддерживает чужие комментарии. Да и свои не всегда.
Поэтому, IMHO, лучше следовать мантре «Читай код».
Не каждый программист поддерживает чужие комментарии. Да и свои не всегда.
Поэтому, IMHO, лучше следовать мантре «Читай код».
Я же это и имел в виду — imho, обычно комментарии нисколько не помогают разобраться в коде.
> Не каждый программист поддерживает чужие комментарии. Да и свои не всегда.
Это уже вопрос культуры. Раз уж начал комментировать код — будь добр поддерживать эти комментарии в актуальном состоянии. Иначе это просто свинство по отношению к коллегам.
P.S. За статью спасибо, прочитал с большим удовольствием.
> Не каждый программист поддерживает чужие комментарии. Да и свои не всегда.
Это уже вопрос культуры. Раз уж начал комментировать код — будь добр поддерживать эти комментарии в актуальном состоянии. Иначе это просто свинство по отношению к коллегам.
P.S. За статью спасибо, прочитал с большим удовольствием.
Хозяйке на заметку: если ваш редактор не позволяет свернуть комментарии и блоки кода, выкиньте его.
покажите мне редактор, который сворачивает // комментарии, пожалуйста
Ой, простите, неверно понял ваш комментарий
Можете показать пример(картинку) где в Notepad++ сворачивается комментарий вида "//"? Я не вижу там такой возможности. Другими редакторами не обладаю, поэтому и проверить не могу.
IntelliJ IDEA
Вот ещё! Вместо того, чтобы просто видеть то, что нужно я буду комментарии сворачивать-разворачивать.
Возможность сворачивать — это фича. Она, как и наличие коментариев (методанных), не влияет на качество кода. Мне нравится мысль Фаулера: если для объяснения кода нужен коментарий попробуйте отрефакторить его (почти дословно).
С точки зрения автора:
1. Это дает возможность писать непонятный код и заставляет вести две параллельных ветки: литературную и на языке программирования.
2. Очень редко это действительно нужно. Например i — это что такое вообще? Может someIdx было бы лучше и избавило бы от комментария.
С другой точки зрения:
3. Понимать, что этот код делает становится сложным: если я открыл ваш код, я или пытаюсь узнать, что функция делает и абстрагироваться от реализации (тогда достаточно коммента в начале), или пытаюсь высмотреть у вас там ошибку, и построчные комментарии конечно же об ошибке мне ничего не скажут.
4. Намного проще становится делать хаки и прочее — а чего, комментарий ведь выше описывает, что делается. Если бы комментариев было мало, откомментированный хак был бы заметнее.
1. Это дает возможность писать непонятный код и заставляет вести две параллельных ветки: литературную и на языке программирования.
2. Очень редко это действительно нужно. Например i — это что такое вообще? Может someIdx было бы лучше и избавило бы от комментария.
С другой точки зрения:
3. Понимать, что этот код делает становится сложным: если я открыл ваш код, я или пытаюсь узнать, что функция делает и абстрагироваться от реализации (тогда достаточно коммента в начале), или пытаюсь высмотреть у вас там ошибку, и построчные комментарии конечно же об ошибке мне ничего не скажут.
4. Намного проще становится делать хаки и прочее — а чего, комментарий ведь выше описывает, что делается. Если бы комментариев было мало, откомментированный хак был бы заметнее.
Если в коде используются понятные имена функций и переменных, то простые алгоритмы просто нет смысла комментировать, код уже содержит всю информацию.
Например:
i++; //увеличиваем количество клиентов
Можно написать как:
ClientsNumber++; //увеличиваем количество клиентов
В первом случае мы описываем, что же мы делаем в комментах, во втором же случае мы пишем два раза одно и то же.
Например:
i++; //увеличиваем количество клиентов
Можно написать как:
ClientsNumber++; //увеличиваем количество клиентов
В первом случае мы описываем, что же мы делаем в комментах, во втором же случае мы пишем два раза одно и то же.
Писать самодокументируемый код очень удобно и полезно, но полностью от комментариев отказываться тоже глупо. Я например, стараюсь разбивать код на некие логические блоки длиной 4-10 строк и разделять их абзацами, и перед каждым таким блоком стараюсь вставить однострочный комментарий описывающий что в нем делается. Так намного проще даже мне самому ориентироваться в коде. Ну а внутри блока, по именам переменных и функций и так все понятно.
Месяц назад, мне захотелось в первые за год написать комментарий на строку кода (внутри метода). Я ее написал, пошел дальше. Подумал, вернулся и разделил строку на две или три. Комментарий удалил. Завтра, если я ее увижу и подумаю, что она все равно сложная — еще чего-нибудь сделаю.
Абзацы — надо делить на отдельные функции с внятными именами.
Абзацы — надо делить на отдельные функции с внятными именами.
Я бы сказал, что комментарии должны быть высокоуровневыми, т.е. надо комментировать, что происходит глобально, а не как это реализовано в каждой строке. Хотя при правильном разделении на функции и классы в этом тоже исчезает смысл. d7k уже ответил, что абзацы можно выделить в функции и результат будет тот же. Но если не выносить все в функции, тогда комментарии необходимы. А до какой степени все выносить в отдельные функции и классы — это уже другой вопрос и я не думаю, что есть универсальное решение, которое всем понравится.
А до какой степени все выносить в отдельные функции и классы — это уже другой вопрос
Используем давно известный принцип единой ответственности. Если есть трудности с определением, выполняет ли предложенный код одну или несколько задач, советую прочитать «Чистый код».
Только проблема остается все та же, как определить простейшую задачу, которую не надо разбивать дальше?
Т.е. есть например есть игра в которой надо нарисовать персонажа. Что есть простейшая задача, которую не надо разбивать на подзадачи? Нарисовать персонажа? Нарисовать руку/ногу? Нарисовать отдельно тело отдельно одежду? Нарисовать поверхность? Нарисовать треугольник?
Код, который рисует персонажа отвечает только за рисование персонажа, но делает много разного для этого. Если же все дробить на мельчайшие части, то объем кода сильно растет и его поддержка занимает больше времени.
Т.е. есть например есть игра в которой надо нарисовать персонажа. Что есть простейшая задача, которую не надо разбивать на подзадачи? Нарисовать персонажа? Нарисовать руку/ногу? Нарисовать отдельно тело отдельно одежду? Нарисовать поверхность? Нарисовать треугольник?
Код, который рисует персонажа отвечает только за рисование персонажа, но делает много разного для этого. Если же все дробить на мельчайшие части, то объем кода сильно растет и его поддержка занимает больше времени.
Разберу случай с персонажем:
Как разбивать (и разбивать ли) внутри данных методов — сильно зависит от того, какой код будет получаться в итоге. Правила, которыми имеет смысл руководствоваться, давно известны и написаны, например, у Макконнелла.
- Работа с движком — инкапсулируется в отдельный класс>
- Получение простейших компонентов, таких как линии, плоскости, примитивы — все в отдельный класс, на каждый компонент — отдельный метод.
- Элементарные преобразования — в отдельный класс, на каждое преобразование — отдельный метод.
- Различные сложные компоненты и преобразования также по отдельным классам.
- Рисование каждой части тела — в отдельный метод. Возможно, сложную часть тела типа «рука» имеет смысл разбить на зап. части, по методу на каждую.
- Рисование первонажа — отдельный метод.
Как разбивать (и разбивать ли) внутри данных методов — сильно зависит от того, какой код будет получаться в итоге. Правила, которыми имеет смысл руководствоваться, давно известны и написаны, например, у Макконнелла.
Ваш подход — это один из многих вариантов. Как альтернативу можно привести по классу на каждый элемент и их иерархия: персонаж содержит руки/ноги/etc и свое относительное расположение в сцене, руки/ноги/etc содержат внутри геометрию и свои положения в сцене, геометрия содержит треугольники и их положение. Тогда чтобы нарисовать надо вызвать метод персонажа, а все остальное иерархически будет происходить внутри. Так что все далеко не так однозначно как кажется:)
Да Вы и сами говорите:
То есть нельзя точно сказать, как разбивать тот или иной код. Один человек сделает так, другой эдак. Правила то есть, но это скорее не алгоритмы с точным результатом, а эвристические правила, которые подсказывают куда двигаться.
Да Вы и сами говорите:
«Как разбивать (и разбивать ли) внутри данных методов — сильно зависит от того, какой код будет получаться в итоге.»
То есть нельзя точно сказать, как разбивать тот или иной код. Один человек сделает так, другой эдак. Правила то есть, но это скорее не алгоритмы с точным результатом, а эвристические правила, которые подсказывают куда двигаться.
«Рисование персонажа» — это одна ответственность, да. Поэтому не надо туда сваливать рисование треугольника — это уже другая ответственность :-) Понимаешь принцип?
Если же все дробить на мельчайшие части, то объем кода сильно растет и его поддержка занимает больше времени
Не согласен. Необходимо просто дробить таким образом, чтобы взгляда на имя метода и набор параметров было достаточно для того, чтобы вспомнить, что оно делает. Тогда навигация до нужного места происходит интуитивно, без лишнего обдумывания.
Хотел поспорить сначала, потом подумал, может мы оба правы:)
Подход с идеальным разбиванием на части может работать (да и работает) только при условии, что разработчик заранее знает какие компоненты будут в финальной версии. Если же, эти самые компоненты меняются по ходу дела по причине изменений в ТЗ, отсутствия опыта в момент начала проекта, обнаружения большой и страшной ошибки в начальной архитектуре (часто сделанной хз кем как и когда), итд итп, то правильный подход с разбиением на множество классов только добавляет проблем, так как менять приходится гораздо больше кода.
В идеальном случае, когда есть знания предметной области и время на прототипы, оно должно работать сразу и хорошо, но мне слишком уж много раз попадались не идеальные случаи.
И еще этот метод нельзя применять при написании первой исследовательского кода, это уже мой личный опыт. Я честно пытался разбивать все на части красиво, но в результате слишком много времени тратилось на поддержку. Видимо поэтому я и против того, чтобы всегда делать все правильно и красиво:)
Подход с идеальным разбиванием на части может работать (да и работает) только при условии, что разработчик заранее знает какие компоненты будут в финальной версии. Если же, эти самые компоненты меняются по ходу дела по причине изменений в ТЗ, отсутствия опыта в момент начала проекта, обнаружения большой и страшной ошибки в начальной архитектуре (часто сделанной хз кем как и когда), итд итп, то правильный подход с разбиением на множество классов только добавляет проблем, так как менять приходится гораздо больше кода.
В идеальном случае, когда есть знания предметной области и время на прототипы, оно должно работать сразу и хорошо, но мне слишком уж много раз попадались не идеальные случаи.
И еще этот метод нельзя применять при написании первой исследовательского кода, это уже мой личный опыт. Я честно пытался разбивать все на части красиво, но в результате слишком много времени тратилось на поддержку. Видимо поэтому я и против того, чтобы всегда делать все правильно и красиво:)
Во втором случае код говорит увеличить номер клиента (какой именно номер ??), а коментарий говорит увеличить кол-во.
numberOfClients++; — так пожалуй более честно
numberOfClients++; — так пожалуй более честно
Это мешает читать код.
Золотые слова:
Код нужно писать для людей, а не для машин
Код нужно писать для людей, а не для машин
у мну обычно дилемма. либо описать очень подробно каждую строчку, либо не писать вовсе. ибо я считаю свой код понятным итак, и тогда либо комменты нужны полным профанам, либо не нужны вовсе. ну и еще я не люблю переменных a, b, c и т.д. максимум что я использую, это i для for циклов.
кто я? подросток? нуб? еще кто похуже?
кто я? подросток? нуб? еще кто похуже?
Еще ни разу не видел, чтобы кто-нибудь написал о комментировании лучше Макконнелла. И эта статья — не исключение.
>> Боже, линии не отделены друг от друга! Некоторые из этих линий даже не прокомментированы!
Боже, линии! (хотя может переводчик не программист)
>> Если быть честным, то я согласен, это некрасивая функция.
Если быть честным, то привел бы автор пример своей красивой функции, чтобы видно было, как он пишет сейчас. А то может он и не «повзрослел» вовсе.
Боже, линии! (хотя может переводчик не программист)
>> Если быть честным, то я согласен, это некрасивая функция.
Если быть честным, то привел бы автор пример своей красивой функции, чтобы видно было, как он пишет сейчас. А то может он и не «повзрослел» вовсе.
В кружке информатики при Дворце Пионеров, а потом и в университете видел очень много нубского кода(не считая своего). Комменты отсутствовали напрочь.
Было такое. Одно время я доводил себя до состояния, когда каждая фукнция должна была занимать не более 20 строчек и иметь не менее 5 строк комментариев, а пустыми строками она отделялась от соседей так, чтобы на экране была только одна функция.
Кстати, я так и не стал хорошим программистом (хотя способен кодить на нескольких языках) и стал сисадмином (для которого подобная обстоятельность — скорее благо, чем зло).
И, кстати, потому мне тяжело писать на питоне — там слишком много нужно программировать, и слишком мало выполнять всяких простых ритуальных движений, вроде проверки успешности выделения памяти, организации списка и т.д.
Кстати, я так и не стал хорошим программистом (хотя способен кодить на нескольких языках) и стал сисадмином (для которого подобная обстоятельность — скорее благо, чем зло).
И, кстати, потому мне тяжело писать на питоне — там слишком много нужно программировать, и слишком мало выполнять всяких простых ритуальных движений, вроде проверки успешности выделения памяти, организации списка и т.д.
Хорошо, если новичок комментирует хотябы каждую пятую строчку. А то обычно они вообще не комментируют код.
Между писаниной простого плоского кода, который растягивается на очень длинные листинги, и писаниной высоко-сложного кода, который растягивается на очень длинные листинги, где-то в районе посреди есть оптимальная позиция, имеющая минимальный листинг.
Тут я с автором совершенно согласен. Если я неверно понял его предупреждение не писать плоский код. ;-)
Читать Властелина Колец, где для понимания текста читатель обязан сначала прочесть 50 страничную энциклопедию, прямо-таки алфавитно упорядоченную, я отказался. И у меня ушло 60 минут разобраться в короткой фразе «рецессивный аллель влияент на фенотип, только если генотип гомозиготен», которая читается за 10 секунд.
То же самое когда определяется сложная модель — вводится гигантский «prerequisites» для чтения. В конце концов задача решается, конечно же, в одну строчку, но… Длина листинга же.
Плоский код, с другой стороны, сродни фортрану или ассемблеру. Длинные простыни примитивных операций во время чтения которых ты пытаешься перевести их на термины задачи, но забываешь с чего дело началось 5 страниц назад. Почти обязательно он будет в стиле «спагетти». Каждая отдельная строка понятна, но общая картина в голову не укладывается. Длина листинга же…
При этом я не имею в виду obfuscated c programming, где используются трюки навроде «while (*d++ = *s++);», (который объясняются в K&R на трёх страницах). Это третья шиза, но она встречается гораздо, гораздо реже.
Сам на С++ пишу «в стиле С», так как практические задачи универсальных абстракций не требуют. И комментирую одной-двумя строками следующий блок в 5-10 строк.
Тут я с автором совершенно согласен. Если я неверно понял его предупреждение не писать плоский код. ;-)
Читать Властелина Колец, где для понимания текста читатель обязан сначала прочесть 50 страничную энциклопедию, прямо-таки алфавитно упорядоченную, я отказался. И у меня ушло 60 минут разобраться в короткой фразе «рецессивный аллель влияент на фенотип, только если генотип гомозиготен», которая читается за 10 секунд.
То же самое когда определяется сложная модель — вводится гигантский «prerequisites» для чтения. В конце концов задача решается, конечно же, в одну строчку, но… Длина листинга же.
Плоский код, с другой стороны, сродни фортрану или ассемблеру. Длинные простыни примитивных операций во время чтения которых ты пытаешься перевести их на термины задачи, но забываешь с чего дело началось 5 страниц назад. Почти обязательно он будет в стиле «спагетти». Каждая отдельная строка понятна, но общая картина в голову не укладывается. Длина листинга же…
При этом я не имею в виду obfuscated c programming, где используются трюки навроде «while (*d++ = *s++);», (который объясняются в K&R на трёх страницах). Это третья шиза, но она встречается гораздо, гораздо реже.
Сам на С++ пишу «в стиле С», так как практические задачи универсальных абстракций не требуют. И комментирую одной-двумя строками следующий блок в 5-10 строк.
Ваша фраза про «рецессивный аллель» мне напомнила о динамичесих и функциональных языках.
Будучи студентом-биоинформатиком, смысл я понял за пару секунд, но это мне напомнило некоторых коллег-сишников, которые долго-долго пытались понять штуки вроде map{}.reduce{} в Ruby или мои собственные попытки вникнуть в таинства концевой рекурсии в Scheme.
Скорость и легкость понимания кода все же очень сильно зависит от опыта.
Будучи студентом-биоинформатиком, смысл я понял за пару секунд, но это мне напомнило некоторых коллег-сишников, которые долго-долго пытались понять штуки вроде map{}.reduce{} в Ruby или мои собственные попытки вникнуть в таинства концевой рекурсии в Scheme.
Скорость и легкость понимания кода все же очень сильно зависит от опыта.
«Читать Властелина Колец, где для понимания текста читатель обязан сначала прочесть 50 страничную энциклопедию, прямо-таки алфавитно упорядоченную, я отказался»
Есть мнение, что вы что-то делаете не так. ВК прекрасно читается и без этого.
Есть мнение, что вы что-то делаете не так. ВК прекрасно читается и без этого.
Эпичный троллинг. Напомнило моего первого начальника который 30 лет писал на ассемблере и утверждал что классы (в С++) — это баги, и писать надо только C-style. Правда он, в отличие от автора текста, не троллил а просто дурак был (чем погубил не один проект)
И да, про комментарии. В них, как было обмусолено тысячу раз, нужно писать что, а не как. Тогда и описаний на полэкрана не будет.
И да, про комментарии. В них, как было обмусолено тысячу раз, нужно писать что, а не как. Тогда и описаний на полэкрана не будет.
Классы — штуки реально хорошие, когда пишешь либу.
Ещё лучше, когда берёшь чужую тщательно продуманную — ведь VCL толкнул Delphi очень далеко вперёд.
Но стоит задуматься — нужна ли в этой конкретной сегодня программе эта моя самописная либа. И что в неё таки правильно оформить.
Всегда можно дойти до маразма
main() {MyClass.SolveTheProblem();return;};
но надо ли? действительно ли цикл жизни моего софта предполагает 10-летнее использование с пятикратным ростом функционала, или 2-3 года и две модификации хватит?
Ещё лучше, когда берёшь чужую тщательно продуманную — ведь VCL толкнул Delphi очень далеко вперёд.
Но стоит задуматься — нужна ли в этой конкретной сегодня программе эта моя самописная либа. И что в неё таки правильно оформить.
Всегда можно дойти до маразма
main() {MyClass.SolveTheProblem();return;};
но надо ли? действительно ли цикл жизни моего софта предполагает 10-летнее использование с пятикратным ростом функционала, или 2-3 года и две модификации хватит?
Это «что» лучше тоже писать в коде ) например, в именах функций, методов, полей и классов.
Меня больше зацепили в статье не комментарии, за которые ухватились куча народу, а само понятие «метаинформации». Т.е. самодокументирующий код пишут нубы? Думаю, с автора (не статьи, а исходника) таки нужно взять листинг его собственного кода, и посмотреть, кто он такой.
Меня больше зацепили в статье не комментарии, за которые ухватились куча народу, а само понятие «метаинформации». Т.е. самодокументирующий код пишут нубы? Думаю, с автора (не статьи, а исходника) таки нужно взять листинг его собственного кода, и посмотреть, кто он такой.
Дочитал до середины, надоело, прочитал «вывод», но так и не понял, что это. Высер старпера-эксперта, троллинг или что-то третье?
Лол, я бы посмотрел на то, как выглядит поддержка оооогромной кучи динамического кода. Точнее, я уже насмотрелся, конечно, но посмотрел бы ещё :D люблю острые ощущения
Я таких комментариев не встречал ни разу.
Но думаю что лучше уж будут такие комментарии у говнокодеров, т.к. из них можно хоть понять ход мыслей, понять зачем здесь этот кусок дерьма.
Но думаю что лучше уж будут такие комментарии у говнокодеров, т.к. из них можно хоть понять ход мыслей, понять зачем здесь этот кусок дерьма.
Я при написании комментариев руководствуюсь следующим принципом: пойму ли я, что делает код, открой я его месяца через два? От этого и длина комментариев зависит.
Раньше мне тоже очень нравились конструкции вида «сделать офигенно» и мемуары в комментариях, но сейчас я понимаю, что все это на самом деле не несет в себе никакой полезности, а порой и смысла.
Раньше мне тоже очень нравились конструкции вида «сделать офигенно» и мемуары в комментариях, но сейчас я понимаю, что все это на самом деле не несет в себе никакой полезности, а порой и смысла.
По мне так вопрос о комментариях очень второстепенный в статье. Это так для затравки. Читал 1 раз и вскользь т.к. много букв. Не все понял что хотел автор. Замечал противоречия в его рассуждениях, но не стал возвращаться назад чтобы их уточнять, мне это было не интересно было. Автор говорит про модели очень абстратно и неконкретно как будто если он скажет что-то конкретное, то придется отвечать на гору каверзных вопросов и спорить. Вобщем эта статья требует структуризации, конкретных тезисов, укорачивания и избавления от кучи ненужных метаданных иначе ее не захотят понимать в виду объема, неконкретности, расплывчивости формулировок.
А когда я был студентом, то у меня в начале некоторых ассемблерных листингов стояли три строки хокку по мнемоническим соображениям.
Ухаха, посмотрел бы я на автора, который бы стал разбираться с унаследованным кодом хотя бы мегабайта в два исходников на каком-либо языке с динамической типизацией )) Без Find Usages, без навигации по коду.
Откуда столько шума? Вроде давно аксиома: комментировать надо то, что из кода не явно, а это случается довольно редко. Комментирование для автоматической документации, при генерации шаблона (любая IDE или простой редактор это умеет делать) мозг не грузит и времени не отнимает.
Тонны комента, для пары строк кода, зло. Комменты должны дополнять, а не становиться отдельной сущностью, на которой можно сломать мозг, пытаясь их соотнести с кодом.
Что касается моделирования, думаю любой опытный программист подходит к этому процессу итеративно, так что никаких проблем со «сверхмоделированием» для них нет.
Тонны комента, для пары строк кода, зло. Комменты должны дополнять, а не становиться отдельной сущностью, на которой можно сломать мозг, пытаясь их соотнести с кодом.
Что касается моделирования, думаю любой опытный программист подходит к этому процессу итеративно, так что никаких проблем со «сверхмоделированием» для них нет.
> Вроде давно аксиома: комментировать надо то, что из кода не явно
Я бы еще добавил, что однострочный комментарий полезен перед блоком который выполняет некое законченное действие. Например, десяток строчек, который получают значение используемое далее, неплохо снабдить комментарием типа: «Получаем значение X». Тогда, при просмотре кода, не нужно просматривать этот блок вообще — по комментарию будет ясно что здесь «родилось» Х и можно смотреть дальше. Это ускоряет изучение кода и не вынуждает погрязать в несущественных деталях модуля
Я бы еще добавил, что однострочный комментарий полезен перед блоком который выполняет некое законченное действие. Например, десяток строчек, который получают значение используемое далее, неплохо снабдить комментарием типа: «Получаем значение X». Тогда, при просмотре кода, не нужно просматривать этот блок вообще — по комментарию будет ясно что здесь «родилось» Х и можно смотреть дальше. Это ускоряет изучение кода и не вынуждает погрязать в несущественных деталях модуля
По-моему у американцев какая-то страсть по пустякам воду лить. прочитал только треть, дальше зевать начал. Какая-то сплошная рефлексия
Ужас, как много букв… смысл статьи, что в комменты нужно писать только самое важное?
Где-то я видел, что коментарий в коде должен отвечать на вопрос «зачем?», но не на вопрос «как?». Последнее должно быть понятно из кода. Моделирование не есть плохо. Нужно лишь, чтобы модель не была вселенски универсальной и не выходила из области задачи.
Автор упускает огромную группу людей — либюзеров, которые для достижения результата не заморачиваются, а подключают либу мегов на N-цать, зато в которой есть Tuple2 для возвращения двух значений функции. Они не изобретают, они пользуются чужими изобретениями и паттернами. Таких большинство.
Вторыми по списку идут быдлокодеры. Они всегда решают задачу влоб теми нехитрыми средствами, которые осилили овладеть. В итоге код дублируется, триплируется, функционал смешивается в кашу, и наступает момент, когда любое изменение влечет за собой гору отвалившегося функционала. И чтобы изменить что-то, надо перелопатить код в 10 местах.
Третья активно нарастающая группа — это быдлотестеры. Они не понимают для чего нужны тесты, но знают, что TDD — это модно. Поэтому пишут тесты абсолютно для всего — даже геттеров и сеттеров.
А изобретателей-«нубов» на самом деле осталось очень мало. Честь им и хвала! Все должны через это пройти.
P.S. Есть и психологическое объяснение статьи: когда автор был нубом, он работал за идею (интерес). Когда же он повзрослел, он тупо стал работать за деньги. Поэтому все идейные вещи ему стали казаться глупыми: платят не за идею, а за результат, поэтому че напрягаться?
Автор упускает огромную группу людей — либюзеров, которые для достижения результата не заморачиваются, а подключают либу мегов на N-цать, зато в которой есть Tuple2 для возвращения двух значений функции. Они не изобретают, они пользуются чужими изобретениями и паттернами. Таких большинство.
Вторыми по списку идут быдлокодеры. Они всегда решают задачу влоб теми нехитрыми средствами, которые осилили овладеть. В итоге код дублируется, триплируется, функционал смешивается в кашу, и наступает момент, когда любое изменение влечет за собой гору отвалившегося функционала. И чтобы изменить что-то, надо перелопатить код в 10 местах.
Третья активно нарастающая группа — это быдлотестеры. Они не понимают для чего нужны тесты, но знают, что TDD — это модно. Поэтому пишут тесты абсолютно для всего — даже геттеров и сеттеров.
А изобретателей-«нубов» на самом деле осталось очень мало. Честь им и хвала! Все должны через это пройти.
P.S. Есть и психологическое объяснение статьи: когда автор был нубом, он работал за идею (интерес). Когда же он повзрослел, он тупо стал работать за деньги. Поэтому все идейные вещи ему стали казаться глупыми: платят не за идею, а за результат, поэтому че напрягаться?
Узнал себя сразу в двух группах по названиям и описаниям, но как-то то, что пишу тесты для геттеров и сеттеров помогает не дублировать и триплировать код, не устраивать кашу и изменения обычно проходят без перелопачивания кода в 10 местах, а если и требуются в 10 местах, то тесты эти места показывают, включая геттеры и сеттеры.
Автору статьи незачет за агрессивность, завышенное самомнение и много спорных высказываний.
Если обильно комментировать, достаточно сложно держать комменты в актуальном состоянии. Особенно когда взахлеб пишешь код, не отвлекаясь ни на что.
плюсанул за старательность — это ж сколько времени потрачено на статью!!! Но дочитал только до середины.
Мне кажется, есть золотая середина, когда код получается и кратким, и откомментированным и понятным. Ближе всего, к этому, мне кажется, позиция Макконнелла:
1. Короткие методы.
2. Комментарии к публичным методам и их параметрам.
3. Принцип «если код плохо читаем — его нужно отрефакторить, а не писать комментарии».
Вот и всё.
1. Короткие методы.
2. Комментарии к публичным методам и их параметрам.
3. Принцип «если код плохо читаем — его нужно отрефакторить, а не писать комментарии».
Вот и всё.
2. Комментарии к публичным методам и их параметрам.
Под публичными здесь нужно понимать не public-методы, а внешний интерфейс системы или модуля. Внутренних интерфейсов, как правило, слишком много для того, чтобы тратить время на поддержание их в чистоте и порядке.
1. Короткие методы.
У Макконнелла, помнится, было написано наоборот :-) Приводятся штук 10 практик по написанию хороших методов, а потом сказано, что предложенных выше методик вполне достаточно, и требование о длине методов излишне.
И я с ним согласен.
UFO just landed and posted this here
Зря вы так про Стива Йегге — парень писал очень правильные вещи в очень правильное время. Статья очень старая и написана так, чтобы подтолкнуть людей. И да, она написана для новичков, для тех из них, кто с одной стороны достаточно интересуется мнениями в профессии, чтобы на них можно было повлиять, а с другой стороны — достаточно способных, чтобы под влиянием статей они изменились к лучшему и росли как профессионалы. Да, Стив перегибает палку, но считайте это художественным приемом :)
Стив делал правильное дело, и не важно, что умудренные опытом люди смотрят на его тексты снисходительно или скептически — на них такие статьи уже не действуют, да и они им и не предназначены.
Стив делал правильное дело, и не важно, что умудренные опытом люди смотрят на его тексты снисходительно или скептически — на них такие статьи уже не действуют, да и они им и не предназначены.
Хорошо мыслите :-) Напомнило притчу.
UFO just landed and posted this here
Такое ощущение, что 90% тех кто отписался выше прочли только верхнюю треть статьи. Ау, люди, статья про метаданные, не про комментарии в коде!
Огромное спасибо за перевод, теперь есть куда тыкать нубов.
Огромное спасибо за перевод, теперь есть куда тыкать нубов.
+1. Статья безумно понравилась. Многие подобные мысли в голове давно крутились.
Иногда работая чувствуешь что закопался в проблеме, а проблема то с нулевым business-value. Чистой воды украшательства кода, создание стройной модели, выправление affecting/effecting coupling чтобы пониже был, ну и прочая фигня. И честно признаться я подобного рода задачи возводил в абсолют, мол без хорошей архитектуры проект загнётся и порастёт #овном.
В то же время на проекте был дядька(голандец, senior по западным меркам), который просто делал что нужно. В большинстве случаев максимально просто, максимально быстро, когда ему становилось некомфортно с этим кодом — не задумываяся рефакторил в тот вид что нужно. Buisiness value который он привносил — был огромным, и при этом когда/если позже всплывали недостатки его решений(не баги, а именно архитектурные компромиссы которые не оправдались) — он моментально правил для соответствия текущим требованиям проекта. Он не писал полотна коментов, не писал слишком примитивного когда для идиотов.
И после этой статьи мне все потуги с созданием хорошей архитектуры, и слежением за красотой кода кажутся абсолютной чепухой. И наверное senior это не тот кто 3 года на каком нибудь Epam кнопки нажимал, и выучил 5 паттернов и сует их везде. А тот кто создаст продукт быстро и без онанирования на красоту кода в случае когда она не мешает результату
Иногда работая чувствуешь что закопался в проблеме, а проблема то с нулевым business-value. Чистой воды украшательства кода, создание стройной модели, выправление affecting/effecting coupling чтобы пониже был, ну и прочая фигня. И честно признаться я подобного рода задачи возводил в абсолют, мол без хорошей архитектуры проект загнётся и порастёт #овном.
В то же время на проекте был дядька(голандец, senior по западным меркам), который просто делал что нужно. В большинстве случаев максимально просто, максимально быстро, когда ему становилось некомфортно с этим кодом — не задумываяся рефакторил в тот вид что нужно. Buisiness value который он привносил — был огромным, и при этом когда/если позже всплывали недостатки его решений(не баги, а именно архитектурные компромиссы которые не оправдались) — он моментально правил для соответствия текущим требованиям проекта. Он не писал полотна коментов, не писал слишком примитивного когда для идиотов.
И после этой статьи мне все потуги с созданием хорошей архитектуры, и слежением за красотой кода кажутся абсолютной чепухой. И наверное senior это не тот кто 3 года на каком нибудь Epam кнопки нажимал, и выучил 5 паттернов и сует их везде. А тот кто создаст продукт быстро и без онанирования на красоту кода в случае когда она не мешает результату
Не понимаю почему люди выше обсуждают в основном комментирование. Автор затронул гораздо более обширную и интересную тему.
Осилил только половину текста… Не очень понятно почему так много написано. Очччень много повторов и водички.
Есть труд. Есть результаты труда. Результаты я всегда представляю в виде готового кода и документации на него. В коде описан процесс. В документации — смысл этого процесса и его алгоритмика. Комментарии в коде носят обычно только характер пояснения к документации, т.е. как бы выполняют синхронизирующую роль.
При таком подходе главное — выбрать описываемый «кубик», т.е. ту минимальную часть труда, которую надо так бюрократизировать. Не описывать каждое присвоение, но и не очень крупный процесс )
Есть труд. Есть результаты труда. Результаты я всегда представляю в виде готового кода и документации на него. В коде описан процесс. В документации — смысл этого процесса и его алгоритмика. Комментарии в коде носят обычно только характер пояснения к документации, т.е. как бы выполняют синхронизирующую роль.
При таком подходе главное — выбрать описываемый «кубик», т.е. ту минимальную часть труда, которую надо так бюрократизировать. Не описывать каждое присвоение, но и не очень крупный процесс )
При таком подходе главное — выбрать описываемый «кубик», т.е. ту минимальную часть труда, которую надо так бюрократизировать. Не описывать каждое присвоение, но и не очень крупный процесс )
*doc к функциям/процедурам/методам, если придерживаться правила, что они небольшие? :)
Именно)
В *doc же можно засунуть математику, графики и прочую обосновательную ерунду. Я как-то обошелся парой строчек текста и четырмя диаграммами, т.к. из них предельно ясно понятно что, зачем и куда. Пояснения должны быть предельно понятным.
Согласен, что нет ничего хуже такого засилья комментариев, когда разработчик передавая код говорит, что документация абсолютно не потребуется (типа там все есть), т.к. «там все понятно расписано». Начинаешь смотреть, а так как картины в целом еще нет, образуется каша в голове.
Кстати, автор мог бы упомянуть, что комментарии бывают трех видов:
— для себя (вида «При изменении С пересчиать KF1»);
— для других (вида «Блок настройки коммутатора MUX3»);
— магические (вида «Не трогать! Иначе не работает!»).
В *doc же можно засунуть математику, графики и прочую обосновательную ерунду. Я как-то обошелся парой строчек текста и четырмя диаграммами, т.к. из них предельно ясно понятно что, зачем и куда. Пояснения должны быть предельно понятным.
Согласен, что нет ничего хуже такого засилья комментариев, когда разработчик передавая код говорит, что документация абсолютно не потребуется (типа там все есть), т.к. «там все понятно расписано». Начинаешь смотреть, а так как картины в целом еще нет, образуется каша в голове.
Кстати, автор мог бы упомянуть, что комментарии бывают трех видов:
— для себя (вида «При изменении С пересчиать KF1»);
— для других (вида «Блок настройки коммутатора MUX3»);
— магические (вида «Не трогать! Иначе не работает!»).
По-моему мы о разных *doc говорим. Я о комментариях для генераторов документации phpdoc, javadoc и т. п.
/**
* Проверяет, допустимый ли ход.
* Например, чтобы задать ход e2-e4, напишите isValidMove(5,2,5,4);
* @author John Doe
* @param theFromFile Вертикаль, на которой находится фигура (1=a, 8=h)
* @param theFromRank Горизонталь, на которой находится фигура (1...8)
* @param theToFile Вертикаль клетки, на которую выполняется ход (1=a, 8=h)
* @param theToRank Горизонталь клетки, на которую выполняется ход (1...8)
* @return true, если ход допустим, и false, если недопустим
*/
boolean isValidMove(int theFromFile, int theFromRank, int theToFile, int theToRank)
{
...
}
Результаты — это работающее приложение без багов. А код, документация, диаграмки, и прочие процессуальные экскременты — это факультативно.
Я будто бы снова вернулся в универ на пары педагогики. Эти же потоки воды низвергающиеся из уст умудренного опытом преподавателя. И та же утрата нити повествования уже на десятой секунде. Butthurt засчитан, я нуб. :(
Если вы, как менеджер по персоналу или владелец фирмы, вдруг читаете в чьем-то резюме слова о «5-6 лет опыта разработки», то знайте — их нельзя перевести как “опытный”. Это переводится так: чувствующий свою неуязвимость малолетка, с вероятностью 50 на 50 напишет вам кучу дерьма, в которой потом не разберется ни его команда, ни он сам, и которую он вероятнее всего не один раз будет переделывать. Но все это в порядке вещей — любой разработчик бывает подростком в своей профессиональной жизни.
Категорически не согласен с подобными высказываниями.
Здесь очень многое зависит от самоподготовки, и от того, что называть «5-6 лет опыта разработки». Я предпочитаю под этим понимать написание коммерческих приложений. Если же отсчитывать от точки начала программирования вообще… тогда, возможно, автор прав. И то не могу сказать с уверенностью, т.к. у многих программирование начинается с университета, а после выпуска они уже устраиваются на работу. Я шел немного другим путем, и программирование начинал до универа, поэтому мне сложно судить адекватно…
IMHO.
У меня сейчас семь лет коммерческого программирования, и я понял, что действительно чувствую себя как подросток — море по колено, бросает в крайности, категоричные суждения и т.п. Уже пошло на спад немного, но полтора-два года назад был пик. У Пола Грэма это хакерской натурой называется, но тут более точно ухвачена суть.
О чем пост?
О том, что со временем люди набираются опыта и начинают писать немного по-другому?
Передавайте привет Капитану Очевидность.
О том, что со временем люди набираются опыта и начинают писать немного по-другому?
Передавайте привет Капитану Очевидность.
Ух, наконец-то перевод чего-то стоящего и дающего пищу для размышлений. Спасибо переводчику (хоть и не без ляпов).
Со многим согласен, в некоторых персонажах узнал знакомые свои черты. Но вот это:
Со многим согласен, в некоторых персонажах узнал знакомые свои черты. Но вот это:
ценой внесения метаданных вы чуть-чуть ухудшаете поддерживаемость, стоимость, гибкость, тестируемость и расширяемость.осталось для меня парадоксом. Я-то считал, что все наоборот. Видимо я еще настолько нуб, что не могу ухватить глубину мысли.
Хочу поблагодарить автора (переводчика) за интересную статью. Проблема комментариев действительно остра, но еще более остра проблема метаданных. Когда появились программно используемые метаданные (аннотации), думал, что счастье на земле есть :) Теперь начинаю склоняться к тому, что использование десятка различных аннотаций приводит к потери нити управления, в конечном счете запутанность проявляется еще больше. Пример тому JPA-аннотации, Spring-аннотации, когда уже ничего не видно как работает и как вызывается и вообще уже похоже, что пишешь не на Java, а каком-то дивном языке, по которому надо прочитать еще десяток книжек.
Стоит признать, что интерфейсы как элемент метаданных, очень хорошо прижились и в принципе не вызывают затруднений. Хотя иногда можно задаться вопросом почему не сериализируется или не клонируется некоторый объект. Комментарии хотя бы безвредны, хотя часто и отвлекают от сути.
Я бы сказал, что структура проекта очень важна + необходимость реализовывать функциональные требования с минимальными издержками. Структура помогает при поддержке проекта, а граммотная архитектура при написании новых функций.
Стоит признать, что интерфейсы как элемент метаданных, очень хорошо прижились и в принципе не вызывают затруднений. Хотя иногда можно задаться вопросом почему не сериализируется или не клонируется некоторый объект. Комментарии хотя бы безвредны, хотя часто и отвлекают от сути.
Я бы сказал, что структура проекта очень важна + необходимость реализовывать функциональные требования с минимальными издержками. Структура помогает при поддержке проекта, а граммотная архитектура при написании новых функций.
Муж (м) — программер, (я) — филолог.
М: Сходи за меня на работу, а?..
Я: Окей, дорогой, буду править ошибки в комментариях твоего кода))
М: Я не комментирую код. То, что писалось тяжело, должно и читаться тяжело.
Я: Лев Толстой, наверное, по такому же принципу работал...
©bash.org.ru
Как по мне, комментариев в коде не должно быть. Совсем. Если требуется добавить в код комментарий, этот код нужно переписать. Естественно, документации это не касается.
Странно, никогда не встречал кода с комментариями-рассказами и сам таким никогда не страдал. Щас пересмотрел свои старые бейсик-исходники — везде (как и сейчас) нечастые однострочные комментарии, поясняющие назначение блока. Никогда бы и в голову не пришло писать такие «рассказы» в коде. И как выше заметили, у нас нубы скорее вообще не используют комментарии, чем пишут их избыточно
Коментарий — это повод для рефакторинга. Если вы пишите коментарий, значит код явно не выражает намерение программиста © Фаулер
Код (а не коментарии) должен рассказывать историю © Бек, Кэнигхем
Код (а не коментарии) должен рассказывать историю © Бек, Кэнигхем
Я не знаю зачем вообще нужны комментарии на java. В плюсах бывают моменты, когда нужно записать, что делает оператор, типа такого «for(;P(»\\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);", чтобы не забыть самому. А в java нужно сильно постараться, что бы такое сделать.
наоборот, Python и Ruby становятся все более популярными, чем Java и C++
По коментариям создалось впечатление, что те кто не понял о чем статья — даже хуже чем нубы. Статья довольно фундаментальная, и даже несмотря на то что дерьмово написана, обсуждает важный вопрос достижения цели в обмен на онанирование на архитектуру, коменты и прочие маразмы которым каждый 5 программист увлеченно занимается и считает себя крутым за это.
UFO just landed and posted this here
Очень, очень, очень глубоко копает.
Когда я был мелким, лет 15, мне досталась дискетка с исходниками простеньких игр, а я сам тоже писал простенькие игры. И там был тривиальный тетрис написанный по всем канонам ООП на щщах с исходниками под 200 кб весом. Исходники моего тетриса занимали 3 кб, несколько массивов, несколько функций плюс отрисовка и обработка прерываний ввода. Я полез внутри и в силу неопытности мало что понял, но расхождение в объеме кода меня поразило.
Поражает и сейчас, хотя я понимаю что 500 классов или 200 таблиц данных это средненький проект.
Из нубства на правильный путь меня направил императив уменьшения сложности. Похрен на идеалогию, методики, похен на все, я не хочу держать в голове 500 классов, эффективно жонглировать в голове я смогу лишь 5 из них а остальное лишь запутает мои попытки понять что происходит.
Любые метаданные это внесение нового уровня сложности.
С другой стороны правильная организация методов и переменных, их правильное наименование — это наше все, это способ заставить код говорить вместо комментариев.
Когда я был мелким, лет 15, мне досталась дискетка с исходниками простеньких игр, а я сам тоже писал простенькие игры. И там был тривиальный тетрис написанный по всем канонам ООП на щщах с исходниками под 200 кб весом. Исходники моего тетриса занимали 3 кб, несколько массивов, несколько функций плюс отрисовка и обработка прерываний ввода. Я полез внутри и в силу неопытности мало что понял, но расхождение в объеме кода меня поразило.
Поражает и сейчас, хотя я понимаю что 500 классов или 200 таблиц данных это средненький проект.
Из нубства на правильный путь меня направил императив уменьшения сложности. Похрен на идеалогию, методики, похен на все, я не хочу держать в голове 500 классов, эффективно жонглировать в голове я смогу лишь 5 из них а остальное лишь запутает мои попытки понять что происходит.
Любые метаданные это внесение нового уровня сложности.
С другой стороны правильная организация методов и переменных, их правильное наименование — это наше все, это способ заставить код говорить вместо комментариев.
Sign up to leave a comment.
Портрет Нуба