Есть предложение тогда добавить все хинты из комментариев Хабра в текст самого задания, чтобы те кто его вдруг не смотрит не оказались в неравных условиях.
А если хочется при этом жить несколько месяцев в году за пределами РФ? Например, зимовать там, где вечное лето, и при этом работать? Насколько это все меняет?
Ну, например, в Jetbrains, используют. А так помнится linux kernell был вообще без тестов много лет, ситуация как-то начала меняться совсем недавно. Что вовсе не означает, что так стоит жить. :-)
Блин, а ведь и правда. По Alt+Enter на внешнем коде предлагает его проаннотировать.
В заблуждение ввела сначала вот эта часть доки:
If an annotation pertains to the SDK, configured for your project, the path is to be defined in the SDK settings. If an annotation pertains to a module, the path should be defined in the module settings.
Понял так, что раз уж аннотация должна относиться либо к модулю, либо к JDK, то и аннотировать можно только их. Ну, и единственный пример только на внешнее аннотирование собственного кода был в пользу этой версии.
Вообще круто, но в feature requests я бы добавил suggestion на добавление external annotation (если они включены) в подобных случаях:
Map<String, String> map = ImmutableMap.of("bca", "cab");
@Nullable String str = map.get("abc");
Ну, и какое-то отображение в исходниках проаннотированной библиотеки, кроме Ctrl+Q. Хотя и с трудом представляю себе как. Хитрые подчеркивания разве что.
Честно говоря, выглядит уже не так интересно в плане затрачиваемых ресурсов/приносимой пользы. Да и Intellij Idea specific, как я понимаю. Лучше добавьте поддержку «аннотирования» внешних библиотек. ;-)
В случае метода — это контракт на «опциональность» между вызывающим и вызываемым. Для объекта и его полей — это инвариант. Даже без всяких статических анализаторов, просто прописав их, вы сможете рассматривать гораздо меньше вариантов состояния и поведения приложения при написании вашего кода.
Ну, и естественно, не надо рыскать по всему коду на тему «а может ли прийти вот сюда null» или строить сомнительные предположения.
Я бы сделал так. Если непонятно где возврат null — штатная ситуация, то сначала анализировать и аннотировать. Затем все таки явно обрабатывать null там где они допустимы. Всякие удобные операторы типа .? из Groovy и Kotlina могут проглатывать null там где его быть не должно, но он вызван переходом программы в недопустимое состояние (IllegalState). В этом случае лучше все таки явно падать, а не продолжать работу.
Последнее время мне как-то везло либо на новые проекты, либо с уже какой-то внедренной политикой обработки опциональности. Поэтому посмотреть внешние стат. анализаторы с одной стороны все хочется, а с другой стороны как-то не особо и надо. Спасибо, что напомнили про FindBugs, возможно в текущем проекте это как раз то, что доктор прописал. А там как практика с ним появится, так и упомяну. :-)
Для коллекций вроде как TypeAnnotations должны эту проблему решить, так же как и для прочих Generic'ов типа Future<@Nullable User>.
Это фактически монада MayBe. Чтобы прижилось нужны лямбды, да и сама реализация мне пока только в Scala понравилась (может за счет pattern matching'а). А так да, появляются compile time проверки на опциональность. Правда за все хорошее приходится платить и в runtime будет overhead.
Скорей всего вы использовали их для Design by Contract. Помнится имплементация Hibernate Validation для первой версии стандарта так умела. Это другой подход, решающий несколько иную задачу. Здесь же речь идет не о ловле ошибки в runtime, а о том чтобы ее туда вообще не пропустить.
Java Bean Validation тоже активно использовал там, где это уместно. В плане обязательности/необязательности у них не нравится, что по-умолчанию все считается Nullable и нельзя это поменять.
В заблуждение ввела сначала вот эта часть доки:
Понял так, что раз уж аннотация должна относиться либо к модулю, либо к JDK, то и аннотировать можно только их. Ну, и единственный пример только на внешнее аннотирование собственного кода был в пользу этой версии.
Вообще круто, но в feature requests я бы добавил suggestion на добавление external annotation (если они включены) в подобных случаях:
Map<String, String> map = ImmutableMap.of("bca", "cab"); @Nullable String str = map.get("abc");Ну, и какое-то отображение в исходниках проаннотированной библиотеки, кроме Ctrl+Q. Хотя и с трудом представляю себе как. Хитрые подчеркивания разве что.
Ну, и естественно, не надо рыскать по всему коду на тему «а может ли прийти вот сюда null» или строить сомнительные предположения.
Для коллекций вроде как TypeAnnotations должны эту проблему решить, так же как и для прочих Generic'ов типа
Future<@Nullable User>.Java Bean Validation тоже активно использовал там, где это уместно. В плане обязательности/необязательности у них не нравится, что по-умолчанию все считается Nullable и нельзя это поменять.