Мне хотелось бы, если возможно, показать обозреватель пакетов, чтобы показать порядок, в котором все определяется в исходном файле.Получить обозреватель пакетов для определения порядка определения в исходном файле Java
Я знаю, что в настройках порядка сортировки Java -> Appearance -> Member, вы можете указать, какие категории категорий определений появляются (поля, методы, внутренние классы и т. Д.), Но не порядок в пределах эти категории. (Ну, вы можете заказать видимость внутри них, но ничего больше.) По всей видимости, это только алфавитный порядок в этой категоризации.
Quick Outline view (Ctrl-O) делает это как в исходном порядке, и я мог бы также collapse all code blocks получить аналогичную схему в редакторе, но я предпочитаю использовать проводник пакетов для навигации.
Например, для класса, реализующего несколько интерфейсов, я группирую методы по интерфейсу и сохраняю порядок методов, как определено в интерфейсе. Кроме того, я отделяю частные методы утилиты и т. Д. Как я уверен, большинство людей делают это, я также по умолчанию заказываю видимость, если нет определенных «логических областей» класса и будет иметь тенденцию иметь «под-методы» ниже их вызывающих.
(Было бы еще лучше, если бы можно было перетащить определения, чтобы изменить порядок их в файле, хотя свернутый вид редактора очень хорошо для этого.)
Что, если что-нибудь, поймают меня ближе к этому мнению? (Или, если хотите, есть ли причины, почему это желание глупо?)
Относительно вашего комментария «большинство людей» Я не с вами. Я отказываюсь от сортировки в моем файле Java «логически». Если вы работаете в командах, трудно сохранить этот порядок. Вместо этого я сортирую своих членов класса «в алфавитном порядке» - это поддерживается IDE и воспроизводится для всех. Я также нарушаю привычку прокручивать и искать что-то. Вместо этого я использую 'Strg-o', чтобы быстро перейти к моему искомому участнику. Для меня это намного эффективнее. Тем не менее я могу понять ваш подход - удачи в поиске ответа на ваш вопрос. – FrVaBe
@ K.Claszen Яркий вид (особенно для крупных распределенных команд). Однако для реализации интерфейса и переопределенных методов суперкласса мне кажется безумно нелогичным, чтобы я не группировал методы, связанные с этими другими классами/интерфейсами. В этом контексте в алфавитном порядке слишком много похоже на потворство (потенциально временным) слабостям инструмента (например, этот вопрос!) Или слабым/неряшливым членам команды. Тем не менее, будучи ветераном нескольких мучительных дебатов о стандартах кодирования в компаниях, у меня есть некоторые симпатии к вашему мнению :-) –