Я насчёт windowsAPI
замечания
1.накоторые функции трубуют, чтобы под все их
параметры - указатели было выделено достаточно памяти(getvolumeinformation, например)
2.некоторые функции через VARвыдают
Pchar, данные в котором разделены #0 (stringlist пролетает)
проблема решается :

FOR i:=0 to ... do
if p[i] = #0 then p[i]:=' ';

3.после данных идёт "мусор" на величину оставшийся
распределёной памяти

Что-то меня сюда занесло. Вот и решил выложить одно наблюдение. А заодно и попытаться возродить полезную тему.

Не очень часто, но с завидной регулярностью встречаются ошибки, связанные с непониманием асинхронных процессов. Типа, пишет человек работу с устройством, подключенным через COM-порт. Посылает он в порт команду, а следующим оператором считывает из порта результат. Естественно, результат оказывается совсем не тот, который нужен. Пытается гонять под отладчиком, все работает нормально. Непонимание на лице и вопросы на Круглом Столе.

Другой типичный пример такого рода ошибок -- непонимание того, что зачастую изменения определеных свойств компонент реализованы через пересылку сообщенй. Соответственно, значение не будет изменено, пока не отработает процедура пользователя (про ProcessMessages такой человек, естественно, тоже не имеет никакого представления). Результат тот же: при выполнении программа глючит, под отладчиком работает как надо.

P.S. После первых двух разборок с подобными ляпами хотел было написать в Подводные Камни, но не сумел сходу выдержать принятый там стиль изложения и отложил до лучших времен. А вот тут нашел тему, где можно излагать свободным стилем и обрадовался :-)

А материальчик-то начинает накапливаться...

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

Привет, NO! Неплохой списочек огласил.
Расписать это всё, "как для маленьких детей" (с) Dimentiy. Попытаться классифицировать, структурировать.
"Медвежьи услуги" - целый класс особо вредных ошибко-возбудителей, и не только от Microsoft; хорошая тема для диссертации.

Мои любимые ошибки и как этого добиться.
1.Плюс-минус единица - индексы в [отрезках],(интервалах),[полуинтервалах).
-непривычное описание массива - [0.. или [1.. или ..max-1]
-деление строки на подстроки - средний символ должен попасть в одну из половин
-2 вида счетчиков: указывает на последний занятый или на первый свободный
элемент буфера
2."Access Violation" - стрелка без компаса.
-использование неинициализированного указателя. NT, 2000 чистят память перед
запуском программы, поэтому указали часто =nil, медвежья услуга MS.
-обращение по nil'у. Полезно в mylib.pas  иметь процедуру notnil(p:pointer), а
ее код поставить внутри {$IFDEF DEBUG}
3.Утечка памяти.
-owner=nil
-exit'ы
-нет finalization
4.Синхронизация.
-при включенной оптимизации for может выполняться в обратную сторону
-во время Application.ProcessMessages происходит рекурсивный вызов;
-дебагер позволяет ставить прерывания на присвоение в Watch
5.Логические ошибки.
-если не пользуетесь UML, то хотя бы положите перед клавиатурой лист
бумаги и все нарисуйте.
-всему давайте имена, и объектам и условиям. При программировании возникают

интуитивные образы легко перепутать.
6.Забывчивость.
-поле в описании класса добавили, а в инициализации и обработке не прописали
-ставьте комментарии типа //!
-если ошибку нашли, то это была ошибка не в программе, а в Вашем уме,
поэтому проверьте что вы еще похожего могли наваять.
7.Путаница.
-ничего не оптимизируйте пока не работает
-пишите сверху вниз, лучше иметь кучу заглушек, чем не нужный код.
-лучше официально оставить ошибку, чем срочно рушить все остальное, люди
жили без вашей программы, проживут и без ее кусочка.
8.Начальство.
-постановка задачи это уже программирование, за это платят Вам а не боссу,
как бы он напорист не был.
9.Проверяйте входящие данные. Мир не Вы писали.

Народ, я так понимаю, что грабли они и в Африке грабли. У каждого программера свои грабли. Одни их прошли и забыли, вторые только подбираются к ним. Причем грабли могут быть как сотворенные программером, так и сотворенные другими программерами. А этот проект задумывался как нечто, помогающее найти, где валяются грабли и благополучно их обойти.
В таком случае надо будет делать поисковик - это я не к тому, что граблей будет много :-) (хотя может и так...) Просто иногда очень трудно найти хотя бы в том же MSDN то, что тебе нужно. И дело не в том, что искать не умею - дело в том, что я знаю, чего хочу, но не знаю, как ЭТО обозвали программеры от Микрософт. Думаю, кто с таким же сталкивался - тот меня поймет. Просто иногда получается, что если я хочу узнать, как мне, например, сделать мультипотоковый обработчик сокетов, мне надо перевернуть гору документации, а потом сотворить нечто, вроде как бы и работающее... Потом через месяц возвращаюсь к исходникам и перелопачиваю алгоритм...
Короче, я "за" проект. Вот только вопрос - будет ли он только Дельфийским? Я пишу на BC++B, а это, как известно, тот же Delphi, но с СИшным синтаксисом... :-)) Но все же различия между языками есть, соответственно, и грабли будут различаться...

Анализируя вопросы в наш support, и опыт преподавания Delphi нашим сотрудникам, могу сказать, что для разного уровня программистов свойственны разные грабли :))) Так что все это можно объеденить, даже было бы нужно, но вот кто будет тратить свое драгоценное время? И какого уровня познаний будут эти люди?

А пока вот 2 глюка на которые наступают почти все (на начальном уровне):

================================
1.

Название: Непонимание создания и освобождения компонента "руцями"
Симптомы: AV в освобождении форм, классов, контролов...
Как делают:
Создают компонент, в конструкторе другого компонента например, и указывают Owner. А потом в деструкторе, или еще, где освобождают этот компонент... Например:

В конструкторе

MyComponent := TMyComponent.Create(Self {Form1, etc.});

В деструкторе

MyComponent.Free;

Как надо:
Если Owner, при создании, задается не nil, то об удалении такого компонента позаботится его овнер. ПРИ Owner <> nil "РУЦЯМИ" КОМПОНЕНТ ОСВОБОЖДАТЬ НЕ НАДО :)))

================================
2.

Название: Непонимание класса и переменной типа класс.
Симптомы: Страшные и непонятные глюки при создании более одной копии объекта. AV в разных, непонятных местах.
Как делают:
В методах класса (чаще всего формы), используют переменную классового типа для задания свойств или вызова методов. Например:

type
  TMyForm = class(TForm)
...
  end;

var
  MyForm: TMyForm;

А в методах TMyForm делают что-то типа такого:

procedure TMyForm.FormShow(Sender: TObject) ;
begin
  MyForm.Caption := 'Visible';
  MyForm.Timer1.Enabled := True;
end;

Как надо:
Не использовать переменную, а использовать свойства и методы класса, иначе 2 копия класса будет “ломать дрова” с первой копией…

procedure TMyForm.FormShow(Sender: TObject) ;
begin
  Caption := 'Visible';
  Timer1.Enabled := True;
end;

================================

Это так, для начала, а вообще полно разных FAQов….

====================
KARPOLAN,
ABF software, Inc. - custom software development and web design.
Borland Technology Partner.
Member of Association of Shareware Professionals (ASP)
mailto:karpolan@ABFsoftware.com
http://www.ABFsoftware.com
http://www.ValueConverter.com - Measurement units converter.

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

Да, забыла сказать:
Анна права, не стоит помещать туда нерешенные задачи.
Но прав и muh, есть "камни", которые исправить нельзя, но найден  путь обхода этих грабель. Хотя, этот путь и можно считать решением на конкретном этапе нашего развития :о)

В общем, не будем плодить сущности, не будем устраивать филиала Круглого стола.
Идет?