Каковы ваши правила Java? - PullRequest
6 голосов
/ 08 октября 2008

Я изучаю Java, и мне интересно, каковы все правила Java. Правила, которые вы знаете по своей сути, и если вы видите, что кто-то нарушает их, вы пытаетесь их исправить. Вещи, которые помогут вам избежать неприятностей или помогут улучшить ситуацию. Вещи, которые вы никогда не должны делать. То, что вы всегда должны делать. Правила, которые новичок не знал бы.

Ответы [ 22 ]

20 голосов
/ 08 октября 2008

Чтение Эффективная Java от Bloch.

Это именно то, что вы просите, набор правил для написания действительно великолепного идиоматического Java-кода.

8 голосов
/ 08 октября 2008

ОК, мозговой штурм:

  • Думайте в классах и объектах, а не в функциях.
  • Избегайте пустых условий вылова (особенно catch (Throwable t) {} )
    • Обрабатывайте ошибку, не игнорируйте ее.
    • Обрабатывать только тип исключения, которое вы хотите обработать в месте, которое вы можете обработать.
  • Используйте Javadoc.
    • заставляет задуматься о том, что вы делаете.
    • Генерирует документацию при разработке.
    • Позволяет IDE, таким как Eclipse, отображать подсказки при использовании ваших классов и методов.
  • Попробуйте использовать дженерики и аннотации, чтобы привыкнуть к нему.

Есть еще много, но те, где первое, что пришло мне в голову.

Кстати, если вы перейдете от новичка к эксперту, вы будете знать, когда делать исключения из этих правил;)

7 голосов
/ 08 октября 2008

Одна из моих задач - придерживаться соглашений о кодировании Sun .

6 голосов
/ 08 октября 2008

Если вы повторяете себя, например, копируете и вставляете, вы делаете это неправильно. Java является ОО-языком, используйте его таким образом.

Если вы не используете шаблоны проектирования, вы заново изобретаете колесо. Удивительно, сколько проблем лучше всего решить с помощью оригинальных шаблонов дизайна GOF. Только после просмотра вы должны сделать что-то другое.

Сохраняйте имена методов длинными, имена параметров описательными, а методы - короткими. Это немного субъективно, но чем больше вы разбиваете на части, тем легче исправить и повторно использовать код. Если вы не можете объяснить, что ваш метод делает в предложении, у вас либо обычно сложная проблема, либо, скорее всего, ваши методы пытаются сделать слишком много.

Избегайте того, чтобы каждый объект делал слишком много. Посмотрите на имена на ваших объектах. Если в объекте есть методы, которые не связаны с именем объекта, переместите их туда, где они могут принадлежать.

Перегрузка методов хороша, и она может спасти вас от повсеместного набора типов.

Постарайтесь не быть «умным» таким образом, чтобы затруднить понимание написанного вами кода. Используйте как можно больше встроенных функций языка (например, итераторов). Сделайте самое простое, что может сработать. Вы будете благодарить себя позже.

Контроль версий необходим, даже если вы один разработчик, работающий в одиночку. Это спасло мою шею больше, чем я могу сосчитать.

После начальной отладки ничто не должно быть жестко закодировано. Для элементов, используемых в приложении, таких как среда и связанные сообщения, сохраняйте в базе данных как можно больше элементов. Если вы думаете, что эти элементы никогда не изменятся, используйте файлы свойств и глобальный java-файл для вещей, которые, как вы убеждены, никогда не изменятся, потому что они будут.

Автоматически форматируйте ваш код, используя вашу IDE, даже если это делает вас уродливым, в конечном итоге вам все равно будет лучше.

Если для чего-то существует хорошо известная и надежная структура, используйте ее. JSF или Struts будут лучше, чем все, что вы могли бы разработать самостоятельно, даже если вы думаете, что ваш собственный MVC-фреймворк действительно классный. То же самое с настойчивостью, используйте что-то основное. Старайтесь использовать как можно меньше или один фреймворк, когда это возможно. Вы можете удивить своих друзей тем, что они используют проект Spring, Shale, JSF, Struts, использующий Hibernate, вместе с другими разработанными вами фреймворками, но на самом деле это просто сложность ради сложности.

5 голосов
/ 08 октября 2008

Никогда не выполняйте трудоемкие задачи в потоке диспетчеризации событий AWT, иначе у вас будет неотвечающий графический интерфейс.

5 голосов
/ 08 октября 2008

Сравнение равенства

При выполнении сравнения на равенство подумайте, хотите ли вы сравнить на предмет равенства значений (имеют ли два объекта одинаковое значение) или ссылочного равенства (являются ли они одним и тем же экземпляром объекта). Для равенства ссылок используйте оператор ==; для равенства значений вы, как правило, захотите использовать метод .equals().

(Обратите внимание, что неосновные классы Java могут иметь или не иметь значимой реализации .equals (); большинство базовых классов имеют хорошую реализацию .equals ().)

Например, обычной ошибкой было бы сделать (string1 == string2), чтобы попытаться определить, представляют ли строковые переменные string1 и string2 одинаковое строковое значение.

5 голосов
/ 08 октября 2008

Ты должен документировать свой код!

  • Вы должны документировать весь код, который вы пишете. Когда вы вернетесь и прочитаете его через 3 месяца, очень важно, чтобы вы оставили некоторые подсказки о том, что делает код.
  • Вы не должны документировать что делает код, как он есть, в коде.
  • Вы должны, однако, документ , почему код там. Вы получите гораздо больше пользы от комментариев «почему», чем от комментариев «что» в долгосрочной перспективе.
  • Если это трудно документировать, скорее всего, вы недостаточно подумали о проблеме.
3 голосов
/ 08 октября 2008

Используйте проверено (объявлено) исключение, если нет способа гарантировать, что исключение не произойдет, но убедитесь, что исключение задокументировано в контракте (JavaDoc). Наказывайте звонящего с помощью исключения unchecked (во время выполнения), если звонящий нарушил договор, например, передается в нулевом аргументе, когда в контракте указано, что аргумент не может быть нулевым.

3 голосов
/ 08 октября 2008

всегда пишите модульные тесты в максимально возможной степени. Существует 2 основных фреймворка для юнит-тестов - junit и TestNG. У каждого из них есть экосистема других расширений для тестирования. модульные тесты дают вам уверенность. После того, как кто-то добавил новый или измененный код, вы можете определить, не работает ли система или нет, выполнив все модульные тесты.

Кроме того, сообщество Java охватило системы непрерывной интеграции. Многие из них имеют открытый исходный код - планируйте регулярное создание программного обеспечения. Если вы можете, разверните его и запустите на них интеграционные тесты, НО, как минимум, регулярно создавайте и запускайте модульные тесты.

3 голосов
/ 08 октября 2008

Просмотрите API Java. Особенно пакет утилит. Там есть много библиотек для выполнения общих задач, и их повторное использование намного лучше, чем использование собственных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...