Идея написать что-то подобное у меня возникла еще после сборов в Петрозаводске, где Михаил Мирзаянов прочитал лекцию о том, как правильно готовить контесты. На мой взгляд, лекция была очень правильная, и было бы здорово увидеть ее здесь, на Codeforces. Спустя некоторое время тема забылась, но фейл (полный провал - прим. Артема) с условиями на 58 раунде напомнил о ней. Хочу обратить внимание, что все написанное здесь это, конечно, наше мнение, но оно все же основано на довольно большом опыте.

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

 Старайтесь, чтобы форматы данных и тесты находились на одной странице.

Название

Единственная часть, которая может быть предоставлена авторам без ограничений. Однако:

 Хорошо, если в английском названии первая буква совпадает с индексом задачи (Эта традиция многих ACM-контестов, однако это правило подходит только для английской версии условия)

Ограничения

 Плохо писать ограничения для всех задач только на отдельной странице.

 Плохо делать разные или нестандартные ML. Если ваша задача требует больше 256 МБ памяти - задумайтесь, может быть, это плохая задача?

 Хорошо делать одинаковые TL для всех задач.

Текст

Самая важная часть задачи. В ней, как правило, авторы любят проявлять свою фантазию. Следует понимать, что текст можно разделить на две части: сказку и полезную информацию.

 Плохо писать слишком длинную сказку.

 Плохо, если в сказке скрыта важная информация.

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

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

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

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

 Особо важные моменты можно выносить отдельно. К сожалению, в традиционных контестах используется редко, в отличие от TopCoder (в условиях пометка Notes).

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

Перевод

Все правила, обозначенные для текста на родном языке, должны применяться и здесь. Кроме того, часто бывают ситуации, когда вы не знаете как перевести ту или иную фразу. У вас есть два варианта:

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

 Изменить фразу так, чтобы она стала

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

Формат входных данных

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

 Плохо делать лишние whitespaces, кроме перевода строки в конце потока.

 Плохо, когда нельзя явно вычислить количество строк/элементов во входном потоке (и приходится использовать while(scanf(“”Гена одержал”)).

 Не используйте нестандартные или непечатаемые символы. В том числе кириллицу. Не надо. Серьезно.

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

Формат выходных данных

То же самое: только формат данных, а не что вы требуете в задаче.

 Обязательно используйте одинаковое написание стандартных слов во всех задачах (YES/Yes).

 Тем не менее, для проверки слов yes, no, no solution, impossible и т.д. лучше использовать чекер, не чувствительный к регистру.

Потоки ввода и вывода

Как правило, используются стандартные потоки (stdin, stdout) или файлы.

 Очень плохо делать смешанные варианты (stdin + file.out).

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

 В таблице с тестами пишите название потока или файла вместо "входные данные".

 Используйте стандартные имена файлов (input.txt/output.txt, file.in/file.out).

 Хорошо, если имя файла совпадает с индексом задачи (a.in).

 Можете указать, что работа со стандартными потоками означает ввод и вывод через консоль - новички скажут вам спасибо.

Тесты

О правильной подготовке тестов подробно рассказано в презентации Михаила Мирзаянова. Очень надеемся, что она появится на Codeforces.

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

 Обязательно проверяйте тесты из условий валидатором!

 Помните, что тесты из условия являются частью описания входных данных.

Комментарии к тестам

 Очень плохо, если после тестов идет информация, не относящаяся непосредственно к тестам (например, примечания).

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

 Илья Акользин и Артем Верхоглядов, MIPT Guinness and Pistachios.