Advertisement
Guest User

Untitled

a guest
Feb 25th, 2020
118
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 55.06 KB | None | 0 0
  1. Изменение в регламенте Code Style для Java
  2.  
  3. Соглашения по оформлению кода Java (Java Code Conventions)
  4.  
  5. 1 Введение
  6.  
  7. 1.1 Зачем нужны условные обозначения кода
  8.  
  9. 2 Имена файлов
  10.  
  11. 2.1 Расширения файлов
  12. 2.2 Общие имена файлов
  13.  
  14. 3 Организация файлов
  15.  
  16. 3.1 Файлы с исходным кодом Java
  17. 3.1.1 Начальный комментарий
  18. 3.1.2 Операторы package и import
  19. 3.1.3 Объявления классов и интерфейсов
  20.  
  21. 4 Отступы
  22.  
  23. 4.1 Длинна строки
  24. 4.2 Перенос строки
  25.  
  26. 5 Комментарии
  27.  
  28. 5.1 Формат реализации комментариев
  29. 5.1.1 Блок комментариев
  30. 5.1.2 Однострочный комментарий
  31. 5.1.3 Прицепные комментарии
  32. 5.1.4 Комментарии в конце строки
  33. 5.2 Комментарии для документации
  34.  
  35. 6 Объявления
  36.  
  37. 6.1 Количество объявлений в строке
  38. 6.2 Размещение
  39. 6.3 Инициализация
  40. 6.4 Объявления классов и интерфейсов
  41.  
  42. 7 Операторы
  43.  
  44. 7.1 Простые операторы
  45. 7.2 Составные операторы
  46. 7.3 Оператор return
  47. 7.4 Операторы if, if-else, if-else-if-else
  48. 7.5 Оператор цикла for
  49. 7.6 Оператор цикла while
  50. 7.7 Оператор цикла do-while
  51. 7.8 Оператор switch
  52. 7.9 Оператор try-catch
  53.  
  54. 8 Пробелы
  55.  
  56. 8.1 Пустые строки
  57. 8.2 Расстановка пробелов
  58.  
  59. 9 Соглашение об именовании
  60.  
  61. 10 Практическое применение
  62.  
  63. 10.1 Обеспечение доступа к экземпляру и переменным класса
  64. 10.2 Обращение к переменным и методам класса
  65. 10.3 Константы
  66. 10.4 Примеры присваивания значение переменным и операторам и т.д.
  67. 10.5 Различные приёмы программирования
  68. 10.5.1 Круглые скобки
  69. 10.5.2 Возврат значения
  70. 10.5.3 Выражения перед '?' в условном операторе
  71. 10.5.4 Специальные комментарии
  72.  
  73. 11 Примеры кода
  74.  
  75. 11.1 Пример файла с исходным кодом Java
  76.  
  77.  
  78.  
  79. 1 - Введение
  80.  
  81. 1.1 Зачем нужны условные обозначения кода
  82.  
  83. Соглашения по оформлению кода важны для программистов по ряду причин:
  84.  
  85. • 80% от стоимости программного обеспечения приходится на его обслуживание.
  86. • Вряд ли какое-либо программное обеспечение все время поддерживается первоначальным разработчиком.
  87. • Соглашения по оформлению кода делают исходный код программ более удобочитаемым, позволяя инженерам более быстро и тщательно понимать новый код.
  88. • Если вы предоставляете исходный код как продукт, вы должны убедится, что он хорошо оформлен и упакован как любой другой продукт который вы создаете
  89.  
  90.  
  91.  
  92.  
  93. 2 - Имена файлов
  94.  
  95. В этом разделе перечислены наиболее часто используемые имена файлов и их расширения.
  96.  
  97.  
  98. 2.1 Расширения файлов
  99.  
  100. В программах написанных на Java используются следующие расширения файлов:
  101.  
  102. --------------------------------
  103. Тип файла | Расширение
  104. --------------------------------
  105. Для исходного кода | .java
  106. --------------------------------
  107. Для байт-кода | .class
  108. --------------------------------
  109.  
  110.  
  111. 2.2 Общие имена файлов
  112.  
  113. Часто используемые имена файлов включают:
  114.  
  115. Имя файла Применение
  116.  
  117. GNUmakefile Зарезервированное имя для создаваемых файлов. Мы используем gnumake для создания нашего программного обеспечения.
  118. README Зарезервированное имя файла в котором содержится информация о файлах находящихся в той же директории.
  119.  
  120.  
  121.  
  122. 3 - Организация файлов
  123.  
  124. Файл состоит из разделов, которые должны быть разделены пустыми строками и необязательным комментарием, идентифицирующим каждую секцию.
  125. Файлы длиной более 2000 строк являются громоздкими и их следует избегать.
  126. Пример форматирования файла с исходным кодом Java приведен в разделе "Пример файла с исходным кодом Java".
  127.  
  128.  
  129. 3.1 Файлы с исходным кодом Java
  130.  
  131. Каждый файл с исходным кодом Java содержит один Class с ключевым словом public или интерфейс. Когда классы с ключевым словом private и интерфейсы связанны с public классом, то их можно поместить в тот же файл с исходным кодом, что и public класс. Класс с ключевым словом public должен быть размещен как первый класс или интерфейс в файле.
  132.  
  133. Файлы с исходным кодом Java имеют следующий порядок:
  134.  
  135. • Начальный комментарий (смотрите "Начальный комментарий")
  136. • Операторы package и import, например:
  137.  
  138. import java.applet.Applet;
  139.  
  140. import java.awt.*; import java.net.*;
  141.  
  142. • Объявления классов и интерфейсов (смотрите "Объявления классов и интерфейсов")
  143.  
  144.  
  145. 3.1.1 Начальный комментарий
  146.  
  147. Все файлы с исходным кодом должны начинаться с комментария в стили языка C, в котором перечисленны авторы программы, дата, сведения об авторских правах, а так же кратко описание того, что делает программа. Для примера:
  148.  
  149. /*
  150. * Имя класса
  151. *
  152. * Информация о версии
  153. *
  154. * Информация об авторском праве
  155. */
  156.  
  157.  
  158. 3.1.2 Операторы Package и Import
  159.  
  160. Первая строка без комментария в файле с исходным кодом Java это оператор package. После нее следует оператор import. Для примера:
  161.  
  162. package java.awt;
  163.  
  164. import java.awt.peer.CanvasPeer;
  165.  
  166.  
  167. 3.1.3 Объявления классов и интерфейсов
  168.  
  169. В следующей таблице описаны части объявления класса или интерфейса в том порядке, в котором они должны отображаться. Образец с комментариями приведен в "Примере файла с исходным кодом Java"
  170.  
  171. -------------------------------------------------------------------------------------
  172. Часть объявления класса/интерфейса| Заметки
  173. -------------------------------------------------------------------------------------
  174. Комментарий для документации по | Смотрите в "Комментарии для документации" какая
  175. классам и интерфейсам (/**...*/) | информация должна содержатся в этом комментарии
  176. -------------------------------------------------------------------------------------
  177. Оператор class или interface |
  178. -------------------------------------------------------------------------------------
  179. Если необходимо, то указать | Здесь содержится любая дополнительная информация
  180. комментарий реализации | по классу или интерфейсу, которая не подходит для
  181. класса/интерфейса (/*...*/) | документирующего комментария.
  182. -------------------------------------------------------------------------------------
  183. (static) Переменные класса | Сначала переменные класса public, затем protected,
  184. | и только потом private
  185. -------------------------------------------------------------------------------------
  186. Переменные экземпляра | Сперва public, затем protected, и только потом
  187. | private.
  188. -------------------------------------------------------------------------------------
  189. Конструкторы |
  190. -------------------------------------------------------------------------------------
  191. Методы | Методы должны быть сгруппированными по
  192. | функциональности, а не по области или доступности.
  193. | Для примера метод класса private может находится
  194. | между двумя public методами экземпляра. Цель в
  195. | облегчении чтения и понимания кода.
  196. --------------------------------------------------------------------------------------
  197.  
  198.  
  199.  
  200.  
  201. 4 - Отступы
  202.  
  203. В качестве единицы отступов следует использовать клавишу Tab которая равна обычно 4-м пробелам. Точная конструкция отступа (пробелы или символы табуляции) не указана. Табуляция должна быть установлена ровно каждые 8 пробелов (а не 4).
  204.  
  205.  
  206. 4.1 Длинна строки
  207.  
  208. Избегайте строк длиннее 80 символов, так как они не обрабатываются многими терминалами и инструментами.
  209.  
  210. Примечание: Примеры для использования в документации должны иметь более короткую длину строки - обычно не более 70 символов.
  211.  
  212.  
  213. 4.2 Перенос строки
  214.  
  215. Если выражение не помещается на одной строке, разбейте его в соответствии с этими общими принципами:
  216.  
  217. • Перенос после запятой.
  218. • Перенос перед оператором.
  219. • Предпочитайте переносы более высокого уровня для переноса нижнего уровня (вложенном уровне).
  220. • Выравнивайте новую строку выражения так, чтобы его начало было на том же уровне как и в предыдущей строке.
  221. • Если приведенные выше правила приводят к запутанному (плохо читающемуся) коду или коду, который сжимается с правым краем, просто введите 2 таба вместо этого.
  222.  
  223. Несколько примеров переноса строки в вызовах методов:
  224.  
  225. function(longExpression1, longExpression2, longExpression3,
  226. longExpression4, longExpression5);
  227.  
  228. var = function1(longExpression1,
  229. function2(longExpression2,
  230. longExpression3));
  231.  
  232. Ниже приведены два примера переноса арифметического выражения. Первое предпочтительнее, так как разрыв происходит вне выражения в скобках, которое находится на более высоком уровне.
  233.  
  234. longName1 = longName2 * (longName3 + longName4 - longName5)
  235. + 4 * longname6; // ПРЕДПОЧТИТЕЛЬНЕЙ
  236.  
  237. longName1 = longName2 * (longName3 + longName4
  238. - longName5) + 4 * longname6; // ИЗБЕГАЙТЕ
  239.  
  240. Ниже приведены два примера объявления отступов. Первый - это обычный случай. Во втором случае следовало бы сдвинуть вторую и третью строки далеко вправо, если бы применялись обычные отступы. Вместо этого строки сдвинуты всего на 8 пробелов.
  241.  
  242. //ОБЫЧНЫЕ ОТСТУПЫ
  243. someMethod(int anArg, Object anotherArg, String yetAnotherArg,
  244. Object andStillAnother) {
  245. ...
  246. }
  247.  
  248. //ОТСТУП НА 8 СИМВОЛОВ, ЧТОБЫ ИЗБЕЖАТЬ ОЧЕНЬ ДЛИННЫХ ОТСТУПОВ
  249. private static synchronized horkingLongMethodName(int anArg,
  250. Object anotherArg, String yetAnotherArg,
  251. Object andStillAnother) {
  252. ...
  253. }
  254.  
  255. Отступы в строках с оператором if следует применить по правилу 2 таба, так как если использовать стандартный таб, то поиск тела оператора будет затруднителен. Например:
  256.  
  257. //НЕ ИСПОЛЬЗУЙТЕ ТАКИЕ ОТСТУПЫ
  258. if ((условие1 && условие2)
  259. || (условие3 && условие4)
  260. ||!(условие5 && условие6)) { //ПЛОХОЙ ПЕРЕНОС
  261. doSomethingAboutIt(); //СДЕЛАЕТ ЭТУ СРОКУ МЕНЕЕ ЗАМЕТНОЙ (ЛЕГКО ПРОПУСТИТЬ)
  262. }
  263.  
  264. //ИСПОЛЬЗУЙТЕ ТАКИЕ ОТСТУПЫ В ПОДОБНЫХ СЛУЧАЯХ
  265. if ((условие1 && условие2)
  266. || (условие3 && условие4)
  267. ||!(условие5 && условие6)) {
  268. doSomethingAboutIt();
  269. }
  270.  
  271. //ИЛИ ДЕЛАЙТЕ ТАК
  272. if ((условие1 && условие2) || (условие3 && условие4)
  273. ||!(условие5 && условие6)) {
  274. doSomethingAboutIt();
  275. }
  276.  
  277. Вот три приемлемых способа форматирования тернарных выражений:
  278.  
  279. alpha = (aLongBooleanExpression) ? beta : gamma;
  280.  
  281. alpha = (aLongBooleanExpression) ? beta
  282. : gamma;
  283.  
  284. alpha = (aLongBooleanExpression)
  285. ? beta
  286. : gamma;
  287.  
  288.  
  289.  
  290.  
  291. 5 - Комментарии
  292.  
  293. Программы написанные на языке Java могут иметь два вида комментариев: комментарий реализации и документирующий комментарий. Комментарии реализации - это те, которые применяются в языке C++, обозначаются /*...*/ и //. Документирующие комментарии (известные как "doc comments" или "Javadoc") есть только в Java, и обозначаются /** ... */. Документирующие комментарии могут извлекаться из кода в HTML файл, используя инструмент javadoc.
  294. Комментарии кода используются для описания отдельных строк/блоков кода или целого алгоритма. Комментарии для документирования используются, чтобы описать спецификацию кода (его интерфейс), не зависящую от его реализации. Комментарии для документирования делают для разработчиков, которые будут использовать ваши программы (библиотеки классов) не имея их исходного кода.
  295. Комментарии нужны, чтобы описать код или пояснить моменты, которые сложно понять непосредственно из кода. Комментарии должны содержать лишь ту информацию, которая необходима для чтения и понимания кода программы. Например информацию о том, как откомпилировать связанный пакет или в какой директории он находится не стоит описывать в комментарии.
  296. Обсуждение нетривиальных или неочевидные решений необходимо, но не нужно описывать то, что и так ясно из кода. Такие "избыточные" комментарии очень быстро могут стать неактуальными. В общем, следует избегать любых комментариев, которые могут стать неактуальными по мере развития кода.
  297.  
  298. Примечание: Частое использование комментариев иногда говорит о низком качество кода. Когда вы чувствуете необходимость добавить комментарий, попробуйте переписать код, чтобы он стал понятнее.
  299.  
  300. Комментарии не должны быть заключены в большие квадраты, помеченные звездочками или другими символами. Например:
  301.  
  302. /************************
  303. * Какой то комментарий *
  304. ************************/
  305.  
  306. Комментарии не должны содержать специальных символов, таких как символ конца страницы или backspace.
  307.  
  308.  
  309. 5.1 Формат реализации комментариев
  310.  
  311. В программах могут использоваться 4 вида комментариев: блочные, однострочные, прицепные и комментарии до конца строки.
  312.  
  313.  
  314. 5.1.1 Блок комментариев
  315.  
  316. Блочные комментарии используются для описания файлов, методов, структур данных и алгоритмов. Так же их следует использовать в начале каждого файла и перед каждым методом. Они также могут использоваться в других местах, например, внутри методов. Блочные комментарии внутри функции или метода должны иметь отступ на том же уровне, что и код, который они описывают.
  317. Перед блочным комментарием следует оставлять пустую строку, чтобы визуально отделить его от кода. Каждая строка блочного комментария (кроме первой) должна начинаться с символа "*".
  318.  
  319. /*
  320. * Это блок комментариев.
  321. */
  322.  
  323. Если блочный комментарий начинается с "/*-", это означает в данном блоке используется особое форматирование, которое нельзя потерять (Такой блок не будет переформатирован средствами авто-форматирования). Например:
  324.  
  325. /*
  326. * Этот блочный комментарий содержит очень специфичное
  327. * форматирование, которое должно игнорироваться средствами авто-форматирования
  328. *
  329. * один
  330. * два
  331. * три
  332. */
  333.  
  334. Примечание: Если вы не используете средства авто-форматирования, вам не обязательно использовать "/*-" в коде, но можете сделать это на случай того, что кто-то другой может запустить средства авто-форматирования на вашем коде.
  335. Смотрите подробней в "Комментарии для документации"
  336.  
  337.  
  338. 5.1.2 Однострочный комментарий
  339.  
  340. Однострочные комментарии (короткие комментарии) можно писать в одной строке используя отступ на уровне соответствующего блока кода, который он описывает. Если комментарий не помещается в одну строку, следует использовать блочный комментарий (смотрите "Блок комментариев"). Однострочному комментарию должна предшествовать пустая строка. Вот пример однострочного комментария в Java-коде (смотрите "Комментарии для документации"):
  341.  
  342. if (условие) {
  343.  
  344. /* Обработка условия. */
  345. ...
  346. }
  347.  
  348.  
  349. 5.1.3 Прицепные комментарии
  350.  
  351. Очень короткий комментарий можно расположить на той же строке, что и описываемый код. При этом его следует сдвинуть вправо настолько, чтобы он не сливался с кодом. Если в одном блоке кода присутствует более одного такого комментария, их начало должно быть на одном уровне.
  352. Старайтесь избегать комментирования каждой строчки кода подобным образом.
  353. Пример прицепных комментариев в Java коде (смотрите также "Комментарии для документирования"):
  354.  
  355. if (a == 2) {
  356. return TRUE; /* особый случай */
  357. } else {
  358. return isprime(a); /* работает только для нечетных a */
  359. }
  360.  
  361.  
  362. 5.1.4 Комментарии в конце строки
  363.  
  364. Символами // начинается комментарий, который продолжится до следующей строки (новой строки). Он может занимать всю строку или только ее часть. Его не следует использовать для многострочных комментариев, однако его можно использовать, чтобы закомментировать несколько строк кода. Рассмотрим пример всех трех вариантов его использования:
  365.  
  366. if (foo > 1) {
  367.  
  368. // Сделайте двойной щелчок.
  369. ...
  370. }
  371. else
  372. return false; // Объясните, почему здесь.
  373.  
  374. //if (bar > 1) {
  375. //
  376. // // Сделайте тройной щелчок.
  377. // ...
  378. //}
  379. //else
  380. // return false;
  381.  
  382.  
  383.  
  384. 5.2 Комментарии для документирования
  385.  
  386. Примечание: смотрите "Пример файла с исходным кодом Java" для примеров форматов комментариев, описанных здесь.
  387.  
  388. Для получения дополнительной информации смотрите "Как написать комментарии к документу для Javadoc", который включает в себя информацию о тегах комментариев документа (@return, @param, @see):
  389.  
  390. http://java.sun.com/products/jdk/javadoc/writingdoccomments.html
  391.  
  392. Для получения большей информации о документирующих комментариях и Javadoc, посетите домашнюю страницу Javadoc:
  393.  
  394. http://java.sun.com/products/jdk/javadoc/
  395.  
  396. Документирующие комментарии описывают Java классы, интерфейсы, конструкторы, методы и поля. Каждый комментарий помещается в ограничители /**...*/, один комментарий на один элемент API. Такой комментарий должен располагаться непосредственно перед объявлением:
  397.  
  398. /**
  399. * Класс Example предоставляет ...
  400. */
  401. class Example { ...
  402.  
  403. Обратите внимание, что классы и интерфейсы не имеют отступов, в отличии от их членов. Первая строка документирующего комментария (/**) для классов и интерфейсов не имеет отступов; каждая последующая строка документирующего комментария имеет 1 пробел (для вертикального выравнивания звездочек). Члены класса, включая конструкторы, имеют 4 пробела для первой строки документирующего комментария и 5 для остальных.
  404. Если необходимо предоставить информацию о классе, интерфейсе, переменной или методе, не принадлежащую к документации, используйте блочный (смотрите раздел 5.1.1) или однострочный (смотрите раздел 5.1.2) комментарий непосредственно после объявления. Например, детали о реализуемом классе должны идти в таком комментарии в блоке реализации, а не в документирующем комментарии.
  405. Документирующий комментарий не должен располагаться внутри блока реализации метода или конструктора, потому что Java связывает документирующий комментарий с первым после него объявлением.
  406.  
  407.  
  408.  
  409.  
  410. 6 - Объявления
  411.  
  412.  
  413. 6.1 Количество объявлений в строке
  414.  
  415. Рекомендуется использовать одно объявление на строку, так как это облегчает комментирование. Другими словами:
  416.  
  417. int level; // уровень отступа
  418. int size; // размер таблицы
  419.  
  420. предпочтительней нежели
  421.  
  422. int level, size;
  423.  
  424. Ни в коем случае нельзя объявлять переменные и функции в одной строке. Например:
  425.  
  426. long dbaddr, getDbaddr(); // НЕПРАВИЛЬНО!
  427.  
  428. Не помещайте переменные разных типов (имеется в виду не тип самих переменных, а тип данных которые в них хранятся) в одну строку. Например:
  429.  
  430. int foo, fooarray[]; /* НЕПРАВИЛЬНО! В одной строке нельзя располагать целочисленную переменную и массив данных! */
  431.  
  432. Примечание: В приведенных выше примерах используется один таб между типом и идентификатором. например:
  433.  
  434. int level; // уровень отступа
  435. int1 size; // размер таблицы
  436. Object currentEntry; // текущий выделенный экземпляр таблицы
  437.  
  438.  
  439. 6.2 Размещение
  440.  
  441. Размещайте объявления только в начале блоков. (Блоком является любой код, заключенный в фигурные скобки "{"" и "}".) Не ждите объявления переменных до их первого использования; Это может запутать неопытного программиста и затруднить переносимость кода в пределах области.
  442.  
  443. void MyMethod() {
  444. int int1; // Начало блока метода
  445.  
  446. if (условие) {
  447. int int2; // Начало блока оператора "if"
  448. ...
  449. }
  450. }
  451.  
  452. Единственным исключением из этого правила являются индексы циклов for, которые в Java могут быть объявлены в операторе for:
  453.  
  454. for (int i = 0; i < maxLoops; i++) { ...
  455.  
  456. Избегайте локальных объявлений, перекрывающих объявления более высокого уровня. Например, не объявляйте одну и ту же переменную перед блоком кода и во внутреннем блоке:
  457.  
  458. int count;
  459. ...
  460. func() {
  461. if (условие) {
  462. int count; // ИЗБЕГАЙТЕ!
  463. ...
  464. }
  465. ...
  466. }
  467.  
  468.  
  469. 6.3 Инициализация
  470.  
  471. Старайтесь инициализировать локальные переменные там, где вы их объявляете. Единственная причина не инициализировать переменную в месте её объявления — если её начальное значение зависит от некоторых предварительных вычислений.
  472.  
  473.  
  474. 6.4 Объявления классов и интерфейсов
  475.  
  476. При написании Java классов и интерфейсов необходимо соблюдать следующие правила форматирования:
  477.  
  478. • Не ставьте пробел между именем метода и скобкой "(" в нутри которой указывается список его параметров
  479. • Открывающая скобка "{" ставится в конце той же строки, где указан оператор объявления класса или интерфейса
  480. • Закрывающая скобка "}" ставится на отдельной строке с тем же отступом, что и у соответствующего ему открывающего оператора, кроме случаев, когда имеем пустой оператор, то "}" должна появиться сразу после "{"
  481.  
  482. class Sample extends Object {
  483. int ivar1;
  484. int ivar2;
  485.  
  486. Sample(int i, int j) {
  487. ivar1 = i;
  488. ivar2 = j;
  489. }
  490.  
  491. int emptyMethod() {}
  492.  
  493. ...
  494. }
  495.  
  496. • Между методами должна быть одна пустая строка
  497.  
  498.  
  499.  
  500.  
  501. 7 - Операторы
  502.  
  503.  
  504. 7.1 Простые операторы
  505.  
  506. Каждая строка должна содержать не более одного оператора. Например:
  507.  
  508. argv++; argc--; // ИЗБЕГАЙТЕ!
  509.  
  510. Не используйте запятую для группировки нескольких операторов, даже если это видно невооруженным глазом. Например:
  511.  
  512. if (err) {
  513. Format.print(System.out, "error"), exit(1); //ОЧЕНЬ НЕПРАВИЛЬНО!
  514. }
  515.  
  516.  
  517. 7.2 Составные операторы
  518.  
  519. Составные операторы - это операторы, содержащие списки операторов, заключенные в фигурные скобки "{ операторы }". Примеры приведены в следующих разделах.
  520.  
  521. • Вложенные операторы должны иметь отступ на один уровень больше, чем составной оператор.
  522. • Открывающая скобка должна быть в конце той строки, с которой начинается составной оператор; закрывающая скобка должна начинаться с новой строки и с отступом, соответствующим началу составного оператора.
  523. • Скобки используются во всех операторах, даже в одиночных, когда они входят в состав управляющей структуры, таких, как оператор if-else или for. Это необходимо, чтобы избежать ошибок в случае добавления новых операторов, когда забыли указать фигурные скобки (если фигурных скобок нет, то управляющая конструкция типа if будет выполнять только одну строку после нее до знака ";").
  524.  
  525.  
  526. 7.3 Оператор return
  527.  
  528. Оператор return, возвращающий значение, не должен использовать скобки, если только их использование не сделает возвращаемое значение более понятным. Например:
  529.  
  530. return;
  531.  
  532. return myDisk.size();
  533.  
  534. return (size ? size : defaultSize);
  535.  
  536.  
  537. 7.4 Операторы if, if-else, if-else-if-else
  538.  
  539. Группа операторов (как и единичное использование) if-else должны иметь следующий вид:
  540.  
  541. if (условие) {
  542. операторы;
  543. }
  544.  
  545. if (условие) {
  546. операторы;
  547. } else {
  548. операторы;
  549. }
  550.  
  551. if (условие) {
  552. операторы;
  553. } else if (условие) {
  554. операторы;
  555. } else if (условие) {
  556. операторы;
  557. }
  558.  
  559. Примечание: операторы if всегда должны использоваться с фигурными скобками "{ }". Избегайте следующей формы:
  560.  
  561. if (условие) //ИЗБЕГАЙТЕ! ЗДЕСЬ УПУЩЕНЫ ФИГУРНЫЕ СКОБКИ {}!
  562. оператор;
  563.  
  564.  
  565. 7.5 Оператор цикла for
  566.  
  567. Оператор цикла for должен иметь следующий вид:
  568.  
  569. for (инициализация; условие; итерация) {
  570. операторы;
  571. }
  572.  
  573. Пустой оператор цикла for (тот, в котором вся работа выполняется в инициализации, условии и итерации) должн иметь следующий вид:
  574.  
  575. for (инициализация; условие; итерация);
  576.  
  577. При использовании оператора запятой в блоке инициализации или итерации оператора цикла for избегайте использования более чем трех переменных. Если необходимо, используйте отдельные операторы перед циклом for (для случая блока инициализации) или в конце цикла (для случая блока итерации).
  578.  
  579. 7.6 Оператор цикла while
  580.  
  581. Оператор цикла while должен иметь следующий вид:
  582.  
  583. while (условие) {
  584. операторы;
  585. }
  586.  
  587. Пустой оператор цикла while должен иметь следующий вид:
  588.  
  589. while (условие);
  590.  
  591.  
  592. 7.7 Оператор цикла do-while
  593.  
  594. Оператор цикла do-while должен иметь следующий вид:
  595.  
  596. do {
  597. операторы;
  598. } while (условие);
  599.  
  600.  
  601. 7.8 Оператор switch
  602.  
  603. Оператор switch должен иметь следующую форму:
  604.  
  605. switch (условие) {
  606. case ABC:
  607. операторы;
  608. /* провал */
  609. case DEF:
  610. операторы;
  611. break;
  612.  
  613. case XYZ:
  614. операторы;
  615. break;
  616.  
  617. default:
  618. операторы;
  619. break;
  620. }
  621.  
  622. Каждый раз, когда выбор проваливается (не включая оператор break), добавьте комментарий, где обычно находится оператор break. Это показано в предыдущем примере кода с комментарием /* провал */.
  623. Каждый оператор switch должен включать выбор по умолчанию (default). Оператор break в выборе по умолчанию лишний, но он предотвращает возникновение ошибки, если позже еще ​​один выбор добавится.
  624.  
  625.  
  626. 7.9 Оператор try-catch
  627.  
  628. Оператор try-catch должн иметь следующий формат:
  629.  
  630. try {
  631. операторы;
  632. } catch (ExceptionClass e) {
  633. операторы;
  634. }
  635.  
  636.  
  637.  
  638.  
  639. 8 - Пробелы
  640.  
  641.  
  642. 8.1 Пустые строки
  643.  
  644. Пустые строки улучшают читабельность, выделяя разделы кода, которые логически связаны между собой.
  645. Две пустые строки всегда должны использоваться в следующих случаях:
  646.  
  647. • Между секциями в файле исходного кода
  648. • Между определениями классов и интерфейсов
  649.  
  650. Одна пустая строка всегда должна использоваться в следующих случаях:
  651.  
  652. • Между методами
  653. • Между локальными переменными метода и его первым оператором
  654. • Перед блочным (смотрите раздел 5.1.1) или однострочным (смотрите раздел 5.1.2) комментарием
  655. • Между логическими участками кода внутри метода для улучшения читабельности
  656.  
  657.  
  658. 8.2 Расстановка пробелов
  659.  
  660. Разделяющие пробелы должны ставиться при следующих обстоятельствах:
  661.  
  662. • Ключевое слово, за которым следует скобка, должны быть разделены пробелом. Например:
  663.  
  664. while (true) {
  665. ...
  666. }
  667.  
  668. Обратите внимание, что пробел не должен использоваться между именем метода и его открывающей скобкой. Это помогает отличать ключевые слова от вызовов метода.
  669.  
  670. • Разделяющий пробел должен появляться после запятой в списке аргументов.
  671. • Все бинарные операторы кроме "." должны быть отделены от своих операндов пробелами. Пробелом никогда не должены разделятся оеранды и их унарные операторы, такие как унарный минус, инкремент ("++") и декремент ("--"). Например:
  672.  
  673. a += c + d;
  674. a = (a + b) / (c * d);
  675.  
  676. while (d++ = s++) {
  677. n++;
  678. }
  679. prints("size is " + foo + "\n");
  680.  
  681. • Выражения в операторе цикла for должны быть разделены пробелами. Например:
  682.  
  683. for (expr1; expr2; expr3)
  684.  
  685. • За приведением типа должен следовать пробел. Например:
  686.  
  687. myMethod((byte) aNum, (Object) x);
  688. myFunc((int) (cp + 5), ((int) (i + 3))
  689. + 1);
  690.  
  691.  
  692.  
  693.  
  694. 9 - Соглашение об именовании
  695.  
  696. Соглашение об именовании делает программы более понятными, облегчая их чтение. Они также могут дать информацию о функции идентификатора - например, является ли он константой, пакетом или классом, это облегчает понимания и чтение кода.
  697. Правила, приведенные в данном разделе, являются основополагающими. Более конкретные правила приведены в таблице:
  698.  
  699. ----------------------------------------------------------------------------------------------------
  700. Тип идентификатора | Правила для именования | Примеры
  701. ----------------------------------------------------------------------------------------------------
  702. Классы | Имена классов должны быть существительными, | class Raster;
  703. | набранным в смешанном регистре (каждое слово | class ImageSprite;
  704. | с большой буквы с большой буквы). |
  705. | Постарайтесь, чтобы ваши имена классов были |
  706. | простыми и наглядными. Используйте |
  707. | целые слова - избегайте сокращений и аббревиатур |
  708. | (если только аббревиатура делает имя класса более |
  709. | наглядным и понятным, чем длинная форма, например |
  710. | такие как URL или HTML). |
  711. ----------------------------------------------------------------------------------------------------
  712. Интерфейсы | Имена интерфейсов должны так же как имена классов | interface RasterDelegate;
  713. | начинаться с заглавных букв и именоваться | interface Storing;
  714. | согласно тех же правил. |
  715. ----------------------------------------------------------------------------------------------------
  716. Методы | Методы должны быть глаголами, набранными в | run();
  717. | смешанном регистре, первая буква первого слова в | runFast();
  718. | нижнем регистре, у всех последующих слов первая | getBackground();
  719. | буква в верхнем регистре. |
  720. -----------------------------------------------------------------------------------------------------
  721. Переменные | За исключением переменных, все экземпляры классов | int i;
  722. | и констант классов набираются в смешанном | char *cp;
  723. | регистре с первым символом в нижнем регистре. | float myWidth;
  724. | Последующие слова набираются с большой буквы. |
  725. | Имена переменных должны быть короткими, |
  726. | но имеющими смысл. Выбранное имя переменной |
  727. | должно быть запоминающееся - то есть кратко |
  728. | описывающим то, что в ней содержится. |
  729. | Односимвольных имен переменных следует избегать, |
  730. | за исключением временных "одноразовых" переменных.|
  731. | Общепринятыми именами для временных переменных |
  732. | являются i, j, k, m и n для целых чисел; c, d и e |
  733. | для символов |
  734. ------------------------------------------------------------------------------------------------------
  735. Константы | Имена переменных объявленные константами класса, | int MIN_WIDTH = 4;
  736. | и ANSI константы должны быть набраны в верхнем | int MAX_WIDTH = 999;
  737. | регистре (заглавными буквами) с разделяемые | int GET_THE_CPU = 1;
  738. | знаком подчеркивания "_" между словами. |
  739. | (ANSI констант следует избегать для более |
  740. | легкой отладки.) |
  741. ------------------------------------------------------------------------------------------------------
  742.  
  743.  
  744.  
  745.  
  746. 10 - Практическое применение
  747.  
  748.  
  749. 10.1 Обеспечение доступа к экземпляру и переменным класса
  750.  
  751. Не делайте какие-либо переменные экземпляра или класса общедоступными без уважительной причины. Часто встречаются случаи, когда поля класса не должны устанавливаться или считываться напрямую - их чтение и запись должны происходить лишь при вызове методов.
  752. Одним из примеров уместного использования public полей может быть случай, когда класс описывает лишь структуру данных, без какого-либо поведения. Другими словами, если бы вы могли использовать struct вместо class (если бы Java поддерживал struct), тогда можно сделать переменные экземпляра класса public.
  753.  
  754.  
  755. 10.2 Обращение к переменным и методам класса
  756.  
  757. Избегайте использование объекта для доступа к статическим полям и методам класса. Вместо этого используйте имя класса. Например:
  758.  
  759. classMethod(); //OK
  760. AClass.classMethod(); //OK
  761.  
  762. anObject.classMethod(); //ИЗБЕГАЙТЕ!
  763.  
  764.  
  765. 10.3 Константы
  766.  
  767. Численные константы (литералы) не должны кодироваться напрямую, за исключением -1, 0 и 1, которые могут использоваться в циклах для управления счетчиком.
  768.  
  769.  
  770. 10.4 Примеры присваивания значение переменным и операторам и т.д.
  771.  
  772. Избегайте присваивания значения некоторым переменным в одном выражении. Это усложняет чтение. Например:
  773.  
  774. fooBar.fChar = barFoo.lchar = 'c'; //ИЗБЕГАЙТЕ!
  775.  
  776. Не используйте оператор присваивания в местах, где он может быть легко спутан с оператором сравнения. Например:
  777.  
  778. if (c++ = d++) { //ИЗБЕГАЙТЕ! В Java запрещено
  779. ...
  780. }
  781.  
  782. лучше написать так:
  783.  
  784. if ((c++ = d++) != 0) {
  785. ...
  786. }
  787.  
  788. Не используйте вложенные присваивания, пытаясь ускорить скорость выполнения программы. Это работа компилятора, и, кроме того, на самом деле редко помогает. Например:
  789.  
  790. d = (a = b + c) + r; //НЕПРАВИЛЬНО!
  791.  
  792. должно быть написано так:
  793.  
  794. a = b + c;
  795. d = a + r;
  796.  
  797.  
  798. 10.5 Различные приёмы программирования
  799.  
  800.  
  801. 10.5.1 Круглые скобки
  802.  
  803. Как правило, хорошей практикой является использование круглые скобки в выражениях содержащих различные операторы, чтобы избегать проблем с приоритетом операторов. Даже если приоритет оператора вам кажется очевидным, то для других это может быть не так - вы не должны предполагать, что другие программисты знают приоритет, как и вы.
  804.  
  805. if (a == b && c == d) // ИЗБЕГАЙТЕ!
  806.  
  807. if ((a == b) && (c == d)) // ПРАВИЛЬНЕЙ ЗАПИАТЬ ТАК
  808.  
  809.  
  810. 10.5.2 Возврат значения
  811.  
  812. Попробуйте сделать структуру вашей программы понятной. Например:
  813.  
  814. if (booleanExpression) {
  815. return TRUE;
  816. } else {
  817. return FALSE;
  818. }
  819.  
  820. вместо этого следует записать так:
  821.  
  822. return booleanExpression;
  823.  
  824. аналогичным образом:
  825.  
  826. if (условие) {
  827. return x;
  828. }
  829. return y;
  830.  
  831. лучше записать так:
  832.  
  833. return (условие ? x : y);
  834.  
  835.  
  836. 10.5.3 Выражения перед '?' в условном операторе
  837.  
  838. Если выражение содержит бинарный оператор, находящийся перед тернарным оператором ?:, он должен быть заключен в скобки. Например:
  839.  
  840. (x >= 0) ? x : -x
  841.  
  842. 10.5.4 Специальные комментарии
  843.  
  844. Используйте XXX в комментарии для того, чтобы показать, что этот код неправильный, но работает. Используйте FIXME для того, чтобы показать, что код неправильный и не работает.
  845.  
  846.  
  847.  
  848.  
  849. 11 - Примеры кода
  850.  
  851.  
  852. 11.1 Пример файла с исходным кодом Java
  853.  
  854. Следующий пример показывает как форматировать файл с исходным кодом Java, содержащим отдельный класс. Интерфейсы форматируются отдельно. Для более подробного изучения прочтите "Объявление классов и интерфейсов" и "Документирующие комментарии".
  855.  
  856. /*
  857. * %W% %E% Имя Фамилия
  858. *
  859. * Копирайт (c) 1993-1996 Sun Microsystems, Inc. Все права защищены.
  860. *
  861. * Это программное обеспечение является конфиденциальной и закрытой информацией Sun
  862. * Microsystems, Inc. («Конфиденциальная информация»). Вы не должны
  863. * раскрывать такую Конфиденциальную информацию и использовать ее только в
  864. * соответствии с условиями лицензионного соглашения, в которых вы состоите
  865. * с Sun.
  866. *
  867. * SUN НЕ ДАЁТ НИКАКИХ ГАРАНТИЙ, ЯВНЫХ ИЛИ КОСВЕННЫХ (ВКЛЮЧАЯ - НО НЕ
  868. * ОГРАНИЧИВАЯСЬ ИМИ - ГАРАНТИИ РЕАЛИЗУЕМОСТИ), СООТВЕТСТВИЯ ОПРЕДЕЛЁННОМУ
  869. * НАЗНАЧЕНИЮ ИЛИ НЕНАРУШЕНИЯ УСЛОВИЙ, ЧТО СОДЕРЖИМОЕ ДАННОЙ СПЕЦИФИКАЦИИ
  870. * ПОДХОДИТ ДЛЯ КАКИХ-ЛИБО ЦЕЛЕЙ ИЛИ ЧТО ЛЮБОЕ ИСПОЛЬЗОВАНИЕ ИЛИ РЕАЛИЗАЦИЯ
  871. * ТАКОГО СОДЕРЖИМОГО НЕ БУДЕТ НАРУШАТЬ КАКИХ-ЛИБО ПАТЕНТОВ ТРЕТЬЕЙ СТОРОНЫ,
  872. * АВТОРСКИХ ПРАВ, КОММЕРЧЕСКОЙ ТАЙНЫ ИЛИ ИНЫХ ПРАВ.
  873. */
  874. package java.blah;
  875.  
  876. import java.blah.blahdy.BlahBlah;
  877.  
  878. /**
  879. * Описание класса здесь.
  880. *
  881. * @version 1.10 04 Oct 1996
  882. * @author Имя Фамилия
  883. */
  884. public class Blah extends SomeClass {
  885. /* Здесь может идти комментарий реализации класса. */
  886.  
  887. /** Комментарий, документирующий classVar1 */
  888. public static int classVar1;
  889.  
  890. /**
  891. * Документирующий комментарий к classVar2, который бывает
  892. * более чем одна строка
  893. */
  894. private static Object classVar2;
  895.  
  896. /** комментарий, документирующий поле instanceVar1*/
  897. public Object instanceVar1;
  898.  
  899. /** комментарий, документирующий поле instanceVar2 */
  900. protected int instanceVar2;
  901.  
  902. /** комментарий, документирующий поле instanceVar3 */
  903. private Object[] instanceVar3;
  904.  
  905. /**
  906. * ...комментарий, документирующий метод Blah...
  907. */
  908. public Blah() {
  909. //...здесь идет реализация...
  910. }
  911.  
  912. /**
  913. * ...комментарий, документирующий метод doSomething...
  914. */
  915. public void doSomething() {
  916. //...здесь идет реализация...
  917. }
  918.  
  919. /**
  920. * ...комментарий, документирующий метод doSomethingElse...
  921. * @param someParam описание
  922. */
  923. public void doSomethingElse(Object someParam) {
  924. // ...здесь идет реализация...
  925. }
  926. }
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement