Подтвердить что ты не робот

Стандарты кодирования и длина линии

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

Очевидно, если это возможно, не пишите слишком длинные строки.

Но что, если это не практично? Как следует обрабатывать длинные строки?

Вот несколько примеров

if ($Stmt = $Mysqli->prepare("SELECT color, pattern, size,
                              manufacturer, mfgSku, storeLocation,
                              aisle, status
                              FROM tblItems WHERE ourSku = ?")) {

или

$flavors = array ('chocolate', 'strawberry', 'vanilla', 'cookie dough', 
                  'chocolate chip', 'mint chocolate chip', 'rocky road',
                  'peach', 'fudge brownie', 'coffee', 'mocha chip');

или

$Stmt->bind_result( $this->_firstName,
                    $this->_lastName,
                    $this->_BillToAddress->address1,
                    $this->_BillToAddress->address2,
                    $this->_BillToAddress->city,
                    $this->_BillToAddress->state,
                    $this->_BillToAddress->zip,
                    $this->_BillToAddress->country,
                    $this->_email,
                    $this->_status,
                    $this->_primaryPhone,
                    $this->_mobilePhone );

В каждом из этих примеров отступы длинного кода различны. Есть ли лучший или более "стандартный" способ сделать это? Если дополнительные строки всегда имеют отступы одинаково. Или это нормально?

4b9b3361

Ответ 1

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

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

Ответ 2

Мои личные предпочтения заключаются в следующем:

$Stmt->bind_result(
    $this->_firstName,
    $this->_lastName,
    $this->_BillToAddress->address1,
    $this->_BillToAddress->address2,
    $this->_BillToAddress->city,
    $this->_BillToAddress->state,
    $this->_BillToAddress->zip,
    $this->_BillToAddress->country,
    $this->_email,
    $this->_status,
    $this->_primaryPhone,
    $this->_mobilePhone 
);

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

Ответ 3

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

Ответ 4

Необычный стиль отступов, который я обнаружил в процессе выполнения большого количества работы SQL, был

INSERT INTO someTable
(
    id,
    name,
    age,
    address1,
    address2,
)
VALUES
(
    2,
    'Bob'
    25,
    '12 Fake Street',
    'The Moon'
)

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

Ответ 5

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

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

Ответ 6

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

Vim и emacs обрабатывают длинные строки очень хорошо, и они устанавливаются почти в каждом окне Unix. В Windows вы почти всегда будете в текстовом редакторе графического интерфейса. Я действительно думаю, что ваш стиль $Stmt->bind_result является самым легким для чтения, но если вам просто нужно загрузить кучу большей части статической информации в одном из операторов, у меня нет проблем с линией с 1000 символами.

Ответ 7

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

Для меня лично, исходя из фона Python, я использую длину строки 79 и

$flavors = array ('chocolate', 'strawberry', 'vanilla', 'cookie dough', 
                  'chocolate chip', 'mint chocolate chip', 'rocky road',
                  'peach', 'fudge brownie', 'coffee', 'mocha chip');

стиль.

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

Ответ 8

В прозе показалось, что строки, длина которых превышает 80 или около того, сложнее читать. (См. Стр. 13 класса LaTeX Memoir документация.) Код Complete (раздел 18.5, страница 425 моего издания) также ссылается на ограничение 80 символов с этой оговоркой:

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

Я бы отделил SQL в вашем первом примере отдельно от остальной части кода:

if ($Stmt = $Mysqli->prepare(
            "SELECT color, pattern, size,
                    manufacturer, mfgSku, storeLocation,
                    aisle, status
             FROM tblItems 
             WHERE ourSku = ?")) {

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

Третий - это хорошо, но вы можете немного подтянуть его:

$Stmt->bind_result( 
   $this->_firstName,
   $this->_lastName,
   $this->_BillToAddress->address1,
   $this->_BillToAddress->address2,
   $this->_BillToAddress->city,
   $this->_BillToAddress->state,
   $this->_BillToAddress->zip,
   $this->_BillToAddress->country,
   $this->_email,
   $this->_status,
   $this->_primaryPhone,
   $this->_mobilePhone 
);

Ответ 9

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

Ответ 10

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

Ответ 11

Я не знаю ни одного стандарта, поскольку было бы трудно сказать. Для тех из нас, кто работает на больших мониторах, мы можем видеть более горизонтальный код, чем другие, на более мелких мониторах. Обычно я пытаюсь построить длинные строки последовательно через. = (PHP), когда это необходимо, и, как показал ваш код, я произвольно разбиваю массивы на новые строки в зависимости от того, сколько символов существует в этой конкретной строке.

Ответ 12

Я не против варианта 3 слишком много (1 пункт в строке). Кроме того, лично, я всегда использую wordwrapping, поэтому наличие кода на одной строке не беспокоит меня вообще. Тем не менее, в вашем втором примере, когда речь заходит об объявлении, это может показаться беспорядочным для программистов, которые действительно используют wordwrapping. Возможно, я из небольшой группы, которые не против длинных строк.

Ответ 13

Лучшая практика обычно проистекает из целей самого ограничения длины строки:

  • Повысить интероперабельность (между программистами, программным обеспечением для редактирования и т.д.).
  • Чтобы повысить читаемость и понимание.
  • Чтобы увеличить скорость и скорость развития
  • Чтобы увеличить доходы и прибыль

Таким образом, ваши варианты, такие как выравнивание всех параметров stmt, хороши, если они вносят вклад как в ваше собственное понимание будущего, так и из других в вашей команде.

Надеюсь, что это поможет;) -M