Делаю почти также, только label с фиксированной шириной, позволяет выравнивать другие элементы в форме относительно полей ввода без особых хлопот.
Взгляните также на Uni-From (http://sprawsm.com/uni-form/) — гибкая и дивная.
Жестоко. В последнее время присваиваю body класс с именем движка, броузера и его версии, а также ОС.
Например, для Firefox 3 «gecko firefox3 win», и уже можно специфицировать стили под конкретной движок/браузер/ОС.
То есть, чтобы зарегистрироваться мне надо вбить неправильные логин и пароль? Не вполне очевидно и не совсем логично. Может у меня капслок включен, а может раскладка не та…
Можно добавить анти-паттерн «Бездумное комментирование».
Работаю с кодом где полно комментариев вида
«end if here»
«end code here»
«added by Ahmed»
" — MAIN CODE START HERE -----------"
Есть комментарии построенные в форме в вопросительной форме.
Никакой полезной информации они не несут, но претендуют на комментированный код.
Лучше писать код понятно, чем объяснять, что же ты написал.
Сейчас работаем над одним проектом, который достался от пакистанцев.
Там есть все мыслимые и немыслимые анти-паттерны.
Теперь с благоговением вспоминаю Фаулера и рефакторю, рефакторю…
Однако…
Лучше начинать (в мыслях) неделю с воскресенья, тогда понедельник это второй день недели и не так тяжело идти на работу. :-)
It's all in my head…
Замечание справедливое, но как уже было замечено, хороший код не означает хорошее приложение (с точки зрения архитектуры).
Определил для себя следующую политику комментирования. Если функция/класс будет доступно как публичное API, то методы комментирую обязательно (чтобы потом можно не парясь составить API). Если нет, то просто стараюсь писать структурировано и давать понятные имена методов и переменных, комментирую сложные места кода + @todo, где что-то надо доделать.
Количество скачиваний чего? Фильмов?
Я не думаю, что на многих «киносайтах» фильмы доступны для скачивания.
А по мне, так рейтинги нужны, лишний параметр при выборе лишним не будет.
Взгляните также на Uni-From (http://sprawsm.com/uni-form/) — гибкая и дивная.
Например, для Firefox 3 «gecko firefox3 win», и уже можно специфицировать стили под конкретной движок/браузер/ОС.
Работаю с кодом где полно комментариев вида
«end if here»
«end code here»
«added by Ahmed»
" — MAIN CODE START HERE -----------"
Есть комментарии построенные в форме в вопросительной форме.
Никакой полезной информации они не несут, но претендуют на комментированный код.
Лучше писать код понятно, чем объяснять, что же ты написал.
Там есть все мыслимые и немыслимые анти-паттерны.
Теперь с благоговением вспоминаю Фаулера и рефакторю, рефакторю…
Лучше начинать (в мыслях) неделю с воскресенья, тогда понедельник это второй день недели и не так тяжело идти на работу. :-)
It's all in my head…
По крайней мере поможет не ошибаться в правописании.
Определил для себя следующую политику комментирования. Если функция/класс будет доступно как публичное API, то методы комментирую обязательно (чтобы потом можно не парясь составить API). Если нет, то просто стараюсь писать структурировано и давать понятные имена методов и переменных, комментирую сложные места кода + @todo, где что-то надо доделать.
Кстати, а на хабре какой типограф используется?
Я не думаю, что на многих «киносайтах» фильмы доступны для скачивания.
А по мне, так рейтинги нужны, лишний параметр при выборе лишним не будет.
Это что-то типы «Битвы экстрасенсов»?
Не вижу логики в ваших рассуждениях.