Записки программиста.
Jul. 11th, 2009 09:05 amЕще одно программистское заблуждение: "хороший" программный код не требует документации.
Я уже писал о некоторых подобных заблуждениях. Скажем о том, что предварительная оптимизация кода это зло или про абсолютный вред использовыние оператора goto. Как правило каждое такое заблуждение является неправльным обобщением совершенно справедливого наблюдения.
Еще одно распространенное заблуждение - это то, что хороший программный код не требует документации. Я, конечно, говорю о внутренней документации - не для пользователей, которые используют продукт как черный (или очень темный :-) ) яшик, а для тех, кто должен этот код понимать - с целью проверки, переделки и.т.д.
Опять же, это мнение возникло как обобщение совершенно справедливых наблюдений, таких как:
- хорошие программисты как правило создают код, который гораздо легче понимать (и, соответственно, модифицировать, проверять и.т.д.).
- даже подробная документация часто не очень-то помогает делать то же самое с плохим, запутанным кодом.
Но обобщение неправильно.
Тривиальным противоречащим примером может служить любой простой (то есть короткий) нетривиальный алгоритм. Скажем, один из оптимальных O(N*log(N)) алгоритмов сортировки (упорядочения массива):
template
Я уже писал о некоторых подобных заблуждениях. Скажем о том, что предварительная оптимизация кода это зло или про абсолютный вред использовыние оператора goto. Как правило каждое такое заблуждение является неправльным обобщением совершенно справедливого наблюдения.
Еще одно распространенное заблуждение - это то, что хороший программный код не требует документации. Я, конечно, говорю о внутренней документации - не для пользователей, которые используют продукт как черный (или очень темный :-) ) яшик, а для тех, кто должен этот код понимать - с целью проверки, переделки и.т.д.
Опять же, это мнение возникло как обобщение совершенно справедливых наблюдений, таких как:
- хорошие программисты как правило создают код, который гораздо легче понимать (и, соответственно, модифицировать, проверять и.т.д.).
- даже подробная документация часто не очень-то помогает делать то же самое с плохим, запутанным кодом.
Но обобщение неправильно.
Тривиальным противоречащим примером может служить любой простой (то есть короткий) нетривиальный алгоритм. Скажем, один из оптимальных O(N*log(N)) алгоритмов сортировки (упорядочения массива):
template