Вызовы метода усечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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