Мои любимые ошибки в программировании

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

Главный вывод: учить матчасть и думать перед тем, как что-то делаешь.
Деньги и плавающая точка — зло.

Я поразмыслил над этим случаем и установил, что следует:
1. Избегать работать поздно ночью

Как я вас понимаю… У самого после ночных бдений порой случаются «провалы», но отучить себя от этого не выходит…

Насчёт дат — нужно не изобретать колесо и использовать возможности базы.
Для MySQL выборка за прошедшую неделю выглядет так: SELECT * FROM `table` WHERE `datetime_field` >= NOW() — INTERVAL 1 WEEK
И.т.д., у MySQL весьма обширный список функций по работе с датами и такие вещи как летнее время уже обрабатываются за нас.

Из одной крайности в другую. А почему бы не хранить и передавать данные в зашифрованном виде? (с ключами достаточной для будущих мощностей криптостойкости)

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

Но перевод хромает… Местами очень напоминает гугл, подвергшийся рерайту. Например:

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

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

я может чего не понимаю…
а почему для дебага нельзя использовать site.com/page.aspx?debug=1?

Было бы еще хорошо узнать, как работать с деньгами правильно.
Сейчас есть один проектик, в котором деньги приодят в рублях, переводятся в доллары и кладутся флоатом в базу…

Я теряюсь — что с этим делать?

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

Взял за правило быть вежливым даже в комментариях. Их может никто и не видит, но мало ли…

А может просто не стоит вести разработку и тестирование на продакшн сервере, не? Я с php не работаю, это там так принято разрабатывать/дебажить? белый список ip дебагеров очень мило :)

стараюсь использовать 2 конфига (production и development) в которых храню все настройки
и далее примерно так:
switch ($_SERVER['SERVER_NAME']) {
case 'www.site.com':
case 'site.com':
case 'aliasOfsite.com':
define('MODE', "production");
break;
default:
define('MODE', "development");
break;
}


Строил собаке будку, сделал огромное количество ошибок:

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

Выходит все строители г…

> … угадайте, что будет возвращаться, если вы запустите следующее?
>
> SELECT * FROM products WHERE category='retro clothing';
>
> Ответ – ничего, поскольку колонка категории длиной всего в 10 символов, так что категория последнего продукта урезана до retro clot.

Если проверять warnings, то подобное можно заметить после первого же INSERT-а или хотя бы сразу понять почему SELECT возвращает неверный результат.

> Перевод часов
>
> Я бы не назвал эту ошибку «погрешностью». Она появляется при особых редких обстоятельствах,…

Вызвало улыбку, потому что по bogus-ам «перестали работать timestamp/даты в MySQL» я определяю приход весны и осени: редкие обстоятельства на миллионах инсталляций дают эффект =)

Статья в целом хорошая и полезная.

Дебажу всегда в error_log с названием класса и номером строки, очень удобно
А после случая, когда админы напортачили и файл index.php отдался как текст, я стал писать в нём только одну строчку => require '../index.php' // который, естественно, не виден снаружи

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

Удивительно, но эта ошибка встречается очень часто (слишком часто!) и приводит к очень неприятным последствиям.
Добавлю, что в некоторых языках программирования и СУБД аналогичные типы могут называться Numeric, Currency или Money (а также smallmoney).

Я бы распечатал такой плакат и дал каждому разработчику, имеющему дело с денежными суммами.

Теперь у меня было четыре строчки весьма сложного кода, чтобы сделать одну очень простую вещь. Сегодня, пока я писал эту статью, я обнаружил встроенную в Javascript функцию, которая справится со всем этим:

<script type="text/javascript">
function GetMoney (amount) {return amount.toFixed (2);}
alert (GetMoney (4.9995) + ' ' + GetMoney (0.1 * 0.7));
</script>

Автор (оригинала) явно неполноценно тестировал то, что написал и не знает про баг с функцией toFixed() :)

Тестовый «эксплойт»:

alert([1.1255.toFixed(3), 0.1255.toFixed(3)]) // 1.125,0.126 - FF5, Chrome12, Opera 11.5
</script>

— на данный момент даёт ошибку в FF5, Chrome12, Opera 11.5. Не даёт ошибки в IE8, Safari5.

Или с использованием функции автора:

<script>
function GetMoney (amount) {return amount.toFixed(2);}
alert([GetMoney(1.155), GetMoney(0.155)]) // 1.16,0.15 - FF5, Chrome12
</script>

Такую ошибку даёт в FF5 и Хроме, но не факт, что Опера застрахована от ошибок для .toFixed(2).

Насчет рассылок. Тут надежнее всего таки не позволить письму отправиться куда не надо.
Для этого достаточно двух вещей:
1. тестировать рассылки только на dev-сервере
2. отправлять письма только по какому-то фильтру. У нас на работе, например, используется RoundCube с фильтром по нашим рабочим адресам. Остальные письма просто складываются на сервер и их можно просмотреть.

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

define(DEVELOPER_IP, '212.121.212.121'); // assign office IP
define(SHOWDEBUG, $_SERVER['REMOTE_ADDR'] == DEVELOPER_IP); // show DEBUG only for office IP

// настройка ini-переменных
ini_set('error_reporting', 'E_ALL & ~E_NOTICE');
error_reporting(E_ALL & ~E_NOTICE);
# /doc/root/../logs/errors.log, файл необходимо предварительно создать!
ini_set('error_log', implode(DIRECTORY_SEPARATOR, array($_SERVER['DOCUMENT_ROOT'], '..', 'logs', 'errors.log')));
if (SHOWDEBUG):
// show errors and warnings
ini_set('display_errors', 'On');
ini_set('display_startup_errors', 'On');
ini_set('log_errors', 'Off');
ini_set('html_errors', 'On');
ini_set('track_errors', 'On'); # If enabled, the last error message will always be present in the variable $php_errormsg
else:
// disable errors and warnings
ini_set('display_errors', 'Off');
ini_set('display_startup_errors', 'Off');
ini_set('log_errors', 'On');
ini_set('html_errors', 'Off');
ini_set('ignore_repeated_errors', 'On');
ini_set('ignore_repeated_source', 'On');
ini_set('track_errors', 'Off'); # If enabled, the last error message will always be present in the variable $php_errormsg
endif;

Да, с часами прикольно получилось, очень немногие знают все силу *nix'овой date.