[prog.flame] Попрограммировал на Java, делюсь впечатлениями. Часть VI. Форматирование кода и Javadoc.

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

Часть I
Часть II
Часть III
Часть IV
Часть V

Никогда больше я не слышал таких жарких споров вокруг соглашений о форматировании кода, чем у Java-программистов. Люди с пеной у рта спорят не только о том, стоит ли использовать какие-нибудь префиксы/суффиксы для полей класса, и даже не о том, стоит ли открывающую фигурную скобку переносить на новую строку. Спорят о том, сколько пробелов должно быть в табуляции и на сколько пробелов нужно делать отступ при: a) переносе длинного выражения, b) переносе параметров при вызове метода, c) при декларировании методов с большим количеством параметров и т.д.

Самое смешное, что все эти горячие споры действительно имеют смысл. Поскольку IDE настолько умные, что могут переформатировать код по своему разумению. И если ты в свою IDE загружаешь чужой код и случайно его переформатируешь, то чужой исходник оказывается полностью перекроенным. Что затем скажется на мержинге изменений из разных веток от разных программистов.

Все это, наверное, преследует благую цель – сделать код одного разработчика “родным” по оформлению для всех остальных разработчиков. Но это с одной стороны. А с другой стороны – это пример постепенного превращения программистов в одинаковых и взаимозаменяемых винтиков. Ваша индивидуальность никому не нужна. Если вам удобно писать код как-то так:

class Demo    {    public void    doSomeAction(          ActionContext ctx,          ActionParams actionParams,          Logger logger)       throws IllegalArgumentException       {          WorkingContext workingCtx = makeWorkingContext                ( ctx.getCurrentUser().getFullContextParams()                , logger );          doActionInsideWorkingContext                ( wokingCtx                , actionParams );       }    }

то это никого не волнует. Не соответствуют ваши предпочтения рекомендованным Sun-ом соглашениям – идете в сад и засуньте свои фантазии сами найдете куда.

Когда-то слышал такое высказывание – человек наиболее остро ощущает свою несвободу не тогда, когда у него забирают что-то большое, а когда его ограничивают в мелочах. Например, запрети обычному человеку выезжать за границу – он будет вспоминать о своей несвободе редко. А вот заставь его спрашивать разрешение каждый раз, когда он захочет выйти из дому (даже если ему будут разрешать это в 99.9% случаев) – вот тут он будет постоянно чувствовать, что свободы у него немного.

Так же и в Java – нет у меня права расставлять пробелы и переносы так, как я привык. И это сильно напрягает.

До маразма можно дойти в любом языке и я слышал о C++ных проектах, в которых были просто-напросто драконовские Gode Style Guide – чуть ли не на 250-300 страниц. Но как раз дело в том, что в C/C++ – это эпизодические явления. Тогда как в Java, благодаря как IDE, так и самой ориентации на взаимозаменяемость программистов, ситуация доведена до крайности.

Ну и напоследок о штуке, которая меня всегда в Java раздражала. Это правила документирования параметров метода в Javadoc. В Java все параметры должны быть описаны в комментарии, предшествующем методу:

class Demo    {    /**     * Демонстрационный метод, который типа делает что-то.     *     * Данный комментарий должен продемонстрировать правила офомления     * документации для параметров методов в Javadoc.     *     * @param ctx Контекст, на котором воображаемая операция     *            должна выполняться.     * @param actionParams Параметры воображаемой операции.     * @param logger Интерфейс для журнализации выполняемых действий.     */    public void    doSomeAction(          ActionContext ctx,          ActionParams actionParams,          Logger logger)       throws IllegalArgumentException       {

Мне не нравится то, что список параметров дублируется – он есть и в Javadoc комментарии, и в декларации метода. Нафига? Мне не понятно.

В свое время, когда я выбирал средство для документирования C++ кода, я специально остановился на Doxygen, поскольку он позволял писать комментарий к параметру метода прямо перед декларацией этого параметра:

class Demo    {    /**     * Демонстрационный метод, который типа делает что-то.     *     * Данный комментарий должен продемонстрировать правила офомления     * документации для параметров методов в Doxygen.     */    public void    doSomeAction(       /// Контекст, на котором воображаемая операция должна выполняться.       ActionContext & ctx,       /// Параметры воображаемой операции.        ActionParams & actionParams,       /// Интерфейс для журнализации выполняемых действий.       Logger & logger)       {

Doxygen-овский подход мне нравится тем, что он позволяет набирать текст программы последовательно – комментарий перед методом с общими словами, начало декларации метода, описание первого параметра, первый параметр, описание второго параметра, второй параметр, …, тело метода. В Java эта последовательность нарушается. Нужно либо дублировать список параметров, либо сначала писать декларацию метода (а то и весь метод), а уже потом, с помощью IDE строить описание параметров метода.

Итого. Двойственные впечатления оставляет Java. С одной стороны, очень примитивный и многословный язык, в котором развернуться особо-то и не где. С другой стороны он безопасный, программировать на нем просто, изучать его просто, за время его существования его чуть подрихтовали, сделали помощнее, поприятнее местами. Плюс к нему разработали очень мощные инструменты. Что, в результате, сделало программирование на Java более приятным занятием, чем можно было ожидать.

Так что понятно, почему Java стал мейнстримом. Но лично мне по-прежнему хочется держаться от Java подальше.