Link and Script tags

Когда объявляем стили или яваскрипты, названия лучше писать в самом начале тега. Чтоб при прочтении сразу было понятно, что за файл. Зачем нам читать всякие type и rel и т.д. если они для чтения кода человеком вообще нафиг не нужны.

<link href="css/style.css" type="text/css" rel="stylesheet"/>

Читаю очень умную книжку - "Чистый код" Роберт Мартин (Robert C. Martin "Clean Code") 2010г.
Пока до половины только прочел...

В предисловии к книге автор допускает, что с его мнениями можно не согласиться. Вот я и не соглашаюсь по одному из них.
На странице 90 (в книжном варианте, иначе 91) автор пишет, про избыточность обязательных комментариев Javadoc (про это там еще где-то написано). И я ни сколько не сомневаюсь в уме этого товарища.
Только он забывает, что по этим комментариям потом можно будет собрать отличное руководство по проекту, в том числе и по классам. О коде-то он позаботился, а что с проектом делать потом, когда все комменты почистить? Люди упрощают создание мануала, понимаешь, а он тут раз и нафиг все.

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

А в php IDE еще и читает эти комментарии и с помощью них восполняет отсутствие строгой типизации в php. К примеру, напишите такое:

/**
* @return UserObject
*/
public function getSomeUsers(){
$userObject = new UserObject();
...
return $userObject;
}
И когда вы будите использовать что-то возвращенное этой функцией, IDE поймет, что вы пользуетесь объектом UserObject!



Ну даже и без этого, все равно можно не согласиться с избыточностью  комментариев.
Вот переменная: duration - Продолжительность воспроизведения в минутах. А как узнать без комментариев в минутах или в часах эта самая продолжительность?
Кстати, если называть durationInMinutes, то это еще тот бред, а если в часах понадобиться, переназывать переменную и свойство класса? так это ж рехнуться можно будет...




PS: кстати у него в коде там ошибка, или не у него, там где он его брал в общем.

Слушай и проверяй

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

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

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

И так, сначала смотрим на то, что обсуждаем, а затем продолжаем обсуждение.

В Базах Данных никогда нельзя писать названия баз, таблиц, процедур, функций и т.д., используя верхний регистр.

Ошибиться в регистре очень легко. К примеру, как писать Id или ID. Все пишут по разному, как им захочется и согласно своей внутренней логике, временами на совпадающей с логикой другого программиста.

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

Если ни как не получается найти ошибку в коде, перепишите код с "нуля".

лучше один вызов, чем два

Не забываем, что:

$var = function();
if(!$var){
    $var = newFunction();
}
echo $var;

работает быстрее чем:

if(function()){
    $var = function();
}else{
    $var = newFunction();
}
echo $var;

Второй способ к тому же вообще не правильный.

кавычки

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

Основной довод не использования двойных кавычек это, конечно, скорость.

Глобальные переменные

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

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

random или псевдо-случайные числа.

Речь пойдет о стандартной функции в php.

rand() -  Generate a random integer.

Однажды ночью обнаружилась  принеприятнейшая ситуация. Тестим мы сервак на высоконагруженность, бомбя его большим количеством соединения за короткий промежуток времени. И тут в одном месте видим потерю соединений в 70-80% случаях. Немного прифигев. т.к. к базе обращений очень мало, циклов больших по проекту не ожидалось..., начали искать...
Долго искали в разных местах...
А была, казалось бы, безобидная функция... Из массива случайно выбиралось значение, потом выбиралось следующее случайное, но с проверкой, чтоб они не совпадали... получалась рекурсия...
И, видимо, при частых обращениях у rand() наступал кондратий, возвращая одинаковые значения, от чего наша рекурсия стремилась к бесконечности. Стоило убрать проверку равенства случайных чисел и все заработало без проблем.

И так:

Никогда не сравнивайте случайные значения.

Ищите либо другой способ реализации функционала, либо удостовертесь, чтоб такая проверка не попадала под большие нагрузки.

Кстати, это же касается и функции random() в MySQL и PostgreSQL.
При очень высокой частоте соединений, такой запрос:

select * from table random() limit 2;

может положить сервак.

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

Про id и таблицы

И сегодня о таблицах...

В cross таблицах, в качестве ключей, должны храниться только(!) идентификаторы (id) таблиц.

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

Казалось бы, это и так понятно, и все так и делают... А нет, не все. Ну а раз не все, значит это надо  записать и показать тем, кто делает не правильно.

Лень матушка.

Давно собирался об этом написать, сегодня только руки дошли.
Сегодняшнее правило:

Ни когда не ленитесь, когда пишите код.

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

Даты в названии.

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

Даты пишутся только цифрами, разделенные тире(дефисом)(или другим символом, если необходимо). Первым пишем год, вторым - месяц, третьим - день.
blablabla_2011-01-06.txt

Небольшая поправка:
В компилируемых файлах даты можно приписывать к расширению, дабы избегать их компиляции.
(blablabla.erl_2011-01-06).

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

Данные в JavaScript

Со временем выработалось важное правило:

Хранить данные в яваскриптах (javascript).

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

Статистическая модель.

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

Собственно правило:

Не писать статичных моделей.



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


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