- проверка орфографии в комментариях в исходном коде (лично мне эта фича ой как нужна в жизни) и, соответственно, правка;
- валидация идентификаторов в исходном коде и подбор более удачной замены (тут задачка посложнее, на первом этапе хватит только определения некоторого "индекса читаемости" идентификаторов, в каких попугаях мерить пока не ясно).
Интерфейс пока хочется банальный текстовый а-ля ispell, на выходе хочется получить diff-файл (чтобы потом патчики создавать :))
Пока думаю, как бы так поприятнее прикрутить к этому делу ispell или aspell...
В принципе, aspell поумнее будет в плане определения возможных вариантов лексем, но совсем не очевидно, что это как раз надо для комментариев в коде ;)
ОтветитьУдалитьЕще один открытый вопрос: на чем все это дело писать? Как варианты рассматриваются C++, Python и Perl. C++ предпочтительней, поскольку хочется в итоге получить некую библиотечку (как часть лингвистического пакета, которым я занимаюсь еще со STARовских времен), а на Perl проще всего, наверное.
В принципе, в перспективе может возникнуть и Java, но только в виде плагина к JBuilder'у или Eclipse'у...
ОтветитьУдалитьИ еще тут подумалось: стоит ли привязываться к ispell/aspell? Может, имеет смысл написать свой движок (ну, когда-нибудь потом).
Сделал прототип модели разбора и хранения структурированных текстовых данных. В первом приближении подходит для парсинга и обработки текста (как обычного, так и исходных кодов).
ОтветитьУдалитьЛежит здесь
Вернулся из Нижнего с парой-тройкой идей. Если успею додумать, изложу. В идеале хорошо бы и сырцы обновить.
ОтветитьУдалитьИсходный код, упомянутый выше, довольно сильно поправлен. Старый вариант удален, поэтому ссылочка не работает.
ОтветитьУдалитьПереработан обобщенный интерфейс представления элементов текста (теперь это дело называется tpi --- Text Processing Interface), осталось autotool'изировать проект и тогда уже выложу в виде библиотеки libtpi.
Далее планы примерно такие:
- написать грамматику для bison'а для парсинга комментариев C/C++/Java;
- подготовить code comments интерфейс на базе libtpi;
- ну и собственно имплементация.
Словари и прочее уже на следующем этапе. Кстати, надо будет подумать еще и том, как парсить идентификаторы в исходном коде... не писать же полноценные парсера для C/C++ и Java!
Вот еще что надо не забыть: нужен механизм распознавания типа парсируемых элементов: слова, числа, doc-comments и пр. На первом этапе (да и возможно вообще можно так и оставить) все знаки пунктуции должны быть удалены. Проблему со сложными словами (через "дефис") пока можно не принимать во внимание, тем более, что для английского языка это не характерно и, возможно, не принципиально.
ОтветитьУдалитьtpi autotool'изирован.
ОтветитьУдалитьОстались мелкие доработки напильником (типа, до-документирование кода, постоение doxygen'овской документации) + одна принципиальная вещь: нужно ли обязать tpi предоставлять информацию о местоположении элемента в тексте? (этого пока нет)
Буквально вчера сделал кучу дополнений. Во-первых, добавились методы определения местоположения распарсенных элементов в тексте (не так давно я сомневался в том, что это надо), добавились методы неявного вызова парсера при загрузке контейнера из потока. Во-вторых, добавился интерфейс депарсера для форматированного воспроизведения исходной информации и, соответственно, добавился интерфейс записи объектов в поток. Еще добавился mixin-класс для работы с именованными сущностями.
ОтветитьУдалитьМожно считать, что libtpi почти готова (получилась такая библиотека интерфейсов).
Осталось ее протестировать на паре легких примеров и можно выкладывать.
Вчера написал первый тестовый примерчик, выловил пару ошибок (формальных, но, все равно, приятно). Заодно образовался повод к размышлениям: должен ли быть базовый класс элемента иерархии текста абстрактным (в текущей реализации он не абстрактный).
ОтветитьУдалитьДо doxygen'а руки пока не дошли...
Видимо, по завершении тестирования эту ветку я закрою, все равно пока это только статус libtpi.
ОтветитьУдалитьВаяю более сложный тестовый примерчик, займет, предположительно еще пару-тройку вечеров... В процессе работы наметились идеи по возможному изменению в интерфейсе tpi (пока еще спорно, посмотрим), а именно: нужна ли сериализация в самом верхнем классе abstract_item? или имеет смысл тогда уже сделать mixin-класс serializable и подмешивать его при необходимости уже на клиентском уровне?
ОтветитьУдалитьИз-за собственной лени, Code Forge и прочего забил на libtpi. :( Вернусь уже, видимо, на следующей неделе.
ОтветитьУдалитьВсе, баста, завязываю :))
ОтветитьУдалитьВ смысле, этот тред комментов закрываю.
Вчера вернулся-таки к libtpi, есть куча упрощений. Заведем новую веточку :)
По поводу SmartChecker'а: тестовая версия будет, возможно, на Perl'е, если прогресс с C++-версией не будет явным.