В тази статия ще видим какви са стандартите за кодиране в java и защо спазването им се счита за добра практика.

Програмирането е начин за комуникиране с компютри, като им давате инструкции, за да изпълните определена задача. По този начин нашият акт на писане на кодове е форма на комуникация не само с машини, но и с други разработчици.

Думата комуникация се определя като обмен на информация между две или повече лица. Този обмен може да се случи по четири начина: вербален, невербален, писмен и визуален. Всяка форма има своите конвенции и методи, за да направи споделянето на информация ефективно. Например, помислете за писмена комуникация. Освен че имаме конкретен синтаксис на даден език, имаме и определени конвенции, които помагат на читателите да възприемат информацията лесно, като редове между абзаци, удебелени и курсив думи и др. Без следвайки тези стилове, тази статия ще изглежда както е показано по-долу.

Coding Standards in Java
Programming is a way to communicate with computers by giving instructions to them in order to perform a particular task. Thus our act of writing codes is a form of communication not only with machines but also with other developers.
The word communication is defined as an exchange of information between two or more persons. This exchange can happen in four ways: verbal, nonverbal, written, and visual. Each form has its conventions and methods to make the sharing of information effective. For example, consider written communication. Apart from having a particular syntax of a language, we also have certain conventions that help readers to grasp information easily. Without following those styles, this article will look as shown below.

Информацията все още е налице, но не по ефективен начин, за да се чете лесно. Тъй като кодирането също е форма на писмена комуникация, добра практика е да следвате определени стандарти, които ще ги направят лесни за разбиране от други разработчици.

През повечето време ние не само пишем код само за да бъде разбран от машината, но и за да бъде разбран от други разработчици, тъй като може да се наложи да прочетат кода и да го променят, да коригират грешки или да добавят повече функции.

Ползи от спазването на стандартите

  • Съответствие с индустриалните стандарти.
  • Повечето софтуери не се поддържат от оригиналния автор през целия му живот. По този начин коригирането на грешки и добавянето на нови функции става лесно и спестява време за всеки друг разработчик.
  • Постоянно качество и структура на кода - без значение кой пише кода.
  • Когато изпращаме нашия изходен код като продукт, трябва да се уверим, че той е толкова добре опакован и чист, колкото всеки друг продукт, който създаваме. Следните стандарти гарантират това.

Защо разработчиците не го правят

Въпреки че всичко това „следване на стандартите“ има смисъл, има много разработчици, които просто не могат да ги следват. Нека да разгледаме някои от тези пречки:

  • Липса на база от знания: Това се отнася за начинаещи или младши разработчици, които нямат много опит в писането на чисти кодове.
  • Липса на мотивация: Това се отнася за няколко разработчици, които не получават много, за да вършат добра работа. Липсва им работна етика.
  • Липса на време: Когато разработчиците са изправени пред кратки срокове, те могат да изберат да се съсредоточат първо върху решаването на задачата и след това върху писането на чисти кодове.

Писането на лоши кодове може да бъде по-бързо в краткосрочен план, но когато сме отделили време и усилия в дизайна на нашия код, добавянето на нови функции, коригирането на грешки и сътрудничеството с други разработчици става много по-лесно.

Стандарти за кодиране на Java

Нека се потопим в някои от важните стандарти, които се следват в индустрията. Това не са строги правила, а насока, към която трябва да се придържате като добра програмна практика, която ще улесни живота ви, както и на тези, които четат вашия код.

1. Конвенции за именуване

  • Имената на пакетите се въвеждат с малки букви, напр. javax.sql, com.newpackage, java.lang. Някои непредпочитани са напр. com.newPackage, com.new_package.
  • Имената на клас, енум, интерфейс и анотация се въвеждат с главни главни букви, напр. Thread, Runnable, Person.
  • Константите са типове с главни букви, разделени с долна черта, напр. SIZE, MIN_VALUE, MAX_VALUE.
  • Имената на методи са глаголи и се въвеждат с малки букви CamelCase, напр. deleteCharAt(), add(), isNull().
  • Променливите се въвеждат с малки букви CamelCase, напр. employeeName, birthDate, email. Името трябва да е кратко и такова, че да казва на читателя на програмата какво съхранява тази променлива.
Avoid                         |      Preferred
--------------------------------------------------------------------
int personIdentificationNumber; --> int personId;
Map<Integer,String> personMap; -->  Map<Integer,String> personsById;
String s;                      -->  String value;
  • Съкращенията не трябва да се използват, доколкото е възможно, но ако се използват, трябва да бъдат документирани.

2. Декларации

  • Препоръчва се една декларация на ред, тъй като насърчава коментирането и подобрява яснотата на кода.
int studentId,totalMarks;    // Avoid
// Preferred
int studentId;
int totalMarks;
d = (c = a + b) + e;    // Avoid
// Preferred
c = a + b;
d = c + e;
// Avoid
argv++; argc--;
  • Променливите статични/клас трябва да бъдат поставени в последователността: Първи публични променливи на клас, защитени, пакет/по подразбиранениво, т.е. без модификатор за достъп и след това частно.
  • След това трябва да се декларират конструктори на класове, последвани от вътрешни класове, ако е приложимо.
  • Трябва да се избягват локални декларации, които скриват декларации на по-високи нива. Например трябва да се избягва същото име на променлива във вътрешен блок като на глобалната променлива.
  • Декларациите за локални променливи трябва да са само в началото на блоковете.
  • Числените константи не трябва да се кодират директно.
// Avoid
String name = personsById.get(2906);
// Preferred
final int PERSON_ID = 2906;
String name = personsById.get(PERSON_ID);

3. Организация на изходния файл

  • Всеки изходен файл на Java трябва да съдържа един клас или интерфейс. Всеки клас трябва да бъде поставен в отделен файл.
  • Дължината на изходния файл трябва да е по-малка от 2,000 lines код.
  • Максималният брой параметри във всеки клас се предпочита да бъде 12.
  • Линиите извън екрана трябва да се избягват. Когато израз не се побира на един ред (повече от 70 до 120 знака), той трябва да бъде прекъснат след запетая или оператор .
count = number.calculate(bytes, offset, length,  
               value, 0, estimatedCount);
long value = ((totalValue < plannedValue ) ?  
                         totalValue : plannedValue );
  • Трябва да се използват празни редове за подобряване на четливостта чрез групиране на секции от код, които са логически свързани.
  • За предпочитане е всички изходни файлове да имат коментар към документацията, който може да съдържа информация като заглавие, версия, дата, автор и т.н. Това е последвано от package декларация, последвана от class коментар
package com.somepackage;
/**
 * what this file is about
 * 
 * @author a,b 
 * @date 
 * @version 
 * @copyright
 * 
 */
import com.somepackage.OtherClass;
/*
 * Optional class comment
 *
 */
public class SomeClass {
  // codes
}
  • Функциите обикновено трябва да са кратки, между 5–15 реда, но това не е абсолютно правило. Възможно е да има случаи, когато дадена функция е единичен голям оператор за превключване или понякога наличието на по-голяма функция може да е изгодно. Но когато е приложимо, опитайте се да се придържате към малки размери на функциите.
  • Началната скоба ({ ) трябва да е в края на същия ред като израза или метода на декларацията, а крайната скоба (} ) трябва да е на отделен ред и да е подравнена с условния/класа.
// Preferred
public class SomeClass {
  // codes
}
// Avoid
public class SomeClass
{
  // codes
}
  • Всички двоични оператори с изключение на „.“ трябва да бъдат разделени от операндите с интервал. Например int value = a + b + 1; се предпочита предint value=a+b+1;

4. Кодове за коментиране

Има два вида коментари, които са описани по-долу. Използвайте ги, когато е приложимо, тъй като това помага на човека, който се опитва да разбере какво е предназначен да прави сложен блок от код, метод или клас. Коментарите също ви помагат да избягвате ситуации, както е показано по-долу.

  • Коментари към документацията: Тези коментари описват спецификацията на кода от гледна точка без внедряване. Това е написано в HTML и трябва да предхожда декларация на клас, поле, конструктор или метод. Състои се от две части — описание, последвано от блокови тагове. След това можем да използваме Javadoc (инструмент, който идва с JDK), за да генерираме документация на Java код в HTML формат от изходния код на Java. Трябва да бъде написан в специфичен формат (вижте тази връзка).
  • Коментари за внедряване: Тези коментари описват конкретно изпълнение на кода. Освен това те са разделени на четири вида.
  1. Блокиране на коментар:използва се за предоставяне на описания на файлове, методи, структури от данни и алгоритми. Блоковите коментари трябва да се използват в началото на всеки файл и на местата, където кодът трябва да бъде обяснен. Трябва да се предхожда от празен ред, за да се отдели от останалата част от кода. Това също се нарича многоредов коментар.
/*
   Draws two lines which divides the window 
   into four quadrants. First draws a horizontal
   line and then the vertical line 
*/
line(0, 50, 100, 50);
line(50, 0, 50, 100);

2. Коментар на един ред:Кратките коментари могат да се показват на един ред. Това позволява добавянето на обяснителен текст към кода.

// single-line comment
if(x < y) {
    x = y % x;
}
/* also a single-line comment */
if(x < y) {
    x = y % x;
}

3.Завършващи коментари: Те се използват за обяснение на един ред код.

System.out.println(pi \u002A 4); // \u002A is Unicode of *

4.Коментар в края на ред: Разделителят за коментар // може да коментира цял ред или само частичен ред. Не трябва да се използва на няколко последователни реда за текстови коментари; въпреки това може да се използва в последователни няколко реда за коментиране на части от кода.

//if (bar > 1) {
//
//    // Do a something
//    ...
//}
//else {
//    return false;
//}

Важно е да степрофесионалистикогато пишете коментари. Помислете за следния коментар от един от отговорите на StackOverflow. Може да не е професионално, но определено е приятелско!

// 
// Dear maintainer: 
// 
// Once you are done trying to 'optimize' this routine, 
// and have realized what a terrible mistake that was, 
// please increment the following counter as a warning 
// to the next guy: 
// 
// total_hours_wasted_here = 42 
//

5. Разни

  • Не трябва да документираме overrided метод, освен ако изпълнението не е променено.
  • Не пропускайте фигурни скоби {} в условни изрази. Обвийте логически подобни условия и използвайте подходящи отстъпи, където е приложимо, така че всички твърдения да са лесни за четене.
// Avoid
if (condition) 
  statement;
// Avoid 
if (x < 0) function(x);
// Preferred
if (condition) {
   statement;
}
// Preferred
if ((a == b) && (c == d)) {
    ...
}
  • В случаите switch винаги има случай default дори без код. Всеки път, когато случай отпадне (не включва израз break), добавете коментар /* falls through */ там, където обикновено би бил операторът break.
switch (condition) {
case ABC:
    statements;
    /* falls through */
case DEF:
    statements;
    break;
case XYZ:
    statements;
    break;
default:
    statements;
    break;
}
  • Изявление return със стойност не трябва да използва скоби, освен ако те не правят върнатата стойност по-очевидна по някакъв начин.
  • Съобщенията трябва да са с правилен отстъп и организирани така, че да са лесни за четене.
// Preferred
throw new CustomException("Failed to retrieve"
    + " request " + request.getId()
    + " for user " + user.getId()
    + " query: '" + query.getText() + "'");

Това са някои от често използваните Java стандарти. Можете да прочетете повече за тях в стандартната документация (oracle, google). Разгледайте този правилно форматиран пример на Java код, за да видите тези конвенции на практика.

Умишлено замърсяване на кодовете

Изходният код на Java обикновено се компилира в байт код на Java — наборът от инструкции на виртуалната машина на Java. Компилираният байт код на Java може лесно да бъде обратно проектиран обратно в изходния код чрез свободно достъпни декомпилатори.

Следователно се извършва процес, наречен Обфускация на кода, който модифицира изпълнимия файл, така че той вече да не е полезен за хакер, но да остане напълно функционален. Методи като преименуване, криптиране на низове, вмъкване на фиктивен код и т.н. се използват за постигане на обфускация. Списък с инструменти с отворен код за извършване на обфускация в java можете да намерите на тази връзка.

Но не забравяйте, че това се прави на Java байт код, а не на изходния код. Не можем да използваме сигурността като извинение да не пишем чисти кодове!

Заключение

В днешно време много IDE като IntelliJ или Eclipse вече предоставят опции за форматиране на код, чрез които могат да се следват повечето от конвенциите за кодиране. Все още трябва да добавим коментари, тъй като те все още не са достатъчно умни, за да направят това за нас! Както и да е, изводът е, че трябва да пишем код по такъв начин, че да улеснява живота на бъдещите автори и поддържащи.

Ако сте намерили тази статия за полезна, проверете другата ми статия относно обектно-ориентираното програмиране в Java.