Комментарии 27
Забавно… Нарыл несколько ошибок в своем тексте, а поправить не могу — Возникла ошибка в получении XML данных:
Internal Server Error
Internal Server Error
Спасибо за статью, обязательно посмотрю плагин. Подобные вещи очень сильно помогают делать код более профессиональным.
А зачем вызывать сборщик мусора? Ведь не факт, что он он будет вызван.
яве всё равно, а разработчику приятно :)
Простите, не совсем понял Ваш вопрос.:)
Calling the gc method suggests to run garbage collection, not orders to
Просто немного запутанная формулировка.
«А зачем вызывать сборщик мусора вручную?»
и
«А зачем вызывать сборщик мусора, если он может быть не вызван?»
это два немного разных вопроса.:)
«А зачем вызывать сборщик мусора вручную?»
и
«А зачем вызывать сборщик мусора, если он может быть не вызван?»
это два немного разных вопроса.:)
Зачем вообще вызывать сборщик мусора? И зачем его вызываете лично Вы, если никто не гарантирует, что он вызовется? :)
Лично я его не вызываю:) Но, в нашем продукте, он вызывается в тех местах, где в результате некоторых действий (построения некого формата, прохождения объёмных транзакций etc.) могут оставаться большие висячие куски данных в памяти, ожидающих следующие циклы сборки мусора. Вот и приходится заставлять jvm заниматься уборкой в форс мажорном порядке. Насколько я помню gc() не вызывается если при запуске установлена опция -Xdisableexplicitgc.
Советую попробовать плагин с подобной функциональностью:
checkstyle.sourceforge.net/
eclipse-cs.sourceforge.net/
Было бы интересно узнать, насколько отличаются результаты проверки кода у этих плагинов
checkstyle.sourceforge.net/
eclipse-cs.sourceforge.net/
Было бы интересно узнать, насколько отличаются результаты проверки кода у этих плагинов
очень много сомнительных предупреждений вроде «Avoid using if… else statements without using curly braces», имеющих отношение больше к субъективным представлениям о красоте кода, чем к реальным проблемам
Полностью с Вами согласен, что и пытался передать в статье. Но, опять же, такого рода «предупреждения» относятся 3-5 приоритетам. На них вообще внимания обращать не стоит, ИМХО.
В основном такие плагины следуют букве Sun Code Conventions.
Это действительно вопрос красоты и удобства чтения.
Есть рекомендуемый стиль кода.
И лично я не вижу преимуществ у кода, который не соответствует SCC.
Другое дело, что иногда нету преимуществ у кода, который причесан под SCC.
Поэтому если плагин применяется под существующий код, то исправлять множество таких предупреждений смысла нету.
Но для нового кода плагин полезен. Сразу во время написания кода видишь предупреждения и исправляешь.
Времени это не отнимает совсем.
Это действительно вопрос красоты и удобства чтения.
Есть рекомендуемый стиль кода.
И лично я не вижу преимуществ у кода, который не соответствует SCC.
Другое дело, что иногда нету преимуществ у кода, который причесан под SCC.
Поэтому если плагин применяется под существующий код, то исправлять множество таких предупреждений смысла нету.
Но для нового кода плагин полезен. Сразу во время написания кода видишь предупреждения и исправляешь.
Времени это не отнимает совсем.
Ыщо есть findbugs.sourceforge.net/
Есть.
Неплохая вещь, я у себя нашел несколько хороших предложений по улучшению качества кода.
Но, как и в случае с PDM, некоторые предупреждения обсуждаемы и их иногда хочется выключить. Особенно те, которые конфликтуют со стилем, в котором пишутся например Eclipse вещи. Но увы, фильтровать на уровне compilation unit'а плагин не помогает. В FindBugs кажется есть фильтры, но писать их руками неудобно.
Лично для меня, когда в проекте есть предупреждения я стараюсь их ВСЕ исправить. Просто чтобы всегда было чисто и всегда видел, что появилась новая проблема, которую нужно исправить. А в данном случае не получается. Что огорчает и заставляет отказать от использования, ибо стоимость просмотра всех сообщений каждый раз представляется выше, чем полученная выгода от полезных предложений.
Неплохая вещь, я у себя нашел несколько хороших предложений по улучшению качества кода.
Но, как и в случае с PDM, некоторые предупреждения обсуждаемы и их иногда хочется выключить. Особенно те, которые конфликтуют со стилем, в котором пишутся например Eclipse вещи. Но увы, фильтровать на уровне compilation unit'а плагин не помогает. В FindBugs кажется есть фильтры, но писать их руками неудобно.
Лично для меня, когда в проекте есть предупреждения я стараюсь их ВСЕ исправить. Просто чтобы всегда было чисто и всегда видел, что появилась новая проблема, которую нужно исправить. А в данном случае не получается. Что огорчает и заставляет отказать от использования, ибо стоимость просмотра всех сообщений каждый раз представляется выше, чем полученная выгода от полезных предложений.
PMD — это скорее рекомендация обратить внимание на потенциально ошибочный код, следовать ей или нет — это уже по ситуации. А за code convention-ом и т.п. должен следить checkstyle.
У нас на большинстве проектов по дефолту ставится и PMD и CheckStyle, + их статистика собирается автобилдами. Такой подход в больших проектах реально полезен.
У нас на большинстве проектов по дефолту ставится и PMD и CheckStyle, + их статистика собирается автобилдами. Такой подход в больших проектах реально полезен.
Пользовался им в IDEA (7+)
Чесьно говоря, мне встроенный в идею анализатор кода понравился гораздо больше.
И более информативный диагноз и упрощённое исправление (прямо тут можно нажать на линк и он исправит).
Чесьно говоря, мне встроенный в идею анализатор кода понравился гораздо больше.
И более информативный диагноз и упрощённое исправление (прямо тут можно нажать на линк и он исправит).
А вы не пользовались TPTP (eclipse.org/tptp)?
Интересно было бы узнать различия.
Интересно было бы узнать различия.
Overridable method called during object construction
…
То есть, с их точки зрения, в конструкторах должна присутствовать только прямая инициализация внутренних параметров плюс весь сопутствующий код. А если этого кода много? А если он не один раз используется? В общем если неукоснительно следовать этому правилу, то это солидно усложняет жизнь.
Ну так если код дублируется в разных конструкторах одного класса, то его надо выносить в приватные методы, а если он дублируется в конструкторах подклассов, то вызывать родительские конструкторы, вызывающие эти приватные методы. Или я чего-то не так понял?
Речь не о дублируемости кода в конструкторах одного класса или разных классов одной иерархии. Просто если в конструкторе Вам понадобится вызвать метод xxx(), и этот метод будет не приватным — то есть будет необходимость его использовать из других точек кода — тогда PMD будет ругаться.
Например
Например
*извините, глюк вышел
Так вот например, если в конструкторе кроме
this.a = a;
this.b = b;
нужна еще какая-либо инициализация, то с точки зрения PMD она должна быть либо вынесена в приватный метод, либо происходить прямо там. А это далеко не всегда оправдано.
Так вот например, если в конструкторе кроме
this.a = a;
this.b = b;
нужна еще какая-либо инициализация, то с точки зрения PMD она должна быть либо вынесена в приватный метод, либо происходить прямо там. А это далеко не всегда оправдано.
В нашей компании статический анализатор кода (корпоративный) запускается на ночных билдах. В начале он нашел довольно много серьезных ошибок типа возможных NPE, незакрытых потоков, SQL injection'ов и т. д. Постепенно исправили. Только потом начали искать и править вещи типа {s = new String(«aaa»);} — из любви к искусству.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Впечатления от Eclipse-плагина PMD