Рискованно ли выбирать нестандартный стиль отступа Java-кода?

Question

Имеет ли значение, если вы выбираете нестандартный стиль отступа?

Это стиль, который я вижу чаще всего:

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

public class Test {
    static public void main(String args[]) throws Exception {
        FileInputStream fin = new FileInputStream("infile.txt");
        FileOutputStream fout = new FileOutputStream("outfile.txt");

        FileChannel inc = fin.getChannel();
        FileChannel outc = fout.getChannel();

        ByteBuffer bb = ByteBuffer.allocateDirect(1024);

        while (true) {
            int ret = inc.read(bb);
            if (ret == -1)
                break;

            bb.flip();
            outc.write(bb);
            bb.clear();
        }
    }
}

Но я предпочитаю этот стиль, где все начинается со следующей строки:

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

public class Test
{
    static public void main(String args[]) throws Exception
    {
        FileInputStream fin = new FileInputStream("infile.txt");
        FileOutputStream fout = new FileOutputStream("outfile.txt");

        FileChannel inc = fin.getChannel();
        FileChannel outc = fout.getChannel();

        ByteBuffer bb = ByteBuffer.allocateDirect(1024);

        while (true)
        {
            int ret = inc.read(bb);
            if (ret == -1)
                break;

            bb.flip();
            outc.write(bb);
            bb.clear();
        }
    }
}

Мне легче читать, но возникнут ли у меня проблемы с другими, если я буду использовать этот стиль?

Answer 1

1. Примите решение о едином соглашении в команде (желательно стандартное, если вы хотите работать с другими позже)
2. Сконфигурируйте и все остальные IDE, чтобы использовать этои только это.
3. Сделайте переформатирование происходить автоматически и желательно при каждом нажатии Ctrl-S.

Это сделает все источники единообразными в любое время и обеспечит изменения вИсходный репозиторий - это реальные изменения, а не просто переформатирование в более позднее время.

Для Eclipse это можно сделать путем настройки средства форматирования (мне нравятся значения по умолчанию) и сохранения настроек, которые затем могут быть загружены всемиостальное.Кроме того, действия Java -> Editor -> Save позволяют автоматически переформатировать при каждом нажатии Ctrl-S, что является также сохраняемым предпочтением.

Я обнаружил, что выше, дополнительная эвристика

• Все должно помещаться на одной строке

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

---

Редактировать: Я написалв моем блоге об этом .

---

Редактировать 2014-08-19: Похоже, что если параметры форматирования Eclipse сохранены в файл, IntelliJ IDEA может форматировать источник, используя этот файл.

Answer 2

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

Answer 3

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

Обычно это подразумевает бесконечные дискуссии, но я думаю, что 2 из перечисленныхвот более распространенные.

Answer 4

Я не согласен с вашим названием. Как 1-й стандарт и 2-й нестандарт?

Настройки меняются со временем. Мы больше не программируем на 80 * 25 текстовых терминалах. Мы пишем разные типы кодов. Обоснование сохранения одной строки становится все более и более забавным.

@RequestMapping(value="/hotels/{hotel}/bookings/{booking}",
                method=RequestMethod.GET)
public String getBooking(
        @PathVariable("hotel") long hotelId, 
        @PathVariable("booking") long bookingId, 
        Model model) {                                    // WOW! I SAVED A LINE!
    Hotel hotel = hotelService.getHotel(hotelId);
    Booking booking = hotel.getBooking(bookingId);
    model.addAttribute("booking", booking);
    return "booking";
}

Answer 5

Я давно перестал беспокоиться о форматировании кода.Какая трата кислорода, спорить о размещении фигурных скобок.Когда мне нужно изменить код, я переформатирую файл с помощью средства форматирования кода в среде IDE, используя настройки по умолчанию.Тогда я делаю свою работу и совершаю ее.Когда кто-то другой изменяет файл, он может отформатировать его по своему вкусу.Меня это не волнует.

Я бы раньше программистов тратил время на обсуждение алгоритмов, структур данных и стратегий тестирования.

Answer 6

У вас не будет проблем с другими, если они все будут использовать тот же стандарт размещения скобок и отступа, что и вы.

У вас будут проблемы, если вы одинокий волк.

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

Когда в Риме, делай, как римляне. Придите к консенсусу в вашей команде и придерживайтесь его.

PS - Я с вами: я предпочитаю иметь брекеты на следующей строке. Солнечная конвенция - первая. Это лучше для авторов книг, потому что там меньше пробелов.

Answer 7

Это не имеет значения. В любом случае большинство компаний используют форматировщик кода.

Я также предпочитаю второй стиль.

Answer 8

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

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

Answer 9

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

Answer 10

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

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

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