Изучение любого нового языка программирования по традиции начинается с программы, выводящей сообщение «Hello, World!» (Здравствуй, мир!). Именно этим мы и займемся в этой статье.
Итак, приведем без лишних слов исходный код программы «Hello, World!» на Java.
package chOl.secOl; // Первая программа на Java public class HelloWorld < public static void main(String[] args) < System.out.println(«Hello, World!»); >>
Анализ первой программы на Java “Hello World”
Ниже приведен краткий анализ этой программы.
- Язык Java является объектно-ориентированным. В программе на Java приходится манипулировать объектами, чтобы выполнить с их помощью нужные действия. Практически каждый манипулируемый объект принадлежит к определенному классу. В классе определяется назначение объекта. В языке Java весь код определяется в классе. А рассматриваемая здесь программа состоит из единственного класса HelloWorld.
- Метод main () представляет собой функцию, объявляемую в классе. Это первый метод, вызываемый при выполнении программы. Он объявляется как статический (static), а это означает, что данный метод не оперирует никакими объектами. (Когда метод main () вызывается, имеется совсем немного предопределенных объектов, но ни один из них не является экземпляром класса HelloWorld.) Данный метод объявляется также как пустой (void), а это означает, что он не возвращает никакого значения. Подробнее о назначении объявления параметров String[] args мы обязательно расскажем в дальнейшем.
- Многие языковые средства Java можно объявлять как открытые (public) или закрытые (private), хотя имеются и другие уровни их доступности. В данном примере класс HelloWorld и метод main() объявляются как public, что наиболее характерно для классов и методов.
- Пакет состоит из взаимосвязанных классов. Каждый класс целесообразно размещать в пакете, чтобы различать несколько классов с одинаковым именем. Таким образом, полное имя рассматриваемого здесь класса будет следующим: ch0l.sec0l.HelloWorld. Подробнее о пакетах и их условных обозначениях речь пойдет в дальнейших статьях моего блога.
- Строка кода, начинающаяся со знаков //, содержит комментарий. Все символы от знаков // и до конца строки игнорируются компилятором и предназначены только для чтения человеком, а не машиной.
- И наконец, рассмотрим тело метода main(). Оно состоит из единственной строки кода, содержащей команду для вывода сообщения в объект System, out, представляющий стандартный поток вывода результатов выполнения программ на Java.
Как видите, Java не является языком написания сценариев, на котором можно быстро написать несколько команд. Этот язык специально предназначен для разработки крупных программ, которые выгодно отличаются организацией в классы и пакеты.
24 Массивы #java #shorts #программирование #урокипрограммирования #javaуроки
Кроме того, язык Java довольно прост и единообразен. В некоторых языках допускаются глобальные переменные и функции, а также переменные и методы в классах. А в Java все объявляется в классе. Подобное единообразие может привести к несколько многословному коду, но в го же время оно упрощает понимание назначения программы.
Программирование на Java для начинающих: #1 (JDK и Hello World!)
ВАЖНО! Как пояснялось выше, комментарий простирается от знаков // и до конца строки. Можно составить и многострочные комментарии, ограничив их разделителями /* и */ , как показано ниже.
/* Это первый пример программы на Java в Вашей жизни! Эта программа выводит традиционное приветствие «Hello, World!». */
Имеется и третий стиль комментария, называемого документирующим. В этом случае комментарий ограничивается разделителями /** и */, как будет показано в следующей части статьи.
Компилирование и выполнение первой программы на Java
Чтобы скомпилировать и выполнить рассматриваемую здесь программу на Java, нужно установить комплект разработки программ на Java под названием Java Development Kit (JDK), а дополнительно, хотя и не обязательно, — интегрированную среду разработки (ИСР). Кроме того, следует загрузить исходный код из данного примера, обратившись на данный веб-сайт. Читать инструкции по установке программного обеспечения неинтересно — их можно найти на том же веб-сайте.
Установив комплект JDK, откройте окно терминала, перейдите к каталогу, содержащему каталог chOl, и выполните приведенные ниже команды. Уже знакомое вам приветствие появится в окне терминала (рис. 1).
Рис. 1. Выполнение первой программы на Java в окне терминала
javac chOl/secOl/HelloWorld.java java chO1.secO1.HelloWorId
Обратите внимание на двухэтапный процесс выполнения программы. Сначала по команде javac исходный код Java компилируется в промежуточное представление, называемое байт-кодом, а результат сохраняется в файлах классов. Затем по команде java запускается виртуальная машина, загружающая файлы классов и выполняющая байт-коды.
После компиляции байт-коды можно выполнять на любой виртуальной машине Java, будь то настольный компьютер или вычислительное устройство в далекой галактике. Обещание «написано однажды — выполняется везде» было важным критерием разработки языка Java.
НА ЗАМЕТКУ. Компилятор javac вызывается с именем файла, имеющего расширение .java, причем знаками косой черты разделяются сегменты пути к этому файлу. Загрузчик виртуальной машины java вызывается с именем класса, причем знаками точки разделяются сегменты пакета, а расширение файла не указывается.
Чтобы выполнить рассматриваемую здесь программу в ИСР (инструментальная среда разработки), нужно сначала создать проект, как поясняется в инструкциях по установке, а затем выбрать класс HelloWorld и дать ИСР команду на выполнение программы. На рис. 2 показано, как это выглядит в Eclipse — распространенной ИСР, хотя имеются и другие отличные ИСР. Освоившись немного с программированием на Java, опробуйте несколько ИСР, чтобы выбрать для себя наиболее подходящую.
Рис. 2. Выполнение первой программы на Java в ИСР Eclipse
Примите поздравления! Вы только что выполнили свою первую программу на Java, следуя освященному временем ритуалу вывода сообщения «Hello, World!”. А теперь можно перейти к рассмотрению основ языка Java.
Вызовы методов в программе Java
Рассмотрим более подробно следующий оператор, оказывающийся единственным в теле метода main (): System.out.println(«Hello, World!»);
В приведенном выше операторе System.out является объектом. Это экземпляр класса PrintStream. В классе PrintStream имеются методы println (), print () и т.д., которые называются методами экземпляра, поскольку они оперируют объектами или экземплярами класса. Чтобы вызвать метод экземпляра для объекта, следует воспользоваться записью через точку, как показано ниже.
объект.ИмяМетода (аргументы)
В рассматриваемом здесь примере указан единственный аргумент метода — символьная строка «Hello, World!».
Рассмотрим другой пример. Символьные строки вроде «Hello, World!» являются экземплярами класса String. В классе String имеется метод length() , возвращающий длину объекта типа String. Чтобы вызвать этот метод, можно снова воспользоваться записью через точку, как показано ниже.
«Hello, World!”.length()
В данном примере метод length() вызывается для объекта «Hello, World!», и у него отсутствуют аргументы. В отличие от метода println() , метод length() возвращает результат. В приведенном ниже примере показано, как воспользоваться этим результатом, чтобы вывести его.
System.out.println(«Hello, World!». length());
Опробуйте этот пример. Создайте для этого программу на Java с приведенным выше оператором и выполните ее, чтобы выяснить длину символьной строки «Hello, World!».
В отличие от готовых к применению объектов вроде System, out и «Hello, World!», большинство объектов в Java приходится строить. Рассмотрим еще один простой пример. Объект класса Random способен генерировать случайные числа. А строится объект типа Random с помощью оператора new следующим образом:
new Random()
После имени класса в этом операторе указывается список аргументов для построения объекта. В данном примере этот список пуст. Для построенного таким образом объекта можно вызвать метод. Так, в результате вызова
new Random().nextlnt()
получается следующее целое число, предоставляемое вновь построенным генератором случайных чисел.
Если для объекта требуется вызвать несколько методов, его следует сохранить в переменной (подробнее об этом будет рассказано в новых статьях моего блога). В следующем примере кода выводятся два случайных числа:
Random generator = new Random(); System.out.println(generator.nextInt ()); System.out.printIn(generator.nextInt());
НА ЗАМЕТКУ. Класс Random объявляется в пакете java.util. Чтобы воспользоваться им в программе, достаточно ввести оператор import в ее исходный код следующим образом:
package chOl.secOl; import java.util.Random; public class MethodDemo
Источник: oracle-patches.com
Рекомендации к стилю кода
Существуют соглашения, по поводу использования Java библиотек и инструментов для Android. В некоторых случаях соглашения могут быть изменены, например, в таких как использование старого кода, который, возможно, использует неодобренный паттерн или библиотеку.
Правила Java стиля
Программы гораздо проще поддерживать, когда все файлы имеют согласованный стиль. Мы следуем стандартному стилю программирования на Java, определенному Sun в их Code Conventions for the Java Programming Language, с несколькими исключениями и дополнениями. Данное руководство по стилю является подробным и всесторонним, а также широко используется Java сообществом.
- Комментарии/Javadoc: пишите их; используйте стандартный стиль.
- Короткие методы: не пишите гигантских методов.
- Поля: должны быть вверху файла, или прямо перед методом, который их использует.
- Локальные переменные: ограничивайте область видимости.
- Импорты: android; сторонние (в алфавитном порядке); java(x)
- Отступы: 4 пробела, без табуляций.
- Длина строки: 100 символов.
- Имена полей: не public и не static поля начинаются с «m».
- Фигурные скобки: открывающие фигурные скобки не находятся в отдельной строке.
- Аннотации: используйте стандартные аннотации.
- Сокращения: используйте сокращения как слова в именах, например, XmlHttpRequest, getUrl() и т.п.
- Стиль TODO: «TODO: пишите описание здесь».
- Согласованность: смотрите, что находится вокруг вас.
Правила языка Java
Не игнорируйте исключения
Возможно, вам захочется написать код, который игнорирует исключения, например:
void setServerPort(String value) < try < serverPort = Integer.parseInt(value); >catch (NumberFormatException e) < >>
-
Перебрасывайте исключения к вызывающему методу.
void setServerPort(String value) throws NumberFormatException
void setServerPort(String value) throws ConfigurationException < try < serverPort = Integer.parseInt(value); >catch (NumberFormatException e) < throw new ConfigurationException(«Port » + value + » is not valid.»); >>
/** Set port. If value is not a valid number, 80 is substituted. */ void setServerPort(String value) < try < serverPort = Integer.parseInt(value); >catch (NumberFormatException e) < serverPort = 80; // default port for server >>
/** Set port. If value is not a valid number, die. */ void setServerPort(String value) < try < serverPort = Integer.parseInt(value); >catch (NumberFormatException e) < throw new RuntimeException(«port » + value » is invalid, «, e); >>
/** If value is not a valid number, original port number is used. */ void setServerPort(String value) < try < serverPort = Integer.parseInt(value); >catch (NumberFormatException e) < // Method is documented to just ignore invalid user input. // serverPort will just be unchanged. >>
Не перехватывайте обобщенные исключения
Иногда бывает заманчиво полениться с обработкой исключений и написать что-то вроде этого:
try < someComplicatedIOFunction(); // may throw IOException someComplicatedParsingFunction(); // may throw ParsingException someComplicatedSecurityFunction(); // may throw SecurityException // phew, made it all the way >catch (Exception e) < // I’ll just catch all exceptions handleError(); // with one generic handler! >
Вам не следует так делать. Суть в том, что возможно появление исключения, которого вы не ожидали и, в итоге, ошибка будет отлавливаться на уровне приложения. То есть, если кто-то добавит новый тип исключения, то компилятор не сможет вам помочь понять, что это другая ошибка.
Существуют редкие исключения из этого правила: определенный тестовый код, или код верхнего уровня, где вы хотите перехватывать все типы ошибок (для того, чтобы предотвратить их отображение в пользовательском интерфейсе, или чтобы продолжить какую-то пакетную задачу).
- Перехватывайте каждое исключение отдельно в блоке catch, после одиночного try. Возможно это неудобно, но всё равно это предпочтительный способ для перехвата всех исключений.
- Измените ваш код для более гранулированной обработки ошибок с несколькими блоками try. Отделите IO от парсинга, обрабатывайте ошибки отдельно в каждом случае.
- Перебросьте исключение. Во многих случаях вам не нужно обрабатывать все исключения на текущем уровне, просто позвольте методу перебросить их.
Финализаторы
Что это: Финализаторы — это способ запускать программный код перед тем как объект собирается сборщиком мусора.
За: могут быть полезны при очистке, в особенности внешних ресурсов.
Против: нет никаких гарантий того, когда будет вызван финализатор, и, вообще, будет ли он вызван.
Решение: Мы не используем финализаторы. В большинстве случаев, всё то, что вам нужно от финализатора, вы сможете сделать при помощи обработки исключений. Если вам действительно нужен финализатор, то объявите метод close() и задокументируйте, когда он точно будет вызываться.
Импорты
Групповой символ в импортах
import foo.*;
import foo.Bar;
Решение: Используйте стиль #2 для импорта любого Android кода. Явное исключение делается для стандартных библиотек (java.util.*, java.io.*, и т.п) и для кода модульного тестирования (junit.framework.*).
Комментарии/Javadoc
Каждый файл должен иметь объявление об авторских правах в самом начале. Далее идут объявления операторов package и import, причем каждый блок разделяется пустой строкой. За ними следуют объявления класса или интерфейса. Опишите, что делает класс в Javadoc-комментариях.
/* * Copyright (C) 2010 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the «License»); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an «AS IS» BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.android.internal.foo; import android.os.Blah; import android.view.Yada; import java.sql.ResultSet; import java.sql.SQLException; /** * Does X and Y and provides an abstraction for Z. */ public class Foo
Каждый класс и нетривиальный public метод должен содержать Javadoc, по крайней мере с одной фразой, описывающей что он делает. Фраза должна начинаться с описательного глагола 3-го лица. Примеры:
/** Returns the correctly rounded positive square root of a double value. */ static double sqrt(double a) < >/** * Constructs a new String by converting the specified array of * bytes using the platform’s default character encoding. */ public String(byte[] bytes)
Вам не нужно описывать Javadoc для тривиальных get и set методов, таких как setFoo(), если ваш Javadoc говорит только «sets Foo». Если метод делает что-то более сложное (например, соблюдение неких ограничений, или если его действия имеют важный эффект вне его самого), тогда его обязательно нужно задокументировать. И если это не просто объяснение того, что означает Foo, то вам также следует его задокументировать.
Вообще, любой метод, который вы написали получает пользу от Javadoc, неважно public он или нет. Public методы являются частью API, и поэтому они требуют описания в Javadoc.
Для написания Javadoc’ов вам следует придерживаться Sun Javadoc conventions.
Короткие методы
Методы должны быть небольшими и решающими конкретную задачу настолько, насколько это возможно. Однако, понятно, что иногда большие методы бывают целесообразны, так что нет строгого ограничения на длину метода. Если метод превышает 40 строк, то вам, возможно, стоит подумать о том, можно ли его разбить на части, не нарушив структуры программы.
Локальные переменные
Область видимости локальных переменных должна сводиться к минимуму. Делая это, вы улучшаете читаемость и поддерживаемость кода, а также уменьшаете вероятность ошибок. Каждая переменная должна объявляться в самом глубоком блоке, который окружает все возможные места использования переменной.
Локальные переменные должны объявляться в том месте, где впервые необходимо её использовать. Почти каждая локальная переменная нуждается в инициализаторе. Если вы еще не знаете, как точно инициализировать переменную, то вам следует отложить её объявление, пока вы это не узнаете.
Существует одно исключение, касательно блока try-catch. Если переменная инициализируется при помощи оператора return метода, который выбрасывает проверяемое исключение, то она должна инициализироваться в блоке try. Если же переменная должна использоваться вне блока try, тогда она объявляется перед ним, неважно, знаете ли вы как её точно нужно инициализировать:
// Instantiate class cl, which represents some sort of Set Set s = null; try < s = (Set) cl.newInstance(); >catch(IllegalAccessException e) < throw new IllegalArgumentException(cl + » not accessible»); >catch(InstantiationException e) < throw new IllegalArgumentException(cl + » not instantiable»); >// Exercise the set s.addAll(Arrays.asList(args));
Но даже этот случай можно обойти при помощи инкапсуляции блока try-catch в методе.
Set createSet(Class cl) < // Instantiate class cl, which represents some sort of Set try < return (Set) cl.newInstance(); >catch(IllegalAccessException e) < throw new IllegalArgumentException(cl + » not accessible»); >catch(InstantiationException e) < throw new IllegalArgumentException(cl + » not instantiable»); >> . // Exercise the set Set s = createSet(cl); s.addAll(Arrays.asList(args));
Переменные в циклах должны объявляться внутри самого оператора, если только нет непреодолимой причины этого не делать.
for (int i = 0; i for (Iterator i = c.iterator(); i.hasNext(); )
Импорты
- Android импорты.
- Сторонние импорты (com, junit, net, org).
- java и javax.
- Отсортированы по алфавиту внутри каждой группы.
- Заглавные буквы должны быть впереди букв нижнего регистра (например, Z перед a).
- Главные группы должны разделяться пустой строкой.
- Импорты, которые люди хотят видеть в первую очередь, находятся вверху (android).
- Импорты, которые люди хотят видеть в последнюю очередь, находятся внизу (java).
- Люди могут с легкостью использовать этот стиль.
- IDE может придерживаться этого стиля.
Отступы
мы используем 4 пробела для блоков. Мы никогда не используем табуляцию. Мы используем 8 пробелов для переноса строк, включая вызовы функций и присваивания, например правильно так:
Instrument i = someLongExpression(that, wouldNotFit, on, one, line);
а так неверно:
Instrument i = someLongExpression(that, wouldNotFit, on, one, line);
Названия полей
- Не static и не public имена начинаются c «m».
- static поля начинаются с «s».
- Другие поля начинаются с буквы нижнего регистра.
- Поля public static final (константы) пишутся полностью в верхнем регистре, с использованием подчеркивания (ALL_CAPS_WITH_UNDERSCORES)
public class MyClass
Фигурные скобки
Для открывающих фигурные скобок не выделяется отдельная строка, они находятся в той же строке, что и код перед ними:
class MyClass < int func() < if (something) < // . >else if (somethingElse) < // . >else < // . >> >
Мы требуем фигурные скобки для оператора условия. Исключением является, когда оператор условия и его тело помещаются в одну строку. То есть можно писать так:
if (condition) < body(); // ok >if (condition) body(); // ok
Но так нельзя:
if (condition) body(); // bad
Длина строки
Каждая строка текста в коде должна быть не длиннее 100 символов.
Исключение: если комментарий содержит пример команд, или URL (удобнее использовать copy/paste).
Исключение: строки импорта могут быть длиннее 100 символов, так как люди редко на них смотрят. Также это упрощает написание инструментов.
Сокращения в именах
Рассматривайте сокращения и аббревиатуры как слова. Имена более удобочитаемы:
| Хорошо | Плохо |
| XmlHttpRequest | XMLHTTPRequest |
| getCustomerId | getCustomerID |
Этот стиль также применяется, когда сокращение и аббревиатура — это полное имя:
| Хорошо | Плохо |
| class Html | class HTML |
| String url; | String URL; |
| long id; | long ID; |
Стиль TODO
Используйте комментарии TODO для кода, который является временным, краткосрочным, или хорошим, но не идеальным. Комментарий должен включать в себя «TODO:», например:
// TODO: Remove this code after the UrlTable2 has been checked in. // TODO: Change this to use a flag instead of a constant.
Если ваш комментарий имеет вид «В будущем сделать что-то», то убедитесь, что он включает в себя конкретную дату (1 января 2011 года), или конкретное событие «Удалить после выхода версии 2.1».
Согласованность
Если вы изменяете код, то потратьте минуту на то, чтобы посмотреть на код вокруг вас и определить его стиль. Если в нем используются пробелы, то и вам следует их использовать. Если комментарии содержат небольшой набор звездочек, то и вам следует их использовать.
Весь смысл рекомендаций к стилю кода в создании общей лексики, чтобы люди концентрировались на том, что они говорят, вместо того как они говорят. Мы представляем глобальные правила стиля, чтобы люди знали эту лексику. Но локальный стиль также важен. Если код, который вы добавляете в файл выглядит резко отличным от того, что был, то это выбросит будущего читателя из его ритма и будет мешать ему понимать структуру. Старайтесь избегать этого.
- android code style
- андроид
- стиль кода
Источник: habr.com
Написание хорошего Java-кода
Вы уже знаете достаточно много о синтаксисе Java, но это не совсем то, в чем заключается профессиональное программирование. Что делает Java-программы «хорошими»?
Вероятно, существует столько ответов на этот вопрос, сколько имеется профессиональных Java-программистов. Но у меня есть несколько предложений, с которыми, я уверен, согласились бы большинство профессиональных Java-программистов, и которые улучшают качество Java-кода.
По правде говоря, я являюсь сторонником agile-методов (динамичных методов), таких как Экстремальное Программирование (Extreme Programming — XP), поэтому многое в моих представлениях о «хорошем» коде сформировано agile-сообществом и, в частности, принципами XP. Тем не менее, я считаю, что большинство опытных профессиональных Java-программистов согласилось бы с советами, которые я дам в данном разделе.
Делайте классы маленькими
В данном руководстве мы создали простой класс Adult . Даже после того, как мы переместили метод main() в другой класс, Adult имел более 100 строк кода. Он имеет более 20 методов, и, в действительности, выполняет не много работы в сравнении со многими профессионально созданными классами, которые вы, вероятно, видите (и создаете). Это маленький класс.
Нередко можно увидеть классы с числом методов от 50 до 100. Что делает их хуже классов, имеющих меньшее число методов? Наверное, ничего. Должно быть столько методов, сколько вам нужно. Если вам нужно несколько вспомогательных методов, выполняющих, в основном, одинаковую работу, но принимающих различные параметры (как наши методы addMoney() ), — это прекрасный вариант.
Просто ограничивайте список методов только теми, которые действительно нужны, не более.
Обычно класс с очень большим числом методов содержит нечто, ему не свойственное, поскольку такой гигантский объект делает слишком много. В своей книге «Рефакторинг» Мартин Фаулер (Martin Fowler) называет это «загрязнением кода чуждыми методами» (Foreign Method code smell). Если у вас есть объект со 100 методами, вы должны хорошо подумать, не является ли этот один объект в действительности комбинацией нескольких объектов. Большие классы обычно отстают в школе. То же самое касается и Java-кода.
Делайте методы маленькими
Маленькие методы также предпочтительны, как и маленькие классы, и по тем же причинам.
Одним из огорчений, которые есть у опытных ОО-программистов в отношении языка Java, является то, что он дает широким массам пользователей объектно-ориентированный подход, но не учит их, как им правильно пользоваться. Другими словами, он дает достаточно веревки, чтобы повеситься (хотя и меньше, чем дает C++). Обычно это можно увидеть в классе с методом main() длиной в пять миль, или в одном методе под названием doIt() .
То, что вы можете поместить весь ваш код в один метод вашего класса, не означает, что вы должны это делать. Язык Java имеет больше синтаксических излишеств, чем большинство других ОО-языков, поэтому некоторая многословность необходима, но не злоупотребляйте этим.
Представьте себе на минутку такие очень длинные методы. Перелистывание на экране десятков страниц кода для того, чтобы понять, что происходит, затрудняет понимание! Что делает метод? Вы должны выпить большую чашку кофе и изучать код несколько часов, для того чтобы понять это. Маленький, даже крошечный, метод является легко перевариваемым фрагментом кода.
Эффективность во время исполнения не является причиной создания маленьких методов. Настоящим призом является читаемость. Это делает ваш код легким в обслуживании и в модификации при добавлении новых функциональных возможностей.
Ограничивайте каждый метод до производительности одного действия.
Называйте методы правильно
Лучшая из когда-либо встреченных мной схем кодирования (и я забыл источник) называется: обнаруживающие намерения имена методов. Какой из двух следующих методов легче понять с первого взгляда?
Ответ должен быть очевидным. По некоторым причинам программисты испытывают антипатию к длинным именам. Конечно, абсурдно длинное имя может быть неудобным, но достаточная для понимания длина имени обычно не является абсурдно большой. У меня нет проблем с таким именем метода, как aReallyLongMethodNameThatIsAbsolutelyClear() . Но если в три часа ночи, пытаясь понять, почему моя программа не работает, я встречаю метод с названием a() , то хочу кого-нибудь ударить.
Потратьте несколько минут на очень описательное имя метода (если это возможно), придумайте имена методов таким образом, чтобы ваш код читался больше как английский текст, даже если это означает добавление дополнительных вспомогательных методов для выполнения работы. Например, обдумаем добавление вспомогательного метода, для того чтобы сделать следующий код более читаемым:
if (myAdult.getWallet().isEmpty())
Метод isEmpty() объекта ArrayList полезен сам по себе, но это условие в нашем выражении if можно улучшить, применив метод Adult с названием hasMoney() , который выглядит следующим образом:
public boolean hasMoney()
Теперь наше выражение if больше похоже на английский:
if (myAdult.hasMoney())
Этот технический прием прост и, возможно, в данном случае тривиален, но он поразительно эффективен, когда код усложняется.
Минимизируйте количество классов
Одним из правил простого дизайна в XP является достижение цели с минимально необходимым количеством классов. Если вам нужен еще один класс, конечно же, добавьте его. Если еще один класс упростил бы код или облегчил бы выражение ваших намерений, добавьте класс. Но нет причин иметь классы только для того, чтобы иметь их.
Чаще всего в ранних версиях проекта имеется меньшее количество классов, чем в окончательной версии, но обычно легче выполнить рефакторинг для разбиения вашего кода на большее количество классов, чем для их объединения. Если у вас есть класс с большим количеством методов, проанализируйте его и определите, не содержится ли в нем другой объект, прежде чем это проявится явно. Если да, создайте новый объект.
Почти во всех моих Java-проектах никто не боялся создавать классы, но мы также постоянно пытались уменьшить количество классов, не делая наши намерения менее ясными.
Минимизируйте количество комментариев
Я когда-то писал обширные комментарии в моих программах. Вы могли читать их как книгу. Потом я стал немного умнее.
Каждая программа обучения науке программирования, каждая книга по программированию и множество программистов, я уверен, советуют вам комментировать свой код. В некоторых случаях комментарии полезны. Во многих случаях они делают код более трудным для поддержки. Подумайте о том, что вы должны сделать при изменении кода. Есть в этом месте комментарий?
Если есть, вам лучше бы менять комментарий, иначе он будет устаревшим и со временем может вовсе не описывать код. Исходя из моего опыта, это удваивает ваше время на обслуживание программы.
Мое практическое правило: если код настолько тяжело прочитать и понять, что нужен комментарий, я должен сделать его достаточно понятным, для того чтобы комментарий был не нужен. Код может быть слишком длинным, или делать слишком много. Если это так, я упрощаю его. Он может быть слишком запутанным. Если это так, я добавляю вспомогательные методы, для того чтобы сделать его более понятным.
Фактически, за три года совместного программирования на Java с участниками одной и той же команды я могу пересчитать количество написанных мной комментариев на пальцах моих рук и ног. Пишите понятный код! Если вам необходимо общее описание того, что делает система или какой-то конкретный ее компонент, напишите краткий документ для этого.
Многословные комментарии обычно тяжелее в обслуживании, не выражают ваших намерений так, как это делает маленький, хорошо написанный метод, и быстро становятся устаревшими. Не попадайте в зависимость от комментариев.
Используйте унифицированный стиль
Стиль кодирования на самом деле зависит от того, что необходимо и приемлемо в вашей среде. Я даже не знаю стиля, который мог бы назвать «типичным». Он часто зависит от личного вкуса. Например, вот некоторый фрагмент кода, который вызывает у меня судороги, пока я его не поменяю:
public void myMethod() < if (this.a == this.b) < statements >>
Почему он раздражает меня? Потому что я лично против стиля кодирования, при котором добавляются строки кода, по моему мнению, не нужные. Java-компилятор интерпретирует следующий код аналогично предыдущему, а я сохранил несколько строк:
public void myMethod()
Нет способа «правильного» или «неправильного». Один просто короче другого. Что же происходит, когда мне приходится кодировать вместе с тем, кто предпочитает первую форму? Мы говорим об этом, выбираем стиль кодирования, который собираемся придерживаться, затем фиксируем его. Единственным правилом на все случаи жизни является унификация.
Если кто-то из работающих над проектом использует другой стиль, чтение кода станет трудным. Выберите стиль и не меняйте его.
Избегайте использования операторов switch
Некоторые Java-программисты любят выражения switch . Я думал, что они хороши, но потом понял, что выражение switch на самом деле является просто набором выражений if ; это обычно означает, что условная логика появляется в моем коде более чем в одном месте. Это дублирование кода, что недопустимо. Почему? Потому что присутствие одинакового кода в нескольких местах затрудняет его изменение. Если у меня есть один и тот же switch в трех местах, и нужно изменить один вариант, я должен поменять три фрагмента кода.
Теперь, можете ли вы выполнить рефакторинг кода таким образом, чтобы имелось только одно выражение switch ? Отлично! Я не имею ничего против его использования. В некоторых ситуациях выражение switch более понятно, чем вложенные if . Но если вы видите, что оно появляется в нескольких местах — это проблема, которую вы должны решить. Простой способ предотвратить ее появление — избегать выражения switch до тех пор, пока оно не будет лучшим средством выполнения работы. Мой опыт говорит, что это случается редко.
Будьте открыты
Я оставил самые сомнительные рекомендации напоследок. Вдохните глубже.
Я верю, что не будет ошибкой сделать все ваши методы открытыми ( public ). Переменные экземпляра должны иметь спецификатор protected .
Естественно, многие профессиональные программисты содрогнуться от этой мысли, поскольку если все будет открытым, любой может изменить что-либо, возможно, несанкционированно. В мире, где все является открытым, вы должны зависеть от дисциплинированности программиста для гарантии того, чтобы люди не получили доступ к тому, к чему не должны иметь доступ, и тогда, когда не должны иметь доступ.
Но в жизни программиста мало найдется ситуаций более разочаровывающих, чем желание обратиться к переменной или методу, который ему не видим. Когда вы ограничиваете доступ к чему-нибудь в вашем коде, предполагая, что другие не должны его иметь, вы полагаете себя всеведущим. Чаще всего это опасное предположение.
Такого рода разочарование часто наступает при использовании чужого кода. Вы можете увидеть метод, делающий точно то, что вам нужно, но он не доступен. Иногда есть веские причины этого, поэтому имеет смысл ограничить доступность.
Однако иногда единственной причиной того, что метод не указан как public , является то, что парни, написавшие код, думали: «Никому и никогда даже не понадобиться обратиться к нему». А может они думали: «Никто не должен обратиться к нему, потому что…», вовсе не имея серьезной на это причины. Очень часто люди используют ключевое слово private только потому, что оно существует. Не поступайте так.
Указывайте методы как public , а переменные как protected , если не имеете серьезной причины для ограничения доступа.
По следам Фаулера (Fowler)
Теперь вы знаете, как создавать хороший Java-код и как поддерживать его хорошим.
Лучшей книгой по этой теме является «Рефакторинг» Мартина Фаулера (Martin Fowler). Ее даже читать легко. Рефакторинг означает изменение дизайна существующего кода без изменения его результатов. Фаулер говорит о «загрязнениях кода» («code smells»), которые требуют рефакторинга, и очень подробно рассматривает различные технические приемы для их исправления.
По моему мнению рефакторинг и способность писать код в стиле test-first (сначала тестирование) является самым важным умением, которое должны освоить начинающие программисты. Если бы каждый программист был хорош в обоих этих навыках, то это революционизировало бы отрасль. Если вы отлично освоите их, будет легче получить работу, поскольку вы будете способны достичь лучших результатов, чем большинство из ваших соратников.
Писать Java-код относительно не сложно. Писать хороший Java-код — это мастерство. Стремитесь стать мастером.
Источник: kvodo.ru