Все технические форумы на одном сайте Удобный поиск информации с популярных форумов в одном месте
Вопрос: ПРАВИЛА ФОРУМА. Прочтите перед тем как задавать вопрос!

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


Итак:
1. Здесь обсуждается:
Visual Basic (версия до 6.0 включительно)
Visual Basic for Application (VBA) - встроенный в приложения Microsoft Office
VBScript (VBS)

Здесь НЕ обсуждается:
VB.NET (Visual Studio 20xx) - есть специальная группа форумов "Microsoft.NET"
VBA для Acсess - есть отдельный форум по Acсess в группе форумов "Использование СУБД".

Не забывайте указывать в своих темах среду разработки, к которой относится ваш вопрос!


2. Форум существует уже давно, и вероятность того, что ваш вопрос уже обсуждался, довольно велика. Поэтому, прежде чем задать свой вопрос, воспользуйтесь поиском. Если вопрос уже обсуждался, то ответами вам, скорее всего, будут линки на схожие темы. И, возможно, раздражение участников. Уважайте их время и они ответят вам тем же.

3. Не стоит беспокоиться о привлечении внимания темами типа "ПОМОГИТЕ!!!!!". Это считается дурным тоном и нисколько не приближает вас к получению ответа. Снова же, цените время отвечающих вам участников. Четко сформулированная тема вопроса скорее привлечет внимание человека, который действительно может вам помочь, и напротив, крики души а также бессмысленные "вопрос", "проблема", "не работает" - могут быть проигнорированы.

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

4. Код в студию. Штатные телепаты форума в отпуске ввиду острого переутомления.
Описания проблемы недостаточно. Проиллюстрируйте ее участком кода который вызывает проблему, отформатировав его тэгом [src VBA][/src] (подробнее про оформление сообщений - в FAQ). Укажите также строку на которой происходит ошибка и оригинальное сообщение об ошибке. Не нужно его переводить своими словами, это только ведет к путанице.
Как вариант, можете приложить скриншот с сообщением, возможности форума это позволяют.

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

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

7. ЗАПРЕЩЕНО публиковать серийные ключи или иные способы взлома ПО в целом и отдельных компонентов, также ЗАПРЕЩЕН поиск ключей/способов взлома ПО или компонентов.


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

Это рекомендуется прочесть школьникам/студентам.

Magnus
(ред. Shocker.Pro)
Ответ: Как правильно задавать вопросы
Eric Steven Raymond, Rick Moen

Введение

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

Прежде всего, надо понять, что экспертам на самом деле нравятся сложные проблемы и хорошие, способные расшевелить мозги, вопросы об этих проблемах. Если бы нам это не нравилось, мы не были бы экспертами. Если задать нам интересный вопрос, требующий продолжительных размышлений, мы будем за него благодарны; хорошие вопросы - это стимул и подарок. Хорошие вопросы помогают лучше понять предмет и часто вскрывают проблемы, которых ранее не замечали или о которых не задумывались. Из уст эксперта: "Хороший вопрос!" - это большой и искренний комплимент.

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

Мы, без сомнения, неприязненно относимся к людям, предположительно не желающим подумать или поучиться прежде, чем задавать вопросы. Такие люди убивают время — они берут, ничего не давая взамен, они отнимают время, которое мы могли бы посвятить другому вопросу, более интересному, и другому человеку, более достойному ответа.

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

Если эта позиция кажется вам смешной, высокомерной или заносчивой, вы ошибаетесь. Мы не просим вас на нас молиться — фактически, большинство из нас хотели бы общаться с вами на равных и принять вас в свою культуру, если вы приложите необходимые для этого усилия. Но для нас просто неэффективно пытаться помочь людям, которые не хотят помочь себе сами. Быть грубым - нормально, а вот прикидываться идиотом - нет.

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

Если вы решили обратиться к нам за помощью, не становитесь в позицию неудачника. И не ведите себя как неудачник. Лучший способ получить быстрый и чуткий ответ, - спрашивать как победитель — спрашивать как человек умный, уверенный в себе и знающий, которому просто понадобилась помощь при решении одной конкретной проблемы.

Прежде, чем спрашивать...

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

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

    Используйте приемы типа поиска в Google по тексту полученного сообщения об ошибке. Это может привести либо непосредственно к документации, посвященной тому, как эту ошибку устранить, либо к дискуссии на форуме или в блоге, в которой можно будет найти ответ. Даже если ответ и не найдется, фраза: "Я поискал в Google по следующему запросу, нашел то-то и то-то (ссылки), но оно не помогло" пригодится при обращении за помощью.

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

    Если ваш вопрос строится на ошибочных предположениях, любой эксперт, скорее всего, даст бесполезный буквальный ответ, подумав при этом "Глупый вопрос...", и надеясь, что получение того, о чем вы просили, вместо того, что действительно нужно, чему-то вас научит.
    Шерлок Холмс и доктор Ватсон летят на воздушном шаре. Попадают в густой туман и перестают понимать, где находятся. Тут небольшой просвет — и они видят на земле человека.
    — Уважаемый, не подскажете ли, где мы находимся?
    Тот долго думает, потом отвечает:
    — В корзине воздушного шара, сэр.


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

    С другой стороны, неплохо сразу ясно дать понять, что вы можете и хотите помочь в процессе выработки решения. На вопросы типа "Может ли кто-то подсказать?", "Что не учтено в моем примере?" и "А нет ли сайта, который стоит на эту тему посмотреть?" более вероятно будет получен ответ, чем на требование прислать точную последовательность действий для решения проблемы, поскольку вы явно показали, что решите проблему сами, если кто-то укажет вам правильное направление действий.

    Когда спрашиваете...

    Правильно выбирайте форум

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

    Эксперты игнорируют вопросы, направленные не по адресу, чтобы не загружать свои каналы связи не относящейся к делу информацией. Не стоит попадать в этот разряд вопросов.

    Просмотрите список форумов и выберите наиболее подходящий теме вашего вопроса. Например, если вы делаете запрос из Visual Basic к базе данных MSSQL, и столкнулись с проблемой, как написать SQL-запрос, лучше задать этот вопрос на форуме по MSSQL, опустив технические подробности о среде выполнения и сосредоточившись на SQL-запросе.

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

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

    Завершение вопроса фразой "Ответ, пожалуйста, направляйте по адресу... " делает получение ответа весьма маловероятным. Если у вас времени просматривать свою ветку или желания подписаться на оповещения о новых ответах, то у нас нет и пары секунд на то, чтобы подумать о вашей проблеме.

    Пишите понятным языком, соблюдая правила грамматики и лексики

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

    Поэтому четкость и правильность формулировки вопроса имеет значение. Если вы не хотите морочить себе этим голову, мы не хотим морочить голову себе, уделяя внимание таким вопросам. Постарайтесь сформулировать вопрос правильным языком. Он не должен быть тяжеловесным и формальным — на самом деле, здесь ценится неформальный, полный сленга и юмора язык, используемый правильно. Но мысли должны быть выражены четко; необходимо продемонстрировать хоть какие-то признаки вдумчивости и внимания.

    Не ПИШИТЕ ВСЕ В ВЕРХНЕМ РЕГИСТРЕ, - это воспринимается как крик и считается грубостью. Если все написано в нижнем регистре, - не многим лучше, поскольку так сложно читать.

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

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

    Уделите внимание заголовку (теме) сообщения

    Тема сообщения - прекрасная возможность привлечь внимание квалифицированных экспертов! Не тратьте их на лепет типа "Помогите мне, пожалуйста" (не говоря уже про темы "PLEASE HELP ME!!!!"; сообщения с такими темами игнорируются рефлекторно). Не пытайтесь поразить нас глубиной своих страданий; лучше используйте отведенное место для максимально краткого описания проблемы.

    Хорошее соглашение по оформлению тем сообщений, используемое многими службами технической поддержки, - применение шаблона "объект - отклонение". Часть "объект" задает, с чем именно возникла проблема, а часть "отклонение" описывает отклонение от ожидаемого поведения.

    Глупо:

    ПОМОГИТЕ! Ошибка при заполнении дерева!

    Разумно:

    Ошибка уникального ключа при заполнении элемента TreeView

    Еще лучше:

    Элемент TreeView - при добавлении узла возникает ошибка "35602: Key is not unique in collection"

    Процесс написания темы по шаблону "объект-отклонение" поможет более детально осмыслить проблему. Что именно неправильно работает? Эксперт, увидев подобную тему, сможет, в общих чертах, понять, с чем именно у вас возникла проблема и что это за проблема.

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

    Точно и детально опишите проблему

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

    Сделайте максимум возможного, чтобы предугадать потенциальные вопросы эксперта и заранее на них ответить в своем обращении за помощью.

    Приложите полноценные исходники и файлы для тестов

    Зачастую эксперту гораздо быстрее разобраться в проблеме, запустив вашу программу на своем компьютере, чем пытаться умозрительным путем выявить ошибку. Можно быстро расставить точки останова, проверить состояние переменных, провести несколько экспериментов, внеся необходимые изменения. И в конце-концов вернуть вам исправленный и уже протестированный программный код.

    Если подобные действия максимально затруднены или невозможны (для запуска кода необходимо воссоздавать формы, придумывать окружение, инициализировать переменные и т.п.), то время решения проблемы увеличится в разы или даже на порядки. Вы будете получать встречные вопросы: какие значения имеют переменные, что будет, если заменить А на Б и т.п. В конце-концов эксперту может просто надоесть длительная переписка с вами.

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

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

    Объем еще не значит точность

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

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

    Публичное самоунижение не заменяет выполнение работы самостоятельно

    Некоторые пользователи, уяснив, что не надо вести себя грубо или надменно, вымогая ответ, выбирают противоположную крайность — самоунижение. «Я знаю, я начинающий, неудачник и полный чайник, но…». Это отвлекает от сути и не имеет никакого смысла. Особенно в сочетании с неопределённостью в описании фактической проблемы.

    Не тратьте своё и наше время, уповая на жалость. Лучше предоставьте факты и задайте свой вопрос как можно яснее. Так вы заявите о себе гораздо с лучшей стороны, нежели избрав путь самоунижения.

    Описывайте симптомы проблемы, а не свои предположения

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

    Не просите отвечать на личный адрес электронной почты

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

    Когда вы просите личного ответа, вы мешаете как процессу выработки решения, так и получению вознаграждения. Не делайте этого. Отвечать лично - это выбор отвечающего, — и если он так и делает, то обычно потому, что считает вопрос слишком неудачно сформулированным или очевидным, чтобы быть интересным другим.

    Экономьте время эксперта

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

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

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

    Поэтому имеет смысл ограничить вопрос, чтобы свести к минимуму время, необходимое эксперту для его решения. Но зачастую это не то же самое, что упростить вопрос. Так, например, вопрос: "Можете ли вы дать мне ссылку на хорошее описание X?" - обычно куда разумнее, чем просьба: "Объясните мне X, пожалуйста". Если у вас проблема с неработающим кодом, разумнее будет попросить объяснить, что в нем не так, а не просить исправить ошибки.

    Не задавайте вопросы из домашних заданий

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

    Избегайте бессмысленных просьб

    Не поддавайтесь соблазну завершить свой запрос бессмысленными вопросами вида: "Не поможет ли мне кто-нибудь?" или "Есть ли вообще ответ?" Во-первых, если вы хоть сколько-нибудь компетентно описали свою проблему, подобные дополнительные вопросы, как минимум, излишни. Во-вторых, поскольку они излишни, экспертам они кажутся надоедливыми, и в ответ их так и подбивает написать логически безукоризненную отписку типа: "Да, помочь вам можно" или "Нет, вам уже ничем не поможешь".

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

    Не помечайте свой вопрос как "Срочный", даже если для вас он именно такой

    Это ваша проблема, а не наша. Упоминание о срочности зачастую контрпродуктивно: большинство экспертов просто пропускает такие сообщения как грубые и эгоистичные попытки срочно привлечь к себе особое внимание.

    Вежливость никогда не повредит, и иногда помогает

    Будьте вежливы. Используйте фразы "Пожалуйста" и "Заранее благодарен". Дайте понять, что благодарны людям, бесплатно посвящающим вам свое время.

    Если честно, это не так важно, как отсутствие ошибок в тексте вопроса, ясность, точность и детальность описания, использование открытых форматов и т.д. (и не заменяет все перечисленное); эксперты, в общем случае, предпочли бы получать грубые, но технически точные сообщения об ошибках, чем вежливое словоблудие. (Если вас это удивляет, вспомните, что мы ценим вопрос за то, чему он нас учит.)

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

    Опубликуйте краткое описание решения

    После того, как проблема решена (даже и тем более, если вы решили ее сами), опубликуйте решение, дайте знать, чем все закончилось, и поблагодарите еще раз за помощь.

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

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

    Последнее, но немаловажное, - такого рода сообщение помогает всем участвовавшим в обсуждении получить чувство удовлетворения от того факта, что проблема закрыта. Если вы сами - не технический специалист и не эксперт, просто поверьте нам, что это чувство очень важно для гуру и экспертов, к которым вы обращались за помощью. Описания проблем, так в итоге и не решенных - это сплошное разочарование; эксперты жаждут увидеть их решенными. Хорошая карма, возникающая, когда вы удовлетворяете эту жажду, очень поможет вам при задании вопроса в следующий раз.

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

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

    Как интерпретировать ответы

    RTFM и STFW: как понять, что вы серьезно облажались

    Есть древняя и священная традиция: если вы получаете ответ "RTFM", значит, отвечающий думает, что вам стоит почитать руководство (Read The Fucking Manual). Он почти наверняка прав. Читайте.

    У ответа RTFM есть более молодой аналог. Если вы получаете ответ "STFW", значит, отвечающий думает, что вам стоит поискать ответ в сети (Search The Fucking Web). Он почти наверняка прав. Ищите.

    Часто тот, кто посылает один из подобных ответов, имеет под рукой руководство или web-страницу с необходимой вам информацией, и смотрит на нее, когда набирает ответ. Эти ответы означают, что, по его мнению, во-первых, необходимую вам информацию легко найти и, во-вторых, вы большему научитесь при поиске информации, чем если вам ее преподнесут под нос на тарелочке.

    Вас это не должно возмущать; он оказал вам достаточное уважение уже тем, что не проигнорировал вопрос. Вы должны поблагодарить ответившего за его отеческую доброту.

    Если вы не поняли...

    Если вы не поняли ответ, не шлите тут же требование его объяснить. Используйте те же источники информации, что и при поиске ответа на исходный вопрос (руководства, FAQ, Интернет, опытные коллеги), чтобы понять ответ. Если и после этого вам необходимы разъяснения, покажите, что вы узнали сами.

    Например, предположим, вам ответили: "Воспользуйтесь функцией Split". Тогда:

    Вот плохой уточняющий вопрос: "А как она работает?"

    Вот хороший уточняющий вопрос: "OK, я прочитал страницу справочного руководства, но не очень понял, как ее использовать, если у меня несколько разных разделителей в одной строке?"

    Реакция на грубость

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

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

    С другой стороны, иногда можно встретиться с грубостью и вызовом, не имеющими никаких видимых оснований. Обратная сторона этой медали в том, что такая реакция является вполне приемлемой формой постановки на место действительных грубиянов, - мы отсекаем их недостойное поведение остро отточенным словесным скальпелем. Однако, вы должны быть очень уверены в своей позиции, прежде чем пытаться этим заняться. Грань между указанием на невежливость и началом бессмысленного "базара" настолько тонкая, что и сами эксперты нередко ее переходят. Если вы - новичок или просто случайный читатель, шансов избежать такой грубой ошибки - немного. Если вас интересует информация, а не развлечение, лучше уберите руки с клавиатуры и не рискуйте вступать в подобные дискуссии.

    (Некоторые настаивают, что многие эксперты в нашей области страдают мягкой формой аутизма, или синдрома Аспергера, и у них просто не хватает той части мозга, которая отвечает за "нормальное" социальное взаимодействие между людьми. Возможно, это правда, а может и нет. Если вы - не эксперт, представление о экспертах как о больных на голову может вам помочь смириться с нашими странностями. Думайте, что хотите. Нас это не волнует; нам нравится быть именно такими, и к клиническим диагнозам мы относимся со здоровым скептицизмом.)

    В следующем разделе мы поговорим о другой проблеме; о своего рода "грубости", с которой можно встретиться, когда именно вы не правы.

    Не реагируйте как неудачник

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

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

    Смириться. Это - нормально. На самом деле, это хорошо и целесообразно.

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

    Были форумы, где, исходя из неправильно понятой гипертрофированной вежливости, участникам запрещалось посылать сообщения об ошибках в чужих сообщениях. Им было сказано: "Если не хотите помочь пользователю, молчите". Отток знающих участников в другие форумы привел к их вырождению в бессмысленную болтовню и к полной бесполезности с технической точки зрения.

    Выбирайте: или преувеличенная "дружественность" (такого рода) или полезность.

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

    Вопросы, которые задавать не надо

    Вот ряд классических глупых вопросов и о чем думают эксперты, когда на них не отвечают.

    Вопрос: Где можно найти программу или ресурс X?
    Ответ: Там же, где и я ее взял, — найти в Internet. Боже, неужели еще не все знают, как пользоваться Google?

    Вопрос: Как можно с помощью X сделать Y?
    Ответ: Если вы хотите сделать Y, надо так и спрашивать, не предполагая заранее использование метода, который может вовсе не подходить. Вопросы такого вида часто задают те, кто не просто ничего не знает об X, но сбит с толку решаемой проблемой Y и слишком сконцентрирован на деталях своей конкретной ситуации. Обычно лучше игнорировать таких людей, пока они не сформулируют свою проблему лучше.

    Вопрос: Можно ли преобразовать X-файл в Y-файл с помощью программы преобразования файлов Z?
    Ответ: Попробуйте и узнаете. Так вы, во-первых, узнаете ответ, а, во-вторых, перестанете тратить мое время.

    Вопрос: Моя {программа, конфигурация, мой оператор SQL} не работает
    Ответ: Это вообще утверждение, а не вопрос, и я не собираюсь задавать еще десяток наводящих вопросов, чтобы выяснить, в чем на самом деле состоит ваша проблема — у меня есть дела и поинтереснее. Когда я вижу подобные вопросы, то обычно даю ответ: "Вам к этому больше нечего добавить?" или "Ой, это очень плохо. Надеюсь, вы уже это исправили."

    Вопрос: Моя программа не работает. Я думаю, проблема в системном компоненте X.
    Ответ: Хотя и возможно, что именно вы первым обнаружили очевидную ошибку в системных вызовах и библиотеках, интенсивно используемых сотнями или тысячами разработчиков, но намного вероятнее, что вы просто не разобрались. Серьезные утверждения требуют серьезных доказательств; если вы делаете подобные утверждения, их надо подкреплять ясным и исчерпывающим описанием ситуации, в которой возникает сбой.

    Хорошие и плохие вопросы

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

    Глупо: Где мне найти информацию о YYY?

    Этот вопрос просто напрашивается на ответ "STFW".

    Правильно: Я попытался поискать в Web с помощью Google по запросу "YYY", но полезных ссылок не получил. Не знает ли кто-нибудь, где найти информацию о его использовании?

    Этот вопрошающий уже поискал в Web и, похоже, у него - реальная проблема.

    Глупо: Я не могу скомпилировать код проекта foo. Почему он некорректен?

    Он думает, что кто-то другой облажался. Самоуверенный тип.

    Правильно: Код проекта foo не компилируется в ОС X версии Y. Я прочитал FAQ, но там нет ничего о проблемах с X. Вот сообщения об ошибках, что я сделал неправильно?

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

    Глупо: У меня проблемы с материнской платой. Не может ли кто-нибудь помочь?

    Любой эксперт на такой вопрос в уме ответит, скорее всего так: "Хорошо. Может, тебе еще помочь срыгнуть и пеленку поменять?", и пройдет мимо.

    Правильно: Я попробовал X, Y и Z на материнской плате W. Когда это не сработало, я попробовал A, B и C. Обратите внимание на странный симптом при попытке сделать C. Очевидно, что эта фигня не фурычит, но результаты получаются непредсказуемые. Что обычно приводит к тому, что не фурычат многопроцессорные материнские платы с Athlon? Нет ли у кого идей для дополнительных тестов, которые помогут изолировать проблему?

    Этот товарищ, напротив, кажется, достоин ответа. Он продемонстрировал способность решать проблемы, а не просто ждет, пока ответ упадет ему с неба.

    В последнем вопросе обратите внимание на небольшую, но важную разницу между "Дайте мне ответ" и "Пожалуйста, помогите разобраться, какие дополнительные диагностические действия можно выполнить, чтобы прояснить ситуацию".

    Если ответ не получен

    Если вы не получили ответа, не принимайте это на свой счет, как наш отказ помочь лично вам. Иногда участники форума просто не знают ответ. Отсутствие ответа не равносильно игнорированию, хотя извне разницу заметить сложно.

    Можно попытаться пару раз "поднять" свой топик, опубликовав в нем повторную просьбу о помощи. Только не стоит это делать, если не прошло хотя бы дня три. Не все эксперты непрерывно читают форум, некоторые появляются изредка.

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

    Как давать хорошие ответы

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

    Если вы не уверены, так и говорите! Ошибочный, но авторитетно звучащий ответ хуже, чем отсутствие ответа. Не направляйте людей по ложному пути просто потому, что вам приятно побыть в роли эксперта. Будьте скромны и честны; показывайте хороший пример для спрашивающих и коллег.

    Если не можете помочь, не мешайте. Не шутите по поводу команд, которые могут разрушить среду пользователя — этот болван может принять ваши шутки как руководство к действию.

    Задавайте дополнительные вопросы, чтобы получить больше информации. Если это делать правильно, спрашивающий кое-чему научится, — да и вы тоже. Попытайтесь превратить плохой вопрос в хороший: помните — все мы были начинающими.

    Хотя простой ответ RTFM бывает оправдан, когда дается просто лентяю, ссылка на документацию (даже если это набор ключевых слов для поиска в Google) все же лучше.

    Если уж вы отвечаете на вопрос, давайте ответ по сути. Не предлагайте наспех придуманные обходные пути, если используется в принципе не то средство или неверный подход. Предлагайте хорошие средства. Переформулируйте вопрос.

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

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



    Благодарности:
    Эвелин Митчел предложила прокомментировать ряд глупых вопросов и вдохновила на написание раздела "Как давать хорошие ответы".

    + об авторах

    Авторы: Eric Steven Raymond, Rick Moen, 2001 оригинальная статья
    Перевод: Валерий Кравчук, 2002

    Статья несколько сокращена и адаптирована к форуму sql.ru, изменения связаны с изначальной ориентацией статьи на группы рассылок и "железные" вопросы, а не на форумы и вопросы "софта", добавлено несколько абзацев, касающихся вопросов о программировании: Shocker.Pro, 2014
  • Вопрос: Систематизация задач пользователей форума

    Я изучаю язык Си и в ветке посвящённом этому языку каждый день появляются просьбы решить/разобраться/помочь с поиском ошибки. Все вопросы, конечно, поступают от изучающих программирование и эти вопросы/задачи взяты из учебников, заданий преподавателей и других источников. Количество этих задач ограничено и каждое новое поколение учеников решают одни и же задачи. Следовательно, большинство из них уже решены "старшими" участниками форума, но из-за неинформативного заголовка эти решения недоступны новичкам. Т.к. содержание задачи, как правило, бывает небольшим текстов, почему бы в качестве заголовка темы не указывать условие задачи?
    Ответ: Бесполезно что-то систематизировать.
    На большинство вопросов, которые задают на форуме, ответы уже есть в интернете. Если человек не может найти нужную ему ссылку на первой странице результатов поиска в гугле, то вряд ли он найдёт нужную тему на форуме.

    Многие из спрашивающих просто хотят получить готовое решение, затратив не более 5 минут времени. Я удивляюсь, неужели нельзя списать у однокурсников?
    Вопрос: Описание: ну как я и сказал выше я хочу сделать форум самый обычнейший форум без всякой всячины

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

    скажите где мне можно найти скрипт либо где есть статья про то как сделать форум на php,mysql ну короче help me
    Ответ:
    arxnday
    Я то сделал себе собственую капчу. Вы же можете поискать плагин для reCapcha например. Но вопрос в другом. Надо ли вам именно phpBB
    Вопрос: WebBrowser вопрос

    перехожу по адресу
    Вижу страницу

    Вижу
      <DIV metrikaId_0.5974972171062272="81"><INPUT id=new_attr_123 class=s_selectTextActive value=6501011805 jQuery17202799393626251008="57" service_alias="kr_erc_all" metrikaId_0.5974972171062272="82" attr_id="123" service_id="1440" pattern="^\s*(([0-9]{10}))\s*$" default_value></DIV>


    Вписал следующий код
      A := WebBrowser1.OleObject.Document.getElementById('new_attr_123');
      A.Value := '6501011805';


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

    Как победить?
    Ответ:
    Получилось, правда немного через ЖЖЖЖ

    реально пришлось через хэндл IE


    но, просто так не удалось.

    Сначала в поле WebBrowser програмно
    Вносим
      A := WebBrowser1.OleObject.Document.getElementById('new_attr_123');
      A.Value := '6501011805';

    Затем фокус
      Form1.WebBrowser1.OleObject.Document.GetElementById('new_attr_123').Click;

    и только после этого обновление
      H := GetIEHandle(Webbrowser1,'Internet Explorer_Server');
      SendMessage(H,WM_LBUTTONDOWN,0,MakeLong(10,10));
      application.ProcessMessages;
    Вопрос: Стоит ли сейчас углубленно изучать Pascal по тем книжкам, что прикреплены к форуму

    Вопрос типичный для новичков, не судите строго. Когда начинал прогать, то ходил на курсы, там изучали Паскаль(даже ассмовские вставки учили применять,ага), в универе тоже обучают только Паскалю, но на работе я пишу на Java/C#(зависит от задачи). Последнее время помогаю студентам с универа на PascalABC.NET писать лабы и встал вопрос, а стоит ли сейчас углубленно изучать Паскаль по тем книжкам, что прикреплены к форуму для развития навыков и выработки какой-то красоты в функциональности и в коде?
    Книжки уже накачал, начал читать. З.Ы. к олимпиадному программированию подойдет знание Паскаля?
    Ответ: ФедосеевПавел, большое спасибо за ответ. Вопрос, конечно, не ради холивара. Просто хочется выбить определенную колею в программировании и в ней копать по направлению вперед
    Вопрос: Движки для Форумов PHP

    Может быть кто-то знает? Был бы очень признателен, если подскажете
    на каком движке форума на базе PHP можно видеть иерархию сообщений?
    Чтобы было понятно, кто кому ответил и на какой вопрос.
    Имеется в виду современный движок для установки себе на сайт.
    Ответ:
    artoodetoo писал(а):https://github.com/phpbb/phpbb



    Спасибо за ссылки!

    Во как! (на fluxbb-форуме пишут, что punbb - отстой)
    Но на punbb-форуме пишут, что все наоборот.
    Вопрос: Несколько вопросов по основам.

    Добрый день. Наткнулась на курсы по с++ и возникли вопросы по материалу, но т.к. курсы старые, форум совсем пустой, нужна ваша помощь.
    Тут объясняется суть алгоритма:

    #include <iostream>

    using namespace std;

    int main() {
    cout << "Hello, World!";
    return 0;
    }

    Следующая строка, using namespace std, говорит, что программа использует стандартное пространство имён (оно называется std). В C++ есть большая стандартная библиотека, и в ней содержится много разных функций, у каждой из которых есть название. Может оказаться, что мы напишем свою функцию, название которой будет совпадать со стандартной, и тогда всё сломается. Если не подключать пространство имен std, то ломаться ничего не будет, но тогда для вызова стандартной функции придётся писать много лишних букв. Но мы не будем называть функции теми же именами, что и стандартные, поэтому нас эта проблема не коснётся.

    Возникли следующие вопросы:
    Я правильно понимаю это момент, что при условии:
    1) я пишу функцию, наим. кот-ой не совпадает с наим. функций из стд библ, то прописывать строку using namespace std не нужно?
    2) я пишу функцию (не из стд библ), наим. кот-ой совпадает с функц. из стд библ., и в начале я не прописала строку using namespace std, то ломаться программа не будет?
    3) а если я пропишу сначала строку using namespace std и напишу функцию, наим. которой совпадает с наим. ф-ии из стд библ, то программа сломается? так? если функция содержит в себе часть имени функции из стд библ, то программа не будет работать?
    4) и если я использую в программе др. функции, но мне понадобилась функция из стд библ, то мне придется писать "много лишних букв" что-бы ее использовать, так как ее наим может совпадать с др. функциями (дабы ничего не сломалось)?
    Ответ: Когда-то на другом форуме объяснял "на пальцах".
    Цитата:
    Представьте себе Вашу файловую систему без каталогов - всё в корневике (в глобальном пространстве имен).
    Какие проблемы могут возникнуть?
    Самое первое - нельзя иметь два файла с одним именем (на самом деле можно, но сейчас не об этом), потому как возникнет конфликт имен.
    Теперь допустим, что всё же у нас два разных файла с одним именем (файл1) оказались в корневике и Вам начальник со свирепым выражением лица, крича и разбрызгивая во все стороны свою слюну кричит "Открой файл1", но вот беда - их два и какой открывать? У Вас по сути один нормальный путь - спросить какой именно, собственно компилятор так и делает - выдает ошибку с текстом на подобии "Имя 'такое-то' двусмысленно".
    А если бы всё лежало по папкам, то коллизий бы не возникло.
    Вам бы сказали открыть файл "файл1" из каталога "каталог1" ( каталог1::файл1 )
    или открыть файл "файл1" из каталога "каталог2" ( каталог2::файл1 )

    А теперь к примеру на программе:
    А теперь представьте, что написали Вы программу, всё работает - класс, всё довольны!
    И вот решили вдруг, что нужно еще сделать пару фишек. Нашли стороннюю библиотеку, которая отлично подходит для реализации этих самых "фишек", но вот беда в ней есть классы с таким же именем как и у Вас. Что делать? Создавать копию Вашего класса, но с другим именем? Ну это жестко.
    Вот пространства имен призваны решать такие проблемы. Например, вся стандартная библиотека, содержится в одном пространстве имен std, а подключаемые файлы так же определяют свои пространства имен, например библиотека boost находится в пространстве имен boost. Если писать boost::vector, то будет понятно, что используется вектор из библиотеки boost, а не std.
    Что касается using namespace такое-то, это означает примерно следующее:
    "Использовать пространство имен такое-то в этой области видимости".
    То есть мы "скидываем" всё содержимое пространства имен в "текущую" область видимости, тем самым её засоряя ( пример про корневой каталог без разделения на папки ).

    То есть пространства имен можно рассматривать как уточнение имени сущности.
    Вопрос: Написание форума с нуля

    Здравствуйте,
    являюсь студентом и ищу тему для проекта. Пришла в голову мысль написать форум.

    С пхп знаком слабо, и с этим вопрос - не слишком ли амбициозная идея как для новичка ?
    Есть мысль написать приложение по "взаимной накрутке лайков" в вк/фейсбуке.
    Возможно подкиньте идею. требования : интернет приложение, должны быть использованы HTML, css, js, базы данных, Ajax, должны быть пользователи и логин.

    Очень не хотел бы переоценить свои силы.

    Спасибо.
    Ответ:
    Сообщение от Jason Leavers
    С пхп знаком слабо, и с этим вопрос - не слишком ли амбициозная идея как для новичка ?
    Почему на php?
    Вопрос: Необходимо оценить качество вопросов в тесте на знание Java8 сайта testd.ru

    Необходимо оценить качество вопросов в тесте на знание Java8 сайта testd.ru. Мы работаем над стартапом – сайтом по тестированию знаний testd.ru. На данный момент нами подготовлено более 150 тестов различных направлений. Составленные авторами тесты сейчас находятся на стадии проверки и нам очень важно узнать Ваше профессиональное мнение о качестве вопросов и ответов, правильно и понятно сформулирован вопрос, какая сложность вопроса и ответа на него. Во время прохождения теста Вы оцените каждый вопрос поставив возле него оценку по пятибальной шкале. Оценка 1- вопрос не раскрывает темы, некорректно сформулирован или не имеет смысла, оценка 5 – хороший вопрос. Прохождение теста в среднем займет 20-30 минут Вашего времени.
    В качестве вознаграждения мы предлагаем Вам в течение двух лет бесплатно проходить тестирование и сертификацию от компании testd и дополнительные бонусы по договоренности. Кого заинтересовало наше предложение, пишите в личку или на почту admin.elena@testd.ru
    Ответ:
    Цитата
    Необходимо оценить качество вопросов в тесте на знание Java8 сайта testd.ru.

    Вы хотите чтобы для тестирования вам платили? Заметьте, ветка форума содержит следующий пункт в правилах:
    Цитата

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

    Цитата
    Сайт на тестировании

    Вы хотите чтобы ВАМ помогли, не пойму, к чему тогда такое отношение?
    Вопрос: Категория форума -> фоурмы

    Мучался, вроде просто - а не туда, ни сюда.
    Две таблицы: Категория форума / Форумы
    Нужно вывести втаком порядке:
    Код:
        Название категории
        - Форумы
        Название второй категории
        - Форумы


    Таблица `forum`:
    `id` (int) , `category`(int) , `name` (varchar)
    1|1|Первый форум
    2|1|Второй форум
    3|2|Еще форум
    4|2|Еще форумец
    4|3|Пум-пум


    Таблица `forum_category`:
    `id` (int) , `name` (varchar)
    1|Основные форумы
    2|информационные форумы
    3|Тринитротелалол


    Пробовал так, но не то.. Группировка не помогает.
    SELECT forum.name, forum_category.name AS cat_name FROM forum
    LEFT JOIN forum_category.category ON forum_category.id = forum.category
    GROUP BY forum.category
    ORDER BY forum.id ASC;
    Ответ: Сейчас вывожу так, но это не есть хорошо =)
    Код:
    Сейчас вывожу так, но это не есть хорошо  ::huh.gif::
    [PHP]
    $sql = $db->super_query("SELECT `".PREFIX."_forum_categories`.`id`,
                            `".PREFIX."_forum_categories`.`name`
                            FROM `".PREFIX."_forum_categories`
                            ", 1);
    if($sql) {
    foreach($sql As $row){

    $tpl->load_template('forum/category.tpl');
    $tpl->set('{name}', $row['name']);
    $tpl->compile('content');

    $sql = $db->super_query("SELECT `".PREFIX."_forum`.`id`,
                            `".PREFIX."_forum`.`name`,
                            `".PREFIX."_forum`.`description`,
                            `".PREFIX."_forum`.`count_messages`,
                            `".PREFIX."_forum`.`count_topics`,
                            `".PREFIX."_forum`.`forum_icon`
                      FROM `".PREFIX."_forum`
                      WHERE `".PREFIX."_forum`.`category` = '".$row['id']."'
                      ", 1);
    if($sql){
    $tpl->load_template('forum/forum.tpl');
    foreach($sql AS $row){
    $tpl->set('{forum_id}', $row['id']);
    $tpl->set('{forum_name}', $row['name']);
    $tpl->set('{forum_description}', $row['description']);
    $tpl->set('{count_messages}', $row['count_messages']);
    $tpl->set('{count_topics}', $row['count_topics']);
    if(file_exists(ROOT_DIR."/templates/".$config['temp']."/images/forum/".$row['forum_icon'])){
    $tpl->set('{forum_icon}', "/templates/".$config['temp']."/images/forum/".$row['forum_icon']);
    } else {
    $tpl->set('{forum_icon}', "/templates/".$config['temp']."/images/forum/no.png");
    }

    $tpl->compile('content');
    }
    }
    }
    } else { msgbox('Ошибка', 'Форумы не найдены', 'Обратитесь к данной странице позже', 'info'); }
    [/PHP]