Флэш Потрошитель этот | тот | 1.0

Нам часто присылают коды, чтобы мы смотрели на них и говорили, хороши ли они. Насмотревшись на разные, мы поняли, что хорошего кода очень мало. Чтобы помочь нам решить эту проблему, решено опубликовать доселе секретные Унивесальные Правила Хорошего Кода для всех времен и языков программирования. Если ваш код не соответствует на 100 процентов хотя бы одному из нижеперечисленых пунктов, то он не хорош и не нужен. Пришлите этот код нам и мы вместе его улучшим. Итак, правила хорошего кода:

1. Хороший код доставляет удовольствие.

Данный список правил был бы неполным без полного перечня подправил, классифицирующих хороший код по ключевым признакам:

1. Хорошее в работе человека с кодом

До написания кода

• Намеревающему код. Удовольствие от намерения написать хороший код огромно, измеряется годами. Хороший код не появится без намерения, а оно в свою очередь определяется предварительными контактами с другим кодом: хорошим, вдохновляющим как пример или наоборот: плохим, вредным, отталкивающим к хорошему коду, кодом. Нам жаль, если вы сталкивались с дурным кодом, но это было важно для вашего понимания. Постарастесь извлечь из этого практические, конструктивные выводы и хороший код.
• Мечтающему. Столько людей было осчастливлено мечтой о хорошем коде! Обещаниями хорошего кода! Нужно больше хорошего в мечтах и больше сдержанных обещаний.

Во время и после написания

• Пишущему код. Хороший код доставляет удовольствие пишущему его. С другой стороны, без своего пишущего хороший код просто не появится. В этом — самая рискованная часть жизни хорошего кода: чтобы он вышел хорошим, нужно, чтобы он доставил удовольствие своему кодеру еще до своего появления на свет. Для решения этой задачи необходимо, чтобы у кодера имелась в наличии голова. Голова нужна кодеру для совершения в ней предварительного кодирования, после которого должно идти кодирование непосредственное, сопровождаемое мягкими, уверенными нажатиями клавиш.
• Читающему. Крайне важно, чтобы чтение кода приносило быстрое понимание, эстетическое удовольствие и практическое применение. Чтение кода — это самое частое, что с ним происходит, и поэтому это самое главное, что может с ним произойти. Это важнее, чем слушание, созерцание и ощупывание кода, о них ниже. Читайте подробнее о подготовке кода к чтению.
• Смотрящему. Как гласит компилийская поговорка, некрасивый код не заработает, а если заработает, то нехорошо. Без комментариев.
• Слушающему. Если код нельзя положить на красивую мелодию, следует тут же выбросить его на помойку, если улучшение невозможно. Код хотя бы должен читаться на манер популярных японских куплетов, ну там "...лягушка прыгнула в воду".
• Обоняющему. Код должен хорошо пахнуть, но лучше не пахнуть вообще, так надежнее.
• Вкушающему. При чтении во время еды хороший код улучшает пищеварение и настроение. Если хороший код испечь в виде таких, знаете, печенек, то они должны помещаться во рту без откусывания и быстро таять с приятным послевкусием.
• Ощупывающему. После ощупывания кода со всех сторон должно оставаться слабое приятное покалывание в подушечках пальцев.
• Вспоминающему. "В конце девяностых видел один код, который изменил мою жизнь! А состоял он лишь из одной строки..."
• Припоминающему. "А вот в наше время код был! Намного больше, не то что тепер! Хороший код был, выпьем!..."
• Напоминающему: "Помнишь, какой ты код год назад написал, я его долго потом пытался понять да так и не понял, дебажил, да не вышло? Сейчас ты за это ответишь!" [Удар, серия ударов. Глухой стук. Удовольствие от мести (эффективно для порчи собственной кармы)].
• Критикующему: Умелое глумление над определенным кодом может доставить столько удовольствия окружающим, что некоторые коды специально пишутся для доставки удовольствия через их критику. Это т.н. поциент-код. Естественно, исправлять такой код преступно и в Компиляндии исправление поциент-кода карается 40 регулярными выражениями на Материнской Площади.

2. Хороший код по размерам эффективной части кода

• Весь. Хороший код должен доставлять удовольствие и быть приятным в целом. При удержании хорошего кода наперевес не должно ощущаться никакой разбалансировки.
• Файл. При поиске файла с хорошим кодом приятные ощущения играют первоочередную роль, идет подготовка к первому контакту с кодом. Это достигается путем присвоения файлам таких имен, которые как бы заранее объясняют, что за код они содержат, и что этот код хорош, и чем он так хорош. Желательно чтобы файл имел благозвучное имя, которое легко сообщать по телефону даже на шумной дискотеке.
• Экран. Вся видимая в любой момент часть кода должна быть безупречна настолько, чтобы не возникало необходимости ни в скроллинге, ни, конечно, просмотре другого (чужого, плохого, враждебного, нехорошего) кода.
• Строка. Отдельная строка кода должна читаться как гениальное одностишие.
• Слово. Каждое отдельное слово кода должно иметь длину больше нулевой и умещаться по ширине в размер монитора и состоять из идеальных символов.
• Символ. Индивидуальные символы кода должны быть просто безупречны. Ведь весь код состоит из них, без исключений. Важно выбрать правильный шрифт.
• Пробел. Он тоже символ, но роль его уникальна. Пробел является универсальным элементом визуального дизайна кода. Хороший код содержит пробелы разных, но строго детерминированных размеров для управления отступами в коде. Для работы с пробелами существует т.н. функция автоформатирования. Правильное использование пробельных символов упрощает чтение, что, как мы узнали выше, есть важнейшая часть жизни кода.

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

Этот список полностью описывает радость организации и участия в событиях.

Организация событий

1. Организаторы событий — честолюбивые, жадные до всего неудачники.
2. Обратное, в общем случае, неверно.
3. Когда организатор событий умнеет и становится успешным, он перестает заниматься организацией событий.
4. Всякое событие сложнее организовать, чем кажется на первый взгляд.
5. Сложно организовать событие, которым все останутся довольны.
6. В общем случае, событие, которым все останутся довольны, организовать невозможно.
7. В частных случаях это также невозможно.
8. Вообще говоря, сложно организовать событие, которым хотя бы кто-то остался доволен.

Сравнение событий

1. Хороших событий не бывает.
2. Событие А всегда лучше события Б, если событие А было раньше события Б.
3. Это универсальное правило.
4. Событие С лучше события А и события Б, если очень нужно.
5. Это правило также универсальное.

Стоимость событий

1. Бюджет события всегда занижен.
2. Бесплатное событие никому не нужно.
3. Платное событие нужно только тем, кто захочет спросить, почему это событие платное.
4. Организаторы всегда доплачивают из своего кармана.
5. Спонсоры всегда обмануты.
6. Деньги всегда потрачены зря.
7. Три предыдущих правила универсальны.

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

Посещаемость событий

1. На событие никто не придет.
2. Если кто-то все же придет, то он не сможет найти входную дверь.
3. После консультации с организаторами по телефону он найдет дверь, но его не пустит охрана, так как окажется, что он забыл зарегистрироваться.
4. Если вам все же удастся его провести, то окажется, что он забыл в машине ноутбук.
5. А потом окажется, что он пришел спросить, почему это событие платное.
6. Если событие бесплатное, то на нем прозвучит вопрос, почему другое событие было платным.

Ближайшие события

1. IT-TALK-6 в Харькове, 19 марта 2009 (регистрация)
2. Дамский день UAFPUG-10 в Одессе, 21 марта 2009 (регистрация)
3. FLASH GAMM-2 в Москве, 14 мая 2009 (регистрация)

Nano Update: ВНИМАНИЕ! Следующий ниже текст ВЫМЫШЛЕН. Любые совпадения с существующими текстами СЛУЧАЙНЫ. Мы ниже медитируем на тему и это все, что важно.

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

Случай дуализма условной логики в задаче заполучения лицензионного ПО

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

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

Локализуем же зону когнитивного диссонанса

Противоречие находится где-то между этими двумя фразами:

1. У меня нет денег, чтобы купить ПО.
2. Мое время слишком дорого, чтобы тратить его на получение ПО, я провожу время зарабатывая деньги, которых кстати нет на покупку ПО, см. предыдущий пункт.

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

Update: fla-Master приложил интересную картинку, снабдив ее таким комментарием:
Я даже график нарисовал )) С допущениями, конечно, например, что чел как только на софт заработал, так сразу и купил. Но вообще надо понимать, что полученный софт - это тоже доход, только не в денежной форме. Вопрос лишь в скорости зарабатывания...

Рис. 1. Скорость написания статей и зарабатывания денег, относительно.

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

Как может в таком случае выглядеть объявление и инициализация переменных для этого цикла? А вот так.