История изменений

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

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

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

должны быть примеры. от «начал работать с Х» до «кончел работать с Х». т.е. мы хотим добиться А, делаем так. хотим Б - делаем так.

вообще, к чему я это написал.

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

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

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

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

должны быть примеры. от «начал работать с Х» до «кончел работать с Х». т.е. мы хотим добиться А, делаем так. хотим Б - делаем так.