Правило очень простое:
Если ты не следуешь одному стилю кодирования в проекте, ты мудак.
Это правило не обсуждается, и никаких других интерпретаций быть не может.
Правило относится к числу так называемых командных правил. Оно расширяется до следующей формулировки:
Если команда не следует единому стилю кодирования в проекте, каждый член команды — мудак.
Код независимо от того, сколько человек над ним работает, должен выглядеть так, как будто он написан одним человеком.
Это важно, потому что облегчает понимание кода текущей командой в будущем и упрощает введение в проект новых людей. Для индивидуального разработчика правило тоже имеет смысл, поскольку единый стиль со временем устройняет код, укрепляет мозги, структурирует инженерное видение, делает человека дороже на рынке труда.
Почти для каждого языка программирования существуют автоматические средства проверки стиля кодирования. Необходимо в своей команде настроить их таким образом, чтобы без проверки формальных требований ко внешнему виду код даже не доходил до просмотра людьми (код-ревью). C помощью дешёвого машинного труда освобождается часть дорогого человеческого времени (см. правило про автоматизацию).
(В команде Сиджеко код даже не попадёт в основной репозиторий, пока не будет выглядеть красиво.)
Правило очень простое:
Если ты заставляешь человека делать работу, с которой прекрасно справляется машина, ты мудак.
За контрпримерами далеко ходить не надо. Вот цитата со страницы отслеживания почтовых отправлений Почты России:
Почтовый идентификатор находится в чеке, выдаваемом при приеме почтового отправления.
Вид номера: 115127(80)15138 4. Следует вводить:
Почтовый идентификатор: 11512780151384 (весь номер без скобок и пробелов).В случае отслеживания международного почтового отправления и EMS-отправления необходимо вводить 4 буквы и 9 цифр. Буквы вводятся обязательно ЗАГЛАВНЫЕ и в латинском алфавите.
Пример: YF123456789RU (весь номер без пробелов).
Почему, о, тупейший из тупейших, я должен это всё делать? С какой целью? Чтобы тебе было удобнее искать значение в базе данных? Пусть программа сама уберёт пробелы и скобки, приведёт символы к нужному регистру, заменит кириллические буквы на похожие латинские (раз только такие и могут быть). Почему я должен тратить несколько секунд или минут на работу, с которой компьютер справляется за несколько микросекунд.
Это настолько просто, что займёт не больше 15-20 минут на написание кода.
См. также: Правило про Юникод.
Правило очень простое:
Если твоя программа не использует Юникод, ты мудак.
Это правило не обсуждается, и никаких других интерпретаций быть не может.
Юникод-кодировок несколько, но лучше всего использовать UTF-8 по причине его обратной совместимости с базовой 7-битной таблицей ASCII, а также общей гениальности архитектуры (круче никто не сделал).
В идеале, конечно, Юникод должен использоваться и в базе данных, и в файлах, и в исходном коде программы, но здесь, само собой, всё зависит от выбранных языков и технологий. С другой стороны, почему в 21 веке всё ещё существуют языки программирования, которые не переваривают исходные тексты программ в многобайтовой кодировке, технологии, поддерживающие только однобайтовые кодировки, и использующие их люди, для нормального инженера должно быть загадкой.
Историю вопроса можно описать одним абзацем. Поскольку основные компьютерные технологии придуманы западным миром, они изначально были рассчитаны только на английский язык и латинский алфавит. Но потом внезапно оказалось, что компьютеры нужны всем, а программисты — люди ленивые, поэтому переучиваются неохотно и медленно. Посему мы до сих пор встречаем эти осколки прошлого, однако брать с них пример — нездоровая идея.
См. также: Правило про автоматизацию.
Судя по дате файла, это четверостишие было написано мной 10 октября 2008 года. Помнится, оно должно было напеваться на мотив куплета песни «Звезда рок-н-ролла» группы «Сплин» (или похоже).
Полноценной песней или кавером этому глупому тексту стать было не суждено, поэтому пусть остаётся здесь.
/* * Рождённая бага должна умереть — аксиома. * Чтоб фичей родиться и снова потом умереть. * Эксепшн пронзит километры исходного кода, * Нарушив программерский смех. */
Я ничего не понимаю в CSS-вёрстке. Вообще. Особенно
в её позиционной части. Как только я вижу
в стилях position: absolute
или float: left
, в моём мозгу происходит
короткое замыкание, и он отказывается воспринимать код дальше,
смотря на то, что он знает, что делает
это правило. Я замечаю различие в тенях в один
пиксель, вижу разницу в оттенке градиента, могу отличить
хорошую вёрстку от плохой (у меня есть сверхсекретный
набор тестов, которые знаю только я, и никогда
из моих уст не узнает ни один верстальщик),
но при этом я не готов изучать,
как это было достигнуто. Разумеется,
я в курсе различий CSS2
и CSS3, слежу
за развитием HTML5
и черновиков CSS4,
но я не могу верстать в промышленных масштабах,
на потоке. Я знаю что делает то или иное
правило, но не понимаю, как стили работают в комплексе,
и как надо порезать дизайн-макет, чтобы создать из него
веб-страницу.
Именно по этой причине в Сиджеко работали, работают и будут работать лучшие верстальщики и клиентские кодеры в окру́ге. В то время, как в других конторах этим на коленке занимаются программисты, которые в основное время делают бизнес-логику. Программисты не должны верстать в компаниях. Никогда. Точка. Программисты должны учить теорию вероятностей и программировать. А после этого, когда они перестанут быть тупыми дебилами, могут и попробовать поверстать. Но только для себя, пожалуйста. Потому что всё равно сделают через задницу.
Причём веб-сообщество делает всё, чтобы даже быдлокодер умел верстать. Умер Internet Explorer 6 (почти), необычайно распространился WebKit, появились CSS-фреймворки и всевозможные Javascript-плагины. Но всё равно у программистов не получается вёрстка, точно так же, как пять-десять лет назад.
Думаете, ваши-то программисты уж наверняка не такие и точно умеют верстать? Не обольщайтесь, не умеют.
Сегодня я обожаю веб-программирование ровно с такой же силой, с какой ненавидел его и любил настольное программирование шесть лет назад.