Считается ли хорошим стилем использование пробела для выравнивания кода?

Ответ 1

Python PEP 8 (который является "Руководством по стилю для кода Python" ) требует, чтобы вы не использовали пробелы для выравнивания кода:

Любители домашних животных

Avoid extraneous whitespace in the following situations:

....

- More than one space around an assignment (or other) operator to
  align it with another.

  Yes:

      x = 1
      y = 2
      long_variable = 3

  No:

      x             = 1
      y             = 2
      long_variable = 3

Ответ 2

Сменили ли вы свои теги? Я вижу несколько ответов, относящихся к Python, но единственный тег, который я вижу, это Scala. Если вас интересует Scala, я бы назвал неофициальный Scala Руководство по стилю. Основываясь на руководстве по стилю, я бы предположил, что ваш пример должен выглядеть так:

val foo = -1
val bar = 1
val yohoho = Double.NaN

Ответ 3

Это просто мое скромное мнение, но я лично просто ненавижу отступы, как второй вариант в любом языке программирования. Некоторые утверждают, что "это выглядит хорошо", но я считаю это совершенно непрактичным. Например, чтобы переименовать переменную yohoho, вы должны перестроить все остальные переменные (и большинство редакторов не помогут вам в этом).

Ответ 4

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

Ответ 5

Что вам подходит, вы кодер. Первый из них просто выглядит забавным для меня.

Ответ 6

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

С другой стороны, если ваш код/​​алгоритм намного читабельнее, когда он выровнен, а затем выровняйте его! Читаемость превосходит все остальные проблемы, согласно гибкому манифесту:

• Лица и взаимодействия над процессами и инструментами

то есть. Более важно, чтобы другие программисты были счастливы, чем довольствоваться инструментами diff.

Ответ 7

Я пробовал это с помощью Python, например, в объявлениях модели Django.

Это становится ОКР, вызывающим боль, когда вы позже модифицируете код. Например, что, если вы добавите var во имя yoohoohoey во втором примере? Вы должны вернуться и добавить пробелы в каждую строку, чтобы выровнять ее с новой длиной.

Итак, я предпочитаю делать что-то в первую очередь.

Ответ 8

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

Но это вопрос предпочтения.

Ответ 9

Scala Руководство по стилю не поддерживает тему, но я не видел вертикально выровнять объявления в коде Scala, поэтому Я бы выбрал первый вариант.

Ответ 10

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

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

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

Ответ 11

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

Ответ 12

Как часто у вас есть несколько инициализированных объявлений val или var в файле Scala? Верхние уровни vals и vars в классах должны в основном быть параметрами первичного конструктора, если это возможно. Верхний уровень vals в чертах, скорее всего, будет абстрактным и, следовательно, не инициализирован. Валс и вары внутри методов абсолютно не должны дополняться, так как переупорядочение вполне вероятно.

Я просто просмотрел проект класса 200 Scala, и нашел только один класс, в котором эта проблема возникает даже (модуль "шаблон торта", где vals объявляют компоненты моего приложения). Это не проблема.

Ответ 13

Что вам подходит, вы кодер. Второй мне просто кажется забавным.

Ответ 14

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

Ответ 15

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

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

Ответ 16

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

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

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

Кроме того, зачем ограничивать макеты таблиц только столбцами с выравниванием по левому краю? ^^

   val foo : Int    = -1
   val bar : Int    =  1
val yohoho : Double =  NaN

Ответ 17

Второй стиль дает головную боль, когда вам нужно искать определенный текст. Когда файл кода становится большим, иногда вам нужно искать определенный текст. Если вы кодируете пользовательские пространства, его трудно найти. У нас был плохой опыт работы с большими XML файлами, содержащими скрипты TSQL, Coders передо мной, используя стиль 2, как в вашем примере, заканчивается всякий раз, когда мы добавляем новое правило или обновляем старый, очень сложно искать файлы с кодами, которые переполнены пользовательскими пространствами.

Ответ 18

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