Обрезание вызовов метода

Question

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

Проблема в том, что группа моих коллег будет обрезать вызовы методов, чтобы соответствовать ширине. Мы все используем широкоэкранные ноутбуки, которые могут работать с большими разрешениями (у меня это 1920x1200), и когда дело доходит до отладки и чтения кода, я считаю, что гораздо проще читать вызовы однострочных методов, чем многострочные.

Вот пример метода (как мне бы хотелось):

IReallyLongInterfaceName instanceOfInterfaceName = OurContainer.retrieveClass(IReallyLongInterfaceName.class, param1, param2, param3);

(я тоже очень не люблю длинные имена интерфейсов / классов:)

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

IReallyLongInterfaceName instanceOfInterfaceName = OurContainer.retrieveClass(IReallyLongInterfaceName.class, 
                                                                              param1, 
                                                                              param2, 
                                                                              param3);

Что для вас легче читать в конце дня, и был бы я неоправданно просить их использовать первый из двух (как это является частью нашего стандарта)?

Answer 1

Я считаю первый пример более читабельным в целом, хотя, если он длиннее некоторого предопределенного предела (для меня 120 символов), я бы разбил строки:

IReallyLongInterfaceName instanceOfInterfaceName =
        OurContainer.retrieveClass(IReallyLongInterfaceName.class,
                                   param1, param2, param3);

Answer 2

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

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

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

Answer 3

Если в стандарте кодирования компаний прямо указано, что метод один является правильным, то непременно стонет на них, ведь они не придерживаются стандартов компании. Если это не указано явно, то я думаю, сейчас самое время привести его в стандарт. Однако следует помнить одну вещь, если вы используете IDE с автоформатированием, это то, что он может самостоятельно переформатировать методы для стиля 2 при его запуске. Так что даже если все пишут в стиле 1, он может не выглядеть так, когда закончил с ним.

и, как и Фил, я нахожу способ 2 более читабельным, поскольку вы можете видеть все, что вам нужно, без необходимости смотреть вбок :)

Answer 4

Может быть, вы должны иметь в качестве части стандартного процесса сборки какой-нибудь плагин checkstyle, который проверяет именно такие вещи? Если вы согласовали стандарт со своими коллегами, кажется разумным попросить их придерживаться его.

Лично я нахожу второй из двух вариантов более читабельным, но это только потому, что у меня нет широкоэкранного монитора;)

Answer 5

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

Итак, я обычно пишу так, если в данной функции более 3 параметров:

applyEncryptionParameters(key,
                          certificate,
                          0, // strength - set to 0 to accept default for platform
                          algorithm);

Answer 6

Я также предпочитаю вариант № 2. Проблема не только в том, как это выглядит на экране (и если бы у меня было 1920 пикселей по горизонтали, у меня было бы намного больше пристыкованных окон), а в том, как это выглядит, если мне нужно распечатать и прочитать его. Длинные строки будут печататься ужасно из большинства IDE, тогда как строки, разбитые автором с намерением улучшить разборчивость, будут печататься хорошо.

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

Я думаю, что 80 может быть чрезмерно произвольным, но я использую 10pt Consolas, и мне кажется, что я могу получить около 100 символов в строке на стандартной 8,5 "печатной странице.

Теперь, в конце концов, это священная война. Может быть, не так плохо, как поставить свои фигурные скобки, но это там. Я отдал вам свои предпочтения, но реальный вопрос возвращается к вам: каков стандарт вашей компании? Мне кажется, что они стандартизированы в варианте № 2, что означает, что ради команды, вы, вероятно, должны адаптироваться к ним.