Comments 18
Видимо следующий анализатор, нам всё же стоит делать не для Objective-C, а скажем для Java. :)
В свете этого топика не лишним будет упомянуть и о веб-сервисе Swiftify по преобразованию Objective-C кода в Swift.
Кстати, Codebeat и Swiftify используют ANTLR и открытую Objective-C грамматику. Однако подходы парсинга немного различаются.
Анализ ObjC кода работает не вполне удовлетворительно. Это связано с тем, что компания ориентируется в основном на анализ кода на Swift, а работа с ObjC добавлена недавно и требует дальнейшей доработки.
Ну да, летом вышеупомянутая грамматика была похуже качеством, чем сейчас =) (я занимаюсь ее разработкой). И в целом обработка препроцесосрных директив в C подобных языках — дело непростое.
Не знаю. А зачем такое нужно? Ведь ObjC более старый и менее удобный язык.
Если такой реализовывать, то конвертинг Swift -> ObjC реализовать попроще.
Конвертните плиз в ObjC такое:
guard let info = result["info"] as? [String : AnyObject] else {
return
}
print("\(info["title"])")
хм…
NSDictionary* info = result["info"]
if (![info isKindOfClass: NSDictionary.class]) {
return
}
NSLog("%@", info["title"])Вроде так?
Вот enum свифта перевести в enum Obj-C, куда посложнее задача, если первый используется не только как обычное перечисление.
Ну я говорил про общий случай. В Swift, например, очень ограниченная поддержка препроцессорных директив, что упрощает процесс.
Действительно, обратная конвертация Swift -> Obj-C может оказаться не проще, если учитывать поддержку сложных языковых конструкций Swift, включая optionals.
Сложный Swift enum можно представить в виде класса в Obj-C.
Переобразование enum values по словарю примерно одинаково по сложности с переобразованием Obj-C -> Swift.
Действительно, меня многие спрашивают про обратный конвертор Swift -> ObjC, и вероятно такой у нас в перспективе будет.
Единственный вопрос в том, что Obj-C используется все меньше.
Буду благоларен если приведете use cases для чего именно вам нужен такой конвертор (я основатель Swiftify).
В форматерах было бы здорово упомянуть clang-format.
https://github.com/nst/objc_dep — строит граф зависимостей фаилов, можно оценить насколько все связано друг с другом в визуальной форме, а иногда и обнаружить что у тебя есть фаилы стоящие отдельно и ни с чем ни линкуемые
http://uncrustify.sourceforge.net/ — форматер, довольно известный и универсальный (работает с C, C++, C#, ObjectiveC, D, Java, Pawn и VALA)
https://pmd.github.io/pmd-5.4.1/usage/cpd-usage.html — поиск дублирующего кода, тоже для кучи всего, но есть и поиск для obj-c. Раньше он был через сторонний плагин, теперь похоже прямо в ванильной версии (каюсь — не пробовал, как-то раньше обходился старой версией, а в последнее время не использовал)
Ну и есть еще такой вопрос (который я уже пару раз задавал, но ответа пока не получил) — а вы проверяли как приведенные вами анализаторы ведут себя с тем же тайфуном? По моим наблюдениям, кланг попросту перестает проверять то что подключено через тайфун т.к. не видит свзяи между классами (оно и понятно — там линкуется-то только протокол, сам класс уже в рантайме оказывается связан).
Статические анализаторы для Swift и Objective-C