Стандарты кодирования и длина строки [закрыта]

17

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

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

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

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

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 );

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

    
задан PartialOrder 19.02.2009 в 17:24
источник
  • У меня смешанные чувства по этому поводу. Первоначально я думал, что обман, поскольку длина линии и стандарты вокруг нее обсуждались ad nauseum. С другой стороны, я думаю, что это может быть достаточно отчетливым, чтобы стоять на своем. –  EBGreen 19.02.2009 в 17:30
  • Сказав это, я предлагаю прочитать другие вопросы, где длина линии и как ее обрабатывать превзошла до смерти. stackoverflow.com/questions/131468/... –  EBGreen 19.02.2009 в 17:30
  • @EBGreen - Спасибо –  PartialOrder 19.02.2009 в 17:44
  • Основываясь на связях coobirds, я думаю, что это обман –  annakata 19.02.2009 в 17:49

14 ответов

10

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

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

-Adam     

ответ дан Adam Davis 19.02.2009 в 17:26
источник
11

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

$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 
);

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

    
ответ дан Daniel Morris 19.02.2009 в 17:37
источник
  • +1, потому что я тоже предпочитаю этот подход –  pd. 20.02.2009 в 02:27
  • Это выглядит чисто и соответствует стандарту PSR-2. –  Goke Obasa 28.06.2016 в 14:37
6

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

    
ответ дан Allain Lalonde 19.02.2009 в 17:28
источник
5

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

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

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

    
ответ дан Christopher McAtackney 19.02.2009 в 17:46
источник
  • Я сделал это, хотя на самом деле он не исправляет ужасный синтаксис вставки SQL. Почему мы не можем INSERT INTO someTable (id = 1, foo = 3, bar = 'gold') ?? –  Nick Van Brunt 19.02.2009 в 17:58
  • Я тоже это делаю. Но я также считаю, что этот стиль является сложным при использовании копирования и вставки. –  Jon Ericson♦ 19.02.2009 в 18:28
  • Ник: MySQL по крайней мере поддерживает синтаксис, такой как INSERT INTO table SET foo="foo", bar="bar" и т. д. –  pd. 20.02.2009 в 02:29
4

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

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

    
ответ дан annakata 19.02.2009 в 17:29
источник
  • Помимо вопроса о стандартах, высокое разрешение не меняет характера чтения. Когда линии становятся слишком длинными, их трудно читать. Я могу поместиться более чем в два раза, что мне удобно читать по ширине моего экрана. Использование полной ширины только замедлит меня. –  PartialOrder 19.02.2009 в 17:55
3

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

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

    
ответ дан Oliver N. 19.02.2009 в 17:27
источник
  • , и если длинная строка ДЕЙСТВИТЕЛЬНО раздражает вас, вы всегда можете включить перенос строки ... с номерами строк, отображаемыми в строке, это действительно не так уж плохо. +1 –  rmeador 19.02.2009 в 17:37
1

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

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

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

стиль.

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

    
ответ дан Alex McBride 19.02.2009 в 17:29
источник
1

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

    
ответ дан Michael Kristofik 19.02.2009 в 17:43
источник
1

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

    
ответ дан Pat 19.02.2009 в 18:23
источник
1

В прозе показалось, что строки, длина которых превышает 80 или около того, сложнее читать. (См. Стр. 13 класса LaTeX Memoir документация .) Code 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 
);
    
ответ дан Jon Ericson 19.02.2009 в 17:32
источник
  • В прозе показалось, что строки длиннее 80 или около того были прочнее - цитата? Показывается кем? –  Benubird 14.01.2016 в 14:20
  • @Benubird: я обновил ответ с помощью своего основного источника. Я видел, что это исследование ссылалось на другие места (и читать статьи, описывающие исследование), но я не помню, где они могут быть обнаружены с моей головы. –  Jon Ericson♦ 14.01.2016 в 18:00
0

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

    
ответ дан Sampson 19.02.2009 в 17:27
источник
0

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

ответ дан typeoneerror 19.02.2009 в 17:33
источник
0

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

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

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

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

    
ответ дан Matt Gardner 19.02.2009 в 17:34
источник
0

Некоторая полезная информация здесь Ссылка

    
ответ дан Mark Unwin 19.02.2009 в 23:59
источник