acerv 4 сен 2011 в 20:45

Портрет Нуба

17 мин

6.6K

Веб-разработка *

Перевод

+91

171

Комментарии 171

ckald 4 сен 2011 в 20:59

У меня почему-то душа не лежит к комментированию. Пользуясь вашей систематикой, я сразу подростком стал. Максимум комментирования, на который я способен: указание перед функцией данных, необходимых для генерирования документации. Во всех остальных случаях для меня комментарии – хранилище неиспользуемого в данный момент кода.

Скорее всего, бедные те, кто будут после меня, но сам я не испытываю проблем в чтении с листа вменяемого кода.

NickLion 5 сен 2011 в 05:16

Ага, аналогично никогда особо не комментил код. Ну, только стрёмные оптимизации разве что, да пометки вроде FIXME, TODO, HACK да функции в общем (и то не все). В основном комментарии — это закомментированный код :) Код должен «читаться» и так. А если не читается, то что-то тут не так.

denver 5 сен 2011 в 05:44

А это такая природа программиста — пока пишет на текущем уровне *ему* все понятно. Уж лучше бы порой сомневался комментами // I feel it smells but can't imagine better approach

NickLion 5 сен 2011 в 09:00

Ну, вот в таких местах я ставлю // FIXME: description how to fix или // HACK: dirty hack to do smth если пока не представляю как по-нормальному сделать.
А насчёт всё понятно — описания классов и методов обычно хватает, или если сложный блок — особенно, если оптимизировано до состояние непонимания — тут да, по-любому надо.

ingspree 5 сен 2011 в 09:18

Комментированый код существовать не должен. Для этого существуют системы контроля версий.

NickLion 5 сен 2011 в 09:21

Понимаете, есть теория, а есть практика. Да, в теории всё замечательно — DCVS вроде git или mercurial… а в реальности — svn. поэтому комментированный код будет. Особенно если идёт разработка вот сейчас — этот коммент будет удален до коммита, но пока — оно проще.

ingspree 5 сен 2011 в 09:27

У меня в практике: сейчас меркуриал, перед этим проект с гитом, перед этим проект с сабвершеном и hgsubversion, перед этим еще два с меркуриалом. Да, три из них я убедил юзать меркуриал (один с нуля, один с свн, один — самый последний — с базара), но усилия того стоили. :)

NickLion 5 сен 2011 в 09:42

Ох, не сомневаюсь, что стоили :) В принципе о mercurial уже думали, но пока тихо :(

asfd 5 сен 2011 в 11:09

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.» (С) Стив Макконнелл

С такой точки зрения понимание где уместно ставить комментарии иногда достичь легче. :)

ckald 5 сен 2011 в 11:12

Как замечательно, что этот психопат я!

andreycha 4 сен 2011 в 21:00

Действительно, разница в восприятии опыта у нас и на Западе различается.

[...] вдруг читаете в чьем-то резюме слова о “5-6 лет опыта разработки”, то знайте — их нельзя перевести как “опытный”. Это переводится так: чувствующий свою неуязвимость малолетка, с вероятностью 50 на 50 напишет вам кучу дерьма

А у нас 5-6 лет опыта — и уже сеньор/тимлид/архитектор.

НЛО прилетело и опубликовало эту надпись здесь

VlK 6 сен 2011 в 19:20

Автор, Стив Йегг, вроде как разработчик с опытом лет в 20-25. Он видел появление плюсов, восход Джавы, появление Джаваскрипта как языка, и я лично видел его код в живых открытых проектах. Это не закостеневший зубр, а очень и очень толковый разработчик, быстрый, внимающий трендам. Это не считая того, что известный блоггер.

Что совсем уж редко — он так и не стал одним из этих консультантов.

Так вот. С его колокольни все мы здесь в лучшем случае начинающие :)

FINTER 5 сен 2011 в 04:36

Хватит уже делить на «на запад» и «у нас». И там долбоебов хватает и тут. И у них есть крутые тимлиды и у нас.

А опыт тем более ничего не показывает. Все зависит от того, на сколько была агрессивной среда, в которой развивался специалист. Скажем, если человек попал стажором в Эбби, то за 5-6 лет он вполне может стать тимлидом, а продвинутым кодером будет точно. А вот если он попал в какой-нибудь шараш-монтаж, то возможны варианты.

Beresta 5 сен 2011 в 11:28

Вопрос еще в том, что именно тут считается опытом…

Вот считается ли опытом участие в школьных олимпиадах по программированию, написание дома всякого софта разной степени бесполезности, обучение в универе по специальности наконец? ;-)

veter 5 сен 2011 в 17:00

Опыт работы и опыт хобби — очень разные вещи.

Beresta 5 сен 2011 в 17:51

Опыт работы и опыт программирования — тоже очень разные вещи.

Akson87 4 сен 2011 в 21:16

Интересно… рад, что не я один люблю экономить на комментариях. А то начальник недавно попросил добавить побольше комментов к коду, дабы последующим было легче, так мне пришлось долго думать где же их впихнуть, так как везде имена функций и переменных говорящие, разве что ветки условных операторов обозначить и не очевидные места алгоритмов. Вообще, как по мне, так хороший код почти не надо комментировать.

А с моделированием главное вовремя остановиться. Я делаю просто: если после добавления классов я смогу забыть о том, что у них внутри — добавляю. Причем добавляю как можно меньше классов, которые полностью описывают какой-то кусок проблемы, но если можно проблему внутри разбить еще раз, будет на каждую подпроблему свой класс. Может правильные подход, может нет, но как-то работает:)

Pushkoff 9 сен 2011 в 14:17

«все правильно сделал»
en.wikipedia.org/wiki/SOLID_(object-oriented_design)

m1el 4 сен 2011 в 21:31

Don't try to model everything!

Вот об это я уже спотыкался.

iximiuz 4 сен 2011 в 21:32

Для контраста, вот код, который я пишу сегодня:
…
В каком бы ужасе я находился, если бы я увидел этот код 20 лет назад.

Почему-то кажется, что в ужас нужно бы придти и сейчас… Код нужно писать для людей, а не для машин.

naryl 4 сен 2011 в 22:36

Он был написан для людей… А потом его перевели сначала на C, потом на Java, потом на EL. И получился ужас.

llxff 5 сен 2011 в 03:04

Он же все равно его писал.

Hemul 4 сен 2011 в 21:41

20 лет назад я не писал комментариев, так как 1) объемы носителей были малы и комментарии жрали драгоценное место и 2) я и так помнил наизусть все свои алгоритмы, а другим до них не было дела :)
Сейчас я не пишу комментариев, так как 1) я научился использовать простые алгоритмы и писать простые программы (не брезгуя использованием готовых библиотек) и 2) программы для меня — инструмент, часто одноразовый, нет нужды комментировать или даже просто хранить их. Надо будет — новые напишу, лучше прежних :)

SVlad 4 сен 2011 в 21:54

Новичок, который комментирует каждую строчку хотя бы так — это уже идельный новичок. Обычно новички свой код вообще не комментируют.

GrigoryPerepechko 4 дек 2011 в 10:24

Опять же. Он о других новичках. Для него 3-5 лет комерческого опыта это новичок. У таких «новичков» порой бывают бзики. Использование паттернов где надо и не надо, оверкоментинг, супергибкие архитектуры и прочее.

А для нас новичок с 3-5 лет опыта — это как вы верно подметили «идеальный новичок»

SVlad 4 дек 2011 в 11:19

Я всегда считал, что новичок — это студент, взятый с 4-5 курса, например. А 3-5 лет опыта — это уже не новичок.

НЛО прилетело и опубликовало эту надпись здесь

goodbear 5 сен 2011 в 10:00

Просто автор бросил писать длинные занудные комментарии и начал писать длинные занудные статьи.

megalol 4 сен 2011 в 21:58

Гоблин-аргументация: выдумать в статье подростка (который по психологическим причинам будет больше говорить об авторе, чем об оппоненте) и спорить с ним. Подросток при этом проигрывает, потому что подросток, ну это же очевидно, что тот, кто ужаснулся от кода автора — нуб, то ли дело блоггер-автор.

EndUser 5 сен 2011 в 04:28

А эта гоблин-аргументация идёт, знаете ли, из древней античности, от Сократа и Платона.
Нормальный жанр для статьи, проверенный временем. ;-)

SONce 4 сен 2011 в 21:59

никогда не понимал чем люядм которые считают себя «папками или гуру» мешают развернутые коментарии.
Да я иногда например тоже коментирую каждую строку, и даже $i++ коментирую, никогда не понимал чем это плохо?

VolCh 4 сен 2011 в 22:05

Например — сложный алгоритм. Предпочтительнее видеть его на одном экране, чем размазанным на многих.

SONce 4 сен 2011 в 22:06

ну в сложном алгоритме имхо разобратся быстрее и проще если он отлично закоментирован, я конечно понимаю что хороший код не нуждается в коментариях но не всех у нас iq выше 120

bytemdfab 5 сен 2011 в 06:36

Конечно все зависит от сложности алгоритма, но лично мне обычно коменты мешают разбираться в алгоритме. Отдельный случай (но это уже конечно клиника) — когда коменты не соответствуют коду.

Colwin 6 сен 2011 в 03:40

Это не такая уж клиника, как может показаться.
Не каждый программист поддерживает чужие комментарии. Да и свои не всегда.
Поэтому, IMHO, лучше следовать мантре «Читай код».

bytemdfab 6 сен 2011 в 05:21

Я же это и имел в виду — imho, обычно комментарии нисколько не помогают разобраться в коде.

> Не каждый программист поддерживает чужие комментарии. Да и свои не всегда.
Это уже вопрос культуры. Раз уж начал комментировать код — будь добр поддерживать эти комментарии в актуальном состоянии. Иначе это просто свинство по отношению к коллегам.

P.S. За статью спасибо, прочитал с большим удовольствием.

Zagrebelion 5 сен 2011 в 01:07

Хозяйке на заметку: если ваш редактор не позволяет свернуть комментарии и блоки кода, выкиньте его.

ixSci 5 сен 2011 в 04:12

покажите мне редактор, который сворачивает // комментарии, пожалуйста

Amper 5 сен 2011 в 04:37

VIM, Emacs, SciTE, Notepad++

Amper 5 сен 2011 в 04:38

Ой, простите, неверно понял ваш комментарий

ixSci 5 сен 2011 в 04:40

Можете показать пример(картинку) где в Notepad++ сворачивается комментарий вида "//"? Я не вижу там такой возможности. Другими редакторами не обладаю, поэтому и проверить не могу.

Amper 5 сен 2011 в 04:42

Я же написал, что неверное истолковал ваш комментарий, не заметил, что вы про "//". Так что не обращайте внимания ) Хотя, думаю, если хорошо подумать, то в VIM можно сделать сворачивание таких комментариев.

aleks_raiden 5 сен 2011 в 08:13

а как его сворачивать, если это ОДНОСТРОЧНЫЙ комментарий? вот /*… */ такое сворачивает

Amper 5 сен 2011 в 09:17

Подразумевается несколько идущих подряд однострочных комментариев

slaykovsky 28 июл 2015 в 13:58

Можно его просто не показывать. Вим можно такому научить довольно-таки легко.

Colwin 6 сен 2011 в 03:42

IntelliJ IDEA

Suor 5 сен 2011 в 06:01

Вот ещё! Вместо того, чтобы просто видеть то, что нужно я буду комментарии сворачивать-разворачивать.

d7k 5 сен 2011 в 07:00

Возможность сворачивать — это фича. Она, как и наличие коментариев (методанных), не влияет на качество кода. Мне нравится мысль Фаулера: если для объяснения кода нужен коментарий попробуйте отрефакторить его (почти дословно).

Colwin 6 сен 2011 в 03:43

Фаулер хорошо понимает принципы проектирования, эт точно.
Кстати, это очень хорошо работает. Не нашел ни одного случая, где путем рефакторинга не удалось бы избавиться от комментариев и излишней запутанности кода.

megalol 4 сен 2011 в 22:10

С точки зрения автора:
1. Это дает возможность писать непонятный код и заставляет вести две параллельных ветки: литературную и на языке программирования.
2. Очень редко это действительно нужно. Например i — это что такое вообще? Может someIdx было бы лучше и избавило бы от комментария.
С другой точки зрения:
3. Понимать, что этот код делает становится сложным: если я открыл ваш код, я или пытаюсь узнать, что функция делает и абстрагироваться от реализации (тогда достаточно коммента в начале), или пытаюсь высмотреть у вас там ошибку, и построчные комментарии конечно же об ошибке мне ничего не скажут.
4. Намного проще становится делать хаки и прочее — а чего, комментарий ведь выше описывает, что делается. Если бы комментариев было мало, откомментированный хак был бы заметнее.

Akson87 4 сен 2011 в 22:24

Если в коде используются понятные имена функций и переменных, то простые алгоритмы просто нет смысла комментировать, код уже содержит всю информацию.

Например:
i++; //увеличиваем количество клиентов

Можно написать как:
ClientsNumber++; //увеличиваем количество клиентов

В первом случае мы описываем, что же мы делаем в комментах, во втором же случае мы пишем два раза одно и то же.

Agent_Smith 5 сен 2011 в 05:24

Писать самодокументируемый код очень удобно и полезно, но полностью от комментариев отказываться тоже глупо. Я например, стараюсь разбивать код на некие логические блоки длиной 4-10 строк и разделять их абзацами, и перед каждым таким блоком стараюсь вставить однострочный комментарий описывающий что в нем делается. Так намного проще даже мне самому ориентироваться в коде. Ну а внутри блока, по именам переменных и функций и так все понятно.

d7k 5 сен 2011 в 07:10

Месяц назад, мне захотелось в первые за год написать комментарий на строку кода (внутри метода). Я ее написал, пошел дальше. Подумал, вернулся и разделил строку на две или три. Комментарий удалил. Завтра, если я ее увижу и подумаю, что она все равно сложная — еще чего-нибудь сделаю.

Абзацы — надо делить на отдельные функции с внятными именами.

Akson87 5 сен 2011 в 17:57

Я бы сказал, что комментарии должны быть высокоуровневыми, т.е. надо комментировать, что происходит глобально, а не как это реализовано в каждой строке. Хотя при правильном разделении на функции и классы в этом тоже исчезает смысл. d7k уже ответил, что абзацы можно выделить в функции и результат будет тот же. Но если не выносить все в функции, тогда комментарии необходимы. А до какой степени все выносить в отдельные функции и классы — это уже другой вопрос и я не думаю, что есть универсальное решение, которое всем понравится.

Colwin 6 сен 2011 в 03:47

А до какой степени все выносить в отдельные функции и классы — это уже другой вопрос

Используем давно известный принцип единой ответственности. Если есть трудности с определением, выполняет ли предложенный код одну или несколько задач, советую прочитать «Чистый код».

Akson87 6 сен 2011 в 13:51

Только проблема остается все та же, как определить простейшую задачу, которую не надо разбивать дальше?

Т.е. есть например есть игра в которой надо нарисовать персонажа. Что есть простейшая задача, которую не надо разбивать на подзадачи? Нарисовать персонажа? Нарисовать руку/ногу? Нарисовать отдельно тело отдельно одежду? Нарисовать поверхность? Нарисовать треугольник?

Код, который рисует персонажа отвечает только за рисование персонажа, но делает много разного для этого. Если же все дробить на мельчайшие части, то объем кода сильно растет и его поддержка занимает больше времени.

Colwin 7 сен 2011 в 04:19

Разберу случай с персонажем:

Работа с движком — инкапсулируется в отдельный класс>
Получение простейших компонентов, таких как линии, плоскости, примитивы — все в отдельный класс, на каждый компонент — отдельный метод.
Элементарные преобразования — в отдельный класс, на каждое преобразование — отдельный метод.
Различные сложные компоненты и преобразования также по отдельным классам.
Рисование каждой части тела — в отдельный метод. Возможно, сложную часть тела типа «рука» имеет смысл разбить на зап. части, по методу на каждую.
Рисование первонажа — отдельный метод.

Как разбивать (и разбивать ли) внутри данных методов — сильно зависит от того, какой код будет получаться в итоге. Правила, которыми имеет смысл руководствоваться, давно известны и написаны, например, у Макконнелла.

Akson87 7 сен 2011 в 04:50

Ваш подход — это один из многих вариантов. Как альтернативу можно привести по классу на каждый элемент и их иерархия: персонаж содержит руки/ноги/etc и свое относительное расположение в сцене, руки/ноги/etc содержат внутри геометрию и свои положения в сцене, геометрия содержит треугольники и их положение. Тогда чтобы нарисовать надо вызвать метод персонажа, а все остальное иерархически будет происходить внутри. Так что все далеко не так однозначно как кажется:)

Да Вы и сами говорите:

«Как разбивать (и разбивать ли) внутри данных методов — сильно зависит от того, какой код будет получаться в итоге.»

То есть нельзя точно сказать, как разбивать тот или иной код. Один человек сделает так, другой эдак. Правила то есть, но это скорее не алгоритмы с точным результатом, а эвристические правила, которые подсказывают куда двигаться.

Colwin 7 сен 2011 в 04:20

«Рисование персонажа» — это одна ответственность, да. Поэтому не надо туда сваливать рисование треугольника — это уже другая ответственность :-) Понимаешь принцип?

Colwin 7 сен 2011 в 04:23

Если же все дробить на мельчайшие части, то объем кода сильно растет и его поддержка занимает больше времени

Не согласен. Необходимо просто дробить таким образом, чтобы взгляда на имя метода и набор параметров было достаточно для того, чтобы вспомнить, что оно делает. Тогда навигация до нужного места происходит интуитивно, без лишнего обдумывания.

Akson87 7 сен 2011 в 04:42

Хотел поспорить сначала, потом подумал, может мы оба правы:)

Подход с идеальным разбиванием на части может работать (да и работает) только при условии, что разработчик заранее знает какие компоненты будут в финальной версии. Если же, эти самые компоненты меняются по ходу дела по причине изменений в ТЗ, отсутствия опыта в момент начала проекта, обнаружения большой и страшной ошибки в начальной архитектуре (часто сделанной хз кем как и когда), итд итп, то правильный подход с разбиением на множество классов только добавляет проблем, так как менять приходится гораздо больше кода.

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

И еще этот метод нельзя применять при написании первой исследовательского кода, это уже мой личный опыт. Я честно пытался разбивать все на части красиво, но в результате слишком много времени тратилось на поддержку. Видимо поэтому я и против того, чтобы всегда делать все правильно и красиво:)

GrigoryPerepechko 4 дек 2011 в 10:31

Во втором случае код говорит увеличить номер клиента (какой именно номер ??), а коментарий говорит увеличить кол-во.

numberOfClients++; — так пожалуй более честно

Akson87 4 дек 2011 в 16:53

Ваша правда, плохое имя дал. Но идея та же:)

weirdan 4 сен 2011 в 23:07

Это мешает читать код.

auesys 4 сен 2011 в 21:59

Золотые слова:
Код нужно писать для людей, а не для машин

Akson87 4 сен 2011 в 22:22

Надо, только не всегда такое возможно… (но это скорее исключение, чем правило, например GPGPU где вызов функции = растрата регистров на стек)

Colwin 6 сен 2011 в 03:48

Понятное дело, там, где идем война за регистры и кешы процессора, там действуют другие правила :-)

auesys 6 сен 2011 в 08:33

hex код не надо комментировать, это для машин, а в исходники я предпочитаю вставлять комменты, хотя бы для того, чтобы знать, что означают выводы порта контроллера (которых десятки), так как это не поддается особой логике и склонно к изменению (аппаратному, например).

Evengard 4 сен 2011 в 22:31

у мну обычно дилемма. либо описать очень подробно каждую строчку, либо не писать вовсе. ибо я считаю свой код понятным итак, и тогда либо комменты нужны полным профанам, либо не нужны вовсе. ну и еще я не люблю переменных a, b, c и т.д. максимум что я использую, это i для for циклов.

кто я? подросток? нуб? еще кто похуже?

abusalimov 4 сен 2011 в 23:50

Вы «мну».

Evengard 5 сен 2011 в 02:48

я «гну» тогда уж ) парнокопытное )

remal 5 сен 2011 в 00:13

Еще ни разу не видел, чтобы кто-нибудь написал о комментировании лучше Макконнелла. И эта статья — не исключение.

anitspam 5 сен 2011 в 00:58

>> Боже, линии не отделены друг от друга! Некоторые из этих линий даже не прокомментированы!

Боже, линии! (хотя может переводчик не программист)

>> Если быть честным, то я согласен, это некрасивая функция.

Если быть честным, то привел бы автор пример своей красивой функции, чтобы видно было, как он пишет сейчас. А то может он и не «повзрослел» вовсе.

zeliboba 7 сен 2011 в 10:54

переводчик тоже должен учитывать контекст и использовать адекватный словарь

kushti 5 сен 2011 в 01:17

В кружке информатики при Дворце Пионеров, а потом и в университете видел очень много нубского кода(не считая своего). Комменты отсутствовали напрочь.

amarao 5 сен 2011 в 01:24

Было такое. Одно время я доводил себя до состояния, когда каждая фукнция должна была занимать не более 20 строчек и иметь не менее 5 строк комментариев, а пустыми строками она отделялась от соседей так, чтобы на экране была только одна функция.

Кстати, я так и не стал хорошим программистом (хотя способен кодить на нескольких языках) и стал сисадмином (для которого подобная обстоятельность — скорее благо, чем зло).

И, кстати, потому мне тяжело писать на питоне — там слишком много нужно программировать, и слишком мало выполнять всяких простых ритуальных движений, вроде проверки успешности выделения памяти, организации списка и т.д.

skitalets 5 сен 2011 в 01:28

Хорошо, если новичок комментирует хотябы каждую пятую строчку. А то обычно они вообще не комментируют код.

Colwin 6 сен 2011 в 03:50

А то обычно они вообще не комментируют код.

Это не плохо. Плохо обычно в том случае, когда этот код представляет собой кашу.

EndUser 5 сен 2011 в 01:43

Между писаниной простого плоского кода, который растягивается на очень длинные листинги, и писаниной высоко-сложного кода, который растягивается на очень длинные листинги, где-то в районе посреди есть оптимальная позиция, имеющая минимальный листинг.

Тут я с автором совершенно согласен. Если я неверно понял его предупреждение не писать плоский код. ;-)

Читать Властелина Колец, где для понимания текста читатель обязан сначала прочесть 50 страничную энциклопедию, прямо-таки алфавитно упорядоченную, я отказался. И у меня ушло 60 минут разобраться в короткой фразе «рецессивный аллель влияент на фенотип, только если генотип гомозиготен», которая читается за 10 секунд.

То же самое когда определяется сложная модель — вводится гигантский «prerequisites» для чтения. В конце концов задача решается, конечно же, в одну строчку, но… Длина листинга же.

Плоский код, с другой стороны, сродни фортрану или ассемблеру. Длинные простыни примитивных операций во время чтения которых ты пытаешься перевести их на термины задачи, но забываешь с чего дело началось 5 страниц назад. Почти обязательно он будет в стиле «спагетти». Каждая отдельная строка понятна, но общая картина в голову не укладывается. Длина листинга же…

При этом я не имею в виду obfuscated c programming, где используются трюки навроде «while (*d++ = *s++);», (который объясняются в K&R на трёх страницах). Это третья шиза, но она встречается гораздо, гораздо реже.

Сам на С++ пишу «в стиле С», так как практические задачи универсальных абстракций не требуют. И комментирую одной-двумя строками следующий блок в 5-10 строк.

whitequark 5 сен 2011 в 02:23

Ваша фраза про «рецессивный аллель» мне напомнила о динамичесих и функциональных языках.

Будучи студентом-биоинформатиком, смысл я понял за пару секунд, но это мне напомнило некоторых коллег-сишников, которые долго-долго пытались понять штуки вроде map{}.reduce{} в Ruby или мои собственные попытки вникнуть в таинства концевой рекурсии в Scheme.

Скорость и легкость понимания кода все же очень сильно зависит от опыта.

megalol 5 сен 2011 в 02:30

Это школьная программа.

whitequark 5 сен 2011 в 02:49

Хм, не знал, что в общеобразовательной тоже есть — я был в биохим-параллели.

К слову, вещи вроде map/reduce, на мой взгляд, тоже вполне тривиальны — и тем не менее регулярно вызывают затруднения, как и «школьная программа» у автора первого комментария.

lair 5 сен 2011 в 11:24

«Читать Властелина Колец, где для понимания текста читатель обязан сначала прочесть 50 страничную энциклопедию, прямо-таки алфавитно упорядоченную, я отказался»
Есть мнение, что вы что-то делаете не так. ВК прекрасно читается и без этого.

Zorkus 6 сен 2011 в 11:14

Тут путают ВК и «Сильмариллион». Вот тот да, требует изрядныз усилий порой.

Zorkus 6 сен 2011 в 11:15

А вообще, ВК с точки зрения сложности восприятия и количества информации, которое нужно удерживать в голове, чтобы понимать что вообще происходит, читается куда проще чем, например, «Хранитель Мечей».

valerypride 5 сен 2011 в 01:59

Эпичный троллинг. Напомнило моего первого начальника который 30 лет писал на ассемблере и утверждал что классы (в С++) — это баги, и писать надо только C-style. Правда он, в отличие от автора текста, не троллил а просто дурак был (чем погубил не один проект)

И да, про комментарии. В них, как было обмусолено тысячу раз, нужно писать что, а не как. Тогда и описаний на полэкрана не будет.

EndUser 5 сен 2011 в 02:40

Классы — штуки реально хорошие, когда пишешь либу.

Ещё лучше, когда берёшь чужую тщательно продуманную — ведь VCL толкнул Delphi очень далеко вперёд.

Но стоит задуматься — нужна ли в этой конкретной сегодня программе эта моя самописная либа. И что в неё таки правильно оформить.

Всегда можно дойти до маразма
main() {MyClass.SolveTheProblem();return;};
но надо ли? действительно ли цикл жизни моего софта предполагает 10-летнее использование с пятикратным ростом функционала, или 2-3 года и две модификации хватит?

DanXai 5 сен 2011 в 04:15

main() {MyClass.SolveTheProblem();return;};
Вот она — Большая Красная Кнопка!
*аплодирует*

bytemdfab 5 сен 2011 в 06:35

Вот, почти оно:

static void Main()

{

Application.EnableVisualStyles();

Application.SetCompatibleTextRenderingDefault(false);

Application.Run(new Form1());

}

alienator 5 сен 2011 в 07:40

Классы-шмассы…
Пишете свой язык. А потом в нем вот так:

do;

Точку с запятой можно опустить.

megalol 5 сен 2011 в 09:17

Дык это ж системная консоль, написана уже

Colwin 6 сен 2011 в 03:56

Это «что» лучше тоже писать в коде ) например, в именах функций, методов, полей и классов.

Меня больше зацепили в статье не комментарии, за которые ухватились куча народу, а само понятие «метаинформации». Т.е. самодокументирующий код пишут нубы? Думаю, с автора (не статьи, а исходника) таки нужно взять листинг его собственного кода, и посмотреть, кто он такой.

ahriman 5 сен 2011 в 02:32

Дочитал до середины, надоело, прочитал «вывод», но так и не понял, что это. Высер старпера-эксперта, троллинг или что-то третье?

НЛО прилетело и опубликовало эту надпись здесь

Shedal 5 сен 2011 в 07:22

Автор статьи — тролль 80-го левела.

vanfukov 5 сен 2011 в 07:29

Всего лишь 80-го?

boh 5 сен 2011 в 09:32

Для левел-апа пора учиться писать по-короче.

ArtyV 5 сен 2011 в 03:10

Лол, я бы посмотрел на то, как выглядит поддержка оооогромной кучи динамического кода. Точнее, я уже насмотрелся, конечно, но посмотрел бы ещё :D люблю острые ощущения

HeavyWave 6 сен 2011 в 01:12

Я бы еще на производительность посмотрел.

Colwin 6 сен 2011 в 03:59

Ага ) Вспоминаю поиск в исходниках на Ruby нужного мне метода. Который, как оказалось, создается динамически :-) И IDE с такими конструкциями ой как не дружит…
А если все это писал не ты — это покруче чем #define true (random() > 0.5).

Ryadovoy 5 сен 2011 в 04:27

Я таких комментариев не встречал ни разу.
Но думаю что лучше уж будут такие комментарии у говнокодеров, т.к. из них можно хоть понять ход мыслей, понять зачем здесь этот кусок дерьма.

Colwin 6 сен 2011 в 04:00

Это позволяет все отрефакторить и удалить портянки.
Хотя времени убьешь…

rodweb 5 сен 2011 в 05:45

Я при написании комментариев руководствуюсь следующим принципом: пойму ли я, что делает код, открой я его месяца через два? От этого и длина комментариев зависит.
Раньше мне тоже очень нравились конструкции вида «сделать офигенно» и мемуары в комментариях, но сейчас я понимаю, что все это на самом деле не несет в себе никакой полезности, а порой и смысла.

Colwin 6 сен 2011 в 04:02

Я при написании комментариев руководствуюсь следующим принципом: пойму ли я, что делает код, открой я его месяца через два?

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете» © Стив Макконнелл

sige 5 сен 2011 в 05:48

По мне так вопрос о комментариях очень второстепенный в статье. Это так для затравки. Читал 1 раз и вскользь т.к. много букв. Не все понял что хотел автор. Замечал противоречия в его рассуждениях, но не стал возвращаться назад чтобы их уточнять, мне это было не интересно было. Автор говорит про модели очень абстратно и неконкретно как будто если он скажет что-то конкретное, то придется отвечать на гору каверзных вопросов и спорить. Вобщем эта статья требует структуризации, конкретных тезисов, укорачивания и избавления от кучи ненужных метаданных иначе ее не захотят понимать в виду объема, неконкретности, расплывчивости формулировок.

d7k 5 сен 2011 в 07:23

и (или) деления. Слишком много тем затронуто.

Yakhnev 5 сен 2011 в 08:21

Далеко ходить не надо

Лично я предпочел бы разбираться в сжатом, сложном коде небольшого объема, чем в здоровой системе из тысяч файлов с коментами.

Лучше отдыхать на юге летом, чем служить на севере зимой…

Mithgol 5 сен 2011 в 05:58

А когда я был студентом, то у меня в начале некоторых ассемблерных листингов стояли три строки хокку по мнемоническим соображениям.

elw00d 5 сен 2011 в 06:05

Ухаха, посмотрел бы я на автора, который бы стал разбираться с унаследованным кодом хотя бы мегабайта в два исходников на каком-либо языке с динамической типизацией )) Без Find Usages, без навигации по коду.

Mozzi 5 сен 2011 в 06:05

Откуда столько шума? Вроде давно аксиома: комментировать надо то, что из кода не явно, а это случается довольно редко. Комментирование для автоматической документации, при генерации шаблона (любая IDE или простой редактор это умеет делать) мозг не грузит и времени не отнимает.

Тонны комента, для пары строк кода, зло. Комменты должны дополнять, а не становиться отдельной сущностью, на которой можно сломать мозг, пытаясь их соотнести с кодом.

Что касается моделирования, думаю любой опытный программист подходит к этому процессу итеративно, так что никаких проблем со «сверхмоделированием» для них нет.

arkady 6 сен 2011 в 08:26

> Вроде давно аксиома: комментировать надо то, что из кода не явно

Я бы еще добавил, что однострочный комментарий полезен перед блоком который выполняет некое законченное действие. Например, десяток строчек, который получают значение используемое далее, неплохо снабдить комментарием типа: «Получаем значение X». Тогда, при просмотре кода, не нужно просматривать этот блок вообще — по комментарию будет ясно что здесь «родилось» Х и можно смотреть дальше. Это ускоряет изучение кода и не вынуждает погрязать в несущественных деталях модуля

yateam 5 сен 2011 в 06:07

По-моему у американцев какая-то страсть по пустякам воду лить. прочитал только треть, дальше зевать начал. Какая-то сплошная рефлексия

rukurbanov 5 сен 2011 в 06:24

Ужас, как много букв… смысл статьи, что в комменты нужно писать только самое важное?

Throwable 5 сен 2011 в 06:34

Где-то я видел, что коментарий в коде должен отвечать на вопрос «зачем?», но не на вопрос «как?». Последнее должно быть понятно из кода. Моделирование не есть плохо. Нужно лишь, чтобы модель не была вселенски универсальной и не выходила из области задачи.

Автор упускает огромную группу людей — либюзеров, которые для достижения результата не заморачиваются, а подключают либу мегов на N-цать, зато в которой есть Tuple2 для возвращения двух значений функции. Они не изобретают, они пользуются чужими изобретениями и паттернами. Таких большинство.

Вторыми по списку идут быдлокодеры. Они всегда решают задачу влоб теми нехитрыми средствами, которые осилили овладеть. В итоге код дублируется, триплируется, функционал смешивается в кашу, и наступает момент, когда любое изменение влечет за собой гору отвалившегося функционала. И чтобы изменить что-то, надо перелопатить код в 10 местах.

Третья активно нарастающая группа — это быдлотестеры. Они не понимают для чего нужны тесты, но знают, что TDD — это модно. Поэтому пишут тесты абсолютно для всего — даже геттеров и сеттеров.

А изобретателей-«нубов» на самом деле осталось очень мало. Честь им и хвала! Все должны через это пройти.

P.S. Есть и психологическое объяснение статьи: когда автор был нубом, он работал за идею (интерес). Когда же он повзрослел, он тупо стал работать за деньги. Поэтому все идейные вещи ему стали казаться глупыми: платят не за идею, а за результат, поэтому че напрягаться?

VolCh 5 сен 2011 в 11:27

Узнал себя сразу в двух группах по названиям и описаниям, но как-то то, что пишу тесты для геттеров и сеттеров помогает не дублировать и триплировать код, не устраивать кашу и изменения обычно проходят без перелопачивания кода в 10 местах, а если и требуются в 10 местах, то тесты эти места показывают, включая геттеры и сеттеры.

Throwable 5 сен 2011 в 18:54

При чрезмерном злоупотреблении рудиментарными тестами наступает момент, когда поддержка самих тестов становится многократно сложнее самого кода. Это когда Вы делаете изменение в одном месте в коде, и перелопачиваете 50 тестов.

VolCh 5 сен 2011 в 19:41

До такого не доходило, вернее было что-то похожее, но просто ~~забыл~~не знал, что в тестах тоже не стоит повторять себя :)

Colwin 6 сен 2011 в 04:07

Дублирование кода в трех местах требует переписывания.
Дублирование кода в двух местах требует переписывания, если это не приведет к излишнему усложнению.

ivsedm 5 сен 2011 в 07:20

Автору статьи незачет за агрессивность, завышенное самомнение и много спорных высказываний.

ilyaplot 5 сен 2011 в 07:43

Если обильно комментировать, достаточно сложно держать комменты в актуальном состоянии. Особенно когда взахлеб пишешь код, не отвлекаясь ни на что.

vovich 5 сен 2011 в 07:43

плюсанул за старательность — это ж сколько времени потрачено на статью!!! Но дочитал только до середины.

tangro 5 сен 2011 в 07:50

Мне кажется, есть золотая середина, когда код получается и кратким, и откомментированным и понятным. Ближе всего, к этому, мне кажется, позиция Макконнелла:
1. Короткие методы.
2. Комментарии к публичным методам и их параметрам.
3. Принцип «если код плохо читаем — его нужно отрефакторить, а не писать комментарии».
Вот и всё.

Colwin 6 сен 2011 в 04:08

2. Комментарии к публичным методам и их параметрам.

Под публичными здесь нужно понимать не public-методы, а внешний интерфейс системы или модуля. Внутренних интерфейсов, как правило, слишком много для того, чтобы тратить время на поддержание их в чистоте и порядке.

Colwin 6 сен 2011 в 04:12

1. Короткие методы.

У Макконнелла, помнится, было написано наоборот :-) Приводятся штук 10 практик по написанию хороших методов, а потом сказано, что предложенных выше методик вполне достаточно, и требование о длине методов излишне.
И я с ним согласен.

tangro 6 сен 2011 в 17:19

Я плохо выразился. Коротких не в плане количества строк, а в плане количества логически законченных действий, которые выполняет метод.

НЛО прилетело и опубликовало эту надпись здесь

alist 5 сен 2011 в 12:10

Зря вы так про Стива Йегге — парень писал очень правильные вещи в очень правильное время. Статья очень старая и написана так, чтобы подтолкнуть людей. И да, она написана для новичков, для тех из них, кто с одной стороны достаточно интересуется мнениями в профессии, чтобы на них можно было повлиять, а с другой стороны — достаточно способных, чтобы под влиянием статей они изменились к лучшему и росли как профессионалы. Да, Стив перегибает палку, но считайте это художественным приемом :)

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

Colwin 6 сен 2011 в 04:17

Хорошо мыслите :-) Напомнило притчу.

НЛО прилетело и опубликовало эту надпись здесь

vanxant 5 сен 2011 в 08:18

Такое ощущение, что 90% тех кто отписался выше прочли только верхнюю треть статьи. Ау, люди, статья про метаданные, не про комментарии в коде!

Огромное спасибо за перевод, теперь есть куда тыкать нубов.

GrigoryPerepechko 4 дек 2011 в 10:44

+1. Статья безумно понравилась. Многие подобные мысли в голове давно крутились.

Иногда работая чувствуешь что закопался в проблеме, а проблема то с нулевым business-value. Чистой воды украшательства кода, создание стройной модели, выправление affecting/effecting coupling чтобы пониже был, ну и прочая фигня. И честно признаться я подобного рода задачи возводил в абсолют, мол без хорошей архитектуры проект загнётся и порастёт #овном.

В то же время на проекте был дядька(голандец, senior по западным меркам), который просто делал что нужно. В большинстве случаев максимально просто, максимально быстро, когда ему становилось некомфортно с этим кодом — не задумываяся рефакторил в тот вид что нужно. Buisiness value который он привносил — был огромным, и при этом когда/если позже всплывали недостатки его решений(не баги, а именно архитектурные компромиссы которые не оправдались) — он моментально правил для соответствия текущим требованиям проекта. Он не писал полотна коментов, не писал слишком примитивного когда для идиотов.

И после этой статьи мне все потуги с созданием хорошей архитектуры, и слежением за красотой кода кажутся абсолютной чепухой. И наверное senior это не тот кто 3 года на каком нибудь Epam кнопки нажимал, и выучил 5 паттернов и сует их везде. А тот кто создаст продукт быстро и без онанирования на красоту кода в случае когда она не мешает результату

НЛО прилетело и опубликовало эту надпись здесь

Darksynx 5 сен 2011 в 09:31

Осмелюсь предположить, что те, кто обсуждает комментирование(и я в том числе), прочитали только начало статьи.

НЛО прилетело и опубликовало эту надпись здесь

AlexanderS 5 сен 2011 в 10:41

Осилил только половину текста… Не очень понятно почему так много написано. Очччень много повторов и водички.

Есть труд. Есть результаты труда. Результаты я всегда представляю в виде готового кода и документации на него. В коде описан процесс. В документации — смысл этого процесса и его алгоритмика. Комментарии в коде носят обычно только характер пояснения к документации, т.е. как бы выполняют синхронизирующую роль.
При таком подходе главное — выбрать описываемый «кубик», т.е. ту минимальную часть труда, которую надо так бюрократизировать. Не описывать каждое присвоение, но и не очень крупный процесс )

VolCh 5 сен 2011 в 11:32

При таком подходе главное — выбрать описываемый «кубик», т.е. ту минимальную часть труда, которую надо так бюрократизировать. Не описывать каждое присвоение, но и не очень крупный процесс )

*doc к функциям/процедурам/методам, если придерживаться правила, что они небольшие? :)

AlexanderS 5 сен 2011 в 12:24

Именно)
В *doc же можно засунуть математику, графики и прочую обосновательную ерунду. Я как-то обошелся парой строчек текста и четырмя диаграммами, т.к. из них предельно ясно понятно что, зачем и куда. Пояснения должны быть предельно понятным.
Согласен, что нет ничего хуже такого засилья комментариев, когда разработчик передавая код говорит, что документация абсолютно не потребуется (типа там все есть), т.к. «там все понятно расписано». Начинаешь смотреть, а так как картины в целом еще нет, образуется каша в голове.

Кстати, автор мог бы упомянуть, что комментарии бывают трех видов:
— для себя (вида «При изменении С пересчиать KF1»);
— для других (вида «Блок настройки коммутатора MUX3»);
— магические (вида «Не трогать! Иначе не работает!»).

VolCh 5 сен 2011 в 19:46

По-моему мы о разных *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)
{
...
}

AlexanderS 5 сен 2011 в 20:04

Мы пишем на языках разного назначения, поэтому и непонятки.
Я занимаюсь разработкой прошивок конечнох устройств и использую VHDL для описаня схемотехники для САПРа…

GrigoryPerepechko 4 дек 2011 в 10:48

Результаты — это работающее приложение без багов. А код, документация, диаграмки, и прочие процессуальные экскременты — это факультативно.

galaxie 5 сен 2011 в 10:56

Я будто бы снова вернулся в универ на пары педагогики. Эти же потоки воды низвергающиеся из уст умудренного опытом преподавателя. И та же утрата нити повествования уже на десятой секунде. Butthurt засчитан, я нуб. :(

Colwin 5 сен 2011 в 11:02

Если вы, как менеджер по персоналу или владелец фирмы, вдруг читаете в чьем-то резюме слова о «5-6 лет опыта разработки», то знайте — их нельзя перевести как “опытный”. Это переводится так: чувствующий свою неуязвимость малолетка, с вероятностью 50 на 50 напишет вам кучу дерьма, в которой потом не разберется ни его команда, ни он сам, и которую он вероятнее всего не один раз будет переделывать. Но все это в порядке вещей — любой разработчик бывает подростком в своей профессиональной жизни.

Категорически не согласен с подобными высказываниями.
Здесь очень многое зависит от самоподготовки, и от того, что называть «5-6 лет опыта разработки». Я предпочитаю под этим понимать написание коммерческих приложений. Если же отсчитывать от точки начала программирования вообще… тогда, возможно, автор прав. И то не могу сказать с уверенностью, т.к. у многих программирование начинается с университета, а после выпуска они уже устраиваются на работу. Я шел немного другим путем, и программирование начинал до универа, поэтому мне сложно судить адекватно…

IMHO.

tonsky 7 сен 2011 в 10:36

У меня сейчас семь лет коммерческого программирования, и я понял, что действительно чувствую себя как подросток — море по колено, бросает в крайности, категоричные суждения и т.п. Уже пошло на спад немного, но полтора-два года назад был пик. У Пола Грэма это хакерской натурой называется, но тут более точно ухвачена суть.

Xarakternik 5 сен 2011 в 11:11

О чем пост?
О том, что со временем люди набираются опыта и начинают писать немного по-другому?
Передавайте привет Капитану Очевидность.

rdolgov 5 сен 2011 в 12:12

Ну если так вопросы ставить, то я думаю всё что есть вокруг будет ни о чем, ибо все очевидно после того как познано. Скорее вопрос должен стоять «для чего?» и тут уже всё ясно.

Nashev 6 сен 2011 в 13:26

пост о том, что не стоит увлекаться моделированием.

ComodoHacker 5 сен 2011 в 14:30

Ух, наконец-то перевод чего-то стоящего и дающего пищу для размышлений. Спасибо переводчику (хоть и не без ляпов).

Со многим согласен, в некоторых персонажах узнал знакомые свои черты. Но вот это:

ценой внесения метаданных вы чуть-чуть ухудшаете поддерживаемость, стоимость, гибкость, тестируемость и расширяемость.

осталось для меня парадоксом. Я-то считал, что все наоборот. Видимо я еще настолько нуб, что не могу ухватить глубину мысли.

VolCh 5 сен 2011 в 19:48

Наверное речь идёт о необходимости синхронизировать код, мета- и простые данные.

Nashev 6 сен 2011 в 13:33

Речь идёт о предстоящих проблемах при засовывании многообразия жизни в жёсткие рамки однажды придуманной модели.

vics001 5 сен 2011 в 18:39

Хочу поблагодарить автора (переводчика) за интересную статью. Проблема комментариев действительно остра, но еще более остра проблема метаданных. Когда появились программно используемые метаданные (аннотации), думал, что счастье на земле есть :) Теперь начинаю склоняться к тому, что использование десятка различных аннотаций приводит к потери нити управления, в конечном счете запутанность проявляется еще больше. Пример тому JPA-аннотации, Spring-аннотации, когда уже ничего не видно как работает и как вызывается и вообще уже похоже, что пишешь не на Java, а каком-то дивном языке, по которому надо прочитать еще десяток книжек.

Стоит признать, что интерфейсы как элемент метаданных, очень хорошо прижились и в принципе не вызывают затруднений. Хотя иногда можно задаться вопросом почему не сериализируется или не клонируется некоторый объект. Комментарии хотя бы безвредны, хотя часто и отвлекают от сути.

Я бы сказал, что структура проекта очень важна + необходимость реализовывать функциональные требования с минимальными издержками. Структура помогает при поддержке проекта, а граммотная архитектура при написании новых функций.

borisko 5 сен 2011 в 19:34

Муж (м) — программер, (я) — филолог.
М: Сходи за меня на работу, а?..
Я: Окей, дорогой, буду править ошибки в комментариях твоего кода))
М: Я не комментирую код. То, что писалось тяжело, должно и читаться тяжело.
Я: Лев Толстой, наверное, по такому же принципу работал...

©bash.org.ru

Colwin 7 сен 2011 в 04:27

По-моему, у профессионала что писалось тяжело, должно читаться легко.

alprk 5 сен 2011 в 20:52

Как по мне, комментариев в коде не должно быть. Совсем. Если требуется добавить в код комментарий, этот код нужно переписать. Естественно, документации это не касается.

alprk 6 сен 2011 в 11:32

И меня всегда удивляли люди, которые оскорблялись этой мыслью.

Colwin 7 сен 2011 в 04:28

Например, добавление к функции sort комментария о том, какой алгоритм используется — совсем не лишний.

alprk 7 сен 2011 в 05:59

Совсем лишний, потому что этой информации место в документации к методу.

arkady 6 сен 2011 в 08:33

Странно, никогда не встречал кода с комментариями-рассказами и сам таким никогда не страдал. Щас пересмотрел свои старые бейсик-исходники — везде (как и сейчас) нечастые однострочные комментарии, поясняющие назначение блока. Никогда бы и в голову не пришло писать такие «рассказы» в коде. И как выше заметили, у нас нубы скорее вообще не используют комментарии, чем пишут их избыточно

Nashev 6 сен 2011 в 13:34

У них видимо школа есть, и это в её традициях…

softwareteam 6 сен 2011 в 11:31

Коментарий — это повод для рефакторинга. Если вы пишите коментарий, значит код явно не выражает намерение программиста © Фаулер
Код (а не коментарии) должен рассказывать историю © Бек, Кэнигхем

Colwin 7 сен 2011 в 04:30

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

softwareteam 7 сен 2011 в 09:30

да, хотя в последнее время такие алгоритмы большая редкость

vladoos 6 сен 2011 в 11:56

Я не знаю зачем вообще нужны комментарии на java. В плюсах бывают моменты, когда нужно записать, что делает оператор, типа такого «for(;P(»\\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);", чтобы не забыть самому. А в java нужно сильно постараться, что бы такое сделать.

Nashev 6 сен 2011 в 13:35

парсер — лох?

vladoos 7 сен 2011 в 09:25

Совсем немного, угловые ковычки лишние… а так это реальный оператор языка си :) причем боянистый, погуглите его :)

Colwin 7 сен 2011 в 04:31

Возьмите реализацию того же RSA.

Aniken222 12 сен 2011 в 07:37

наоборот, Python и Ruby становятся все более популярными, чем Java и C++

GrigoryPerepechko 4 дек 2011 в 10:52

По коментариям создалось впечатление, что те кто не понял о чем статья — даже хуже чем нубы. Статья довольно фундаментальная, и даже несмотря на то что дерьмово написана, обсуждает важный вопрос достижения цели в обмен на онанирование на архитектуру, коменты и прочие маразмы которым каждый 5 программист увлеченно занимается и считает себя крутым за это.

НЛО прилетело и опубликовало эту надпись здесь

mrjj 4 фев 2012 в 01:51

Очень, очень, очень глубоко копает.
Когда я был мелким, лет 15, мне досталась дискетка с исходниками простеньких игр, а я сам тоже писал простенькие игры. И там был тривиальный тетрис написанный по всем канонам ООП на щщах с исходниками под 200 кб весом. Исходники моего тетриса занимали 3 кб, несколько массивов, несколько функций плюс отрисовка и обработка прерываний ввода. Я полез внутри и в силу неопытности мало что понял, но расхождение в объеме кода меня поразило.
Поражает и сейчас, хотя я понимаю что 500 классов или 200 таблиц данных это средненький проект.
Из нубства на правильный путь меня направил императив уменьшения сложности. Похрен на идеалогию, методики, похен на все, я не хочу держать в голове 500 классов, эффективно жонглировать в голове я смогу лишь 5 из них а остальное лишь запутает мои попытки понять что происходит.
Любые метаданные это внесение нового уровня сложности.
С другой стороны правильная организация методов и переменных, их правильное наименование — это наше все, это способ заставить код говорить вместо комментариев.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий