Элементы стиля Scala? [закрыто]

Днем я пишу C #. Все, что я делаю, проходит через инструменты анализа кода и статического анализа Microsoft, поэтому мой C # имеет очень регулярную структуру и структуру. Очевидно, я пишу код с определенным стилем. Это отчасти потому, что у меня нет выборане скомпилировать, если я пропущу пробел перед запятой), ноТакже хорошо иметь регулярно выглядящий код, зная, где искать вещи и т. д.

На выходных яЯ вхожу в Скалу. Глядя на Scala API иЛифт источник веб-фреймворка, я могуОчевидно, мы видим любой стандартизированный стиль. Например, одна вещь, которая бросается в глаза, - это отсутствие отдельного файла для каждого класса. Отсутствие согласованности со скобками и фигурными скобками является еще одним примером.

Я понимаю, что, возможно, есть несколько причин, объясняющих это: во-первых, с открытым исходным кодом (или хобби), обеспечивающим, чтобы очевидный метод неПолностью документированный является менее приоритетным. Во-вторых, такие вещи, как case-классы, сокращают 20-строчные объявления классов в одну строку. В-третьих, C # оченьльстить» язык: если некомплексLINQ оператор, число вложенных паренсов, скобок и скобоктак глубоко В Scala вещи, как правило, немного вложены.

У обычных пользователей Scala есть определенный стиль, к которому они привязаны? Разве я просто глуп, помещая однострочный case-класс в свой собственный файл ради [чужой] конвенции? Какие-нибудь советы?

 Kevin Meredith18 дек. 2013 г., 02:52
Г-н Одерский выступил с основным докладом на Scala Days 2013:Scala with Styleparleys.com/play/51c1994ae4b0d38b54f4621b/chapter0/about

Ответы на вопрос(5)

который используют многие кодировщики Scala, поэтому я просто применяю тот же стандарт, который использовал бы в C #, Java или особенно JavaScript.

ScalaМожно Будьте очень выразительными, но использование незнакомого формата увеличит ваш барьер для входа. Особенно учитывая внутреннийDSL,, который не мог иметь "Стандарт».

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

Решение Вопроса

формой в Scala, если классы тесно связаны между собой.

Хотя это и необязательно, тип, возвращаемый методом - именованной функцией, объявленной в признаке, классе или объекте, - как ожидается, будет объявлен для не закрытых методов. Пробелы ожидаются после:, но не до этого.

//  methods declared on a class, trait or object
def length: Int = ...
def multiply(other: Foo): Foo = ...

def hypotenuse(a: Double, b: Double): Double = {
  //  function inside a method, so effectively private
  def square(x: Double) = x * x

  math.sqrt(square(a) + square(b))
}

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

//  keywords
if (foo) ...

//  dot notation
foo.doSomething(bar)

//  operator notation
foo doSomething bar
foo + bar

Исключительно, при объединении строк с+Рекомендуемый стиль - не использовать пробелы вокруг него. Например:

//  concatenate strings
println("Name: "+person.name+"\tAge: "+person.age)

Ожидается, что объявления, которые могут быть однострочными, будут однострочными, если вложенность неЭто очевидно.

//  one-liners
lazy val foo = calculateFoo
def square(x: Int) = x * x

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

//  without side-effects
val x = foo.length
val y = bar.coefficient

//  with side-effects
foo.reverse()

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

//  single-line expression
def sum(list: List[Int]): Int = if (!list.isEmpty) list reduceLeft (_ + _) else 0

//  multi-line expression
val sum = (
  getItems
  reduceLeft (_ + _)
)

Для понимания, генераторы и условия должны быть выровнены вертикально, кажется, принятым стилем. Что касаетсяyieldЯ видел, что оба выровнены сfor и с отступом.

//  for-comprehensions
val squares =
  for (x <- numbers)
    yield x * x

// Curly brackets-style identation
val cells = for {
  x <- columns
  y <- rows
  if x != y
} yield Cell(x, y)

// Parameter-style identation
val cells = for (x <- columns;
                 y <- rows;
                 if x != y)
            yield Cell(x, y)

Это'Также принят стиль для вертикального выравнивания параметров объявления класса.

Говоря об отступе, два пробела - это общепринятая конвенция.

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

//  another example
def factorial(n: Int): Int = {
  def fact(n: Int, acc: Int): Int = n match {
    case 0 => acc
    case x => fact(x - 1, x * acc)
  }

  fact(n, 1)
}

Для процедур - функции, чей тип возвратаUnit - ожидаемый стиль должен был опускать тип метода и знак равенства:

//  procedures
def complain {
  println("Oh, no!")
}

Некоторые люди думают, что этот стиль подвержен ошибкам, так как пропущенный знак равенства изменит функцию, возвращающую что-то отличное отUnit в процедуру.

Идентификаторы написаны в случае верблюда (например:identifiersHaveHumps), как в Java. Для имен полей, параметров метода, локальных переменных и функций начните со строчной буквы. Для классов, черт и типов, начните с заглавной буквы.

Отступление от соглашения Java - имена констант. В Scala практикой является использование стандартного верблюжьего регистра, начинающегося с заглавной буквы. НапримерPi и неPI, XOffset а неX_OFFSET, За этим правилом обычно следует любой синглтон. Представление констант и синглетонов таким образом имеет практическое значение для случаев:

import scala.Math.Pi

val pi = Pi // this identifier will be shadowed by the identifier in the function below

def isPi(n: Double): Boolean = n match {
  case Pi => println("I got a true Pi."); true
  case pi => println("I got "+pi+" and bounded it to an identifier named pi."); false
}

Имена пакетов пишутся со строчной буквы. Это особенно полезно при различении в операторе импорта, что является пакетом, а что нет. В предыдущем примереMath это не пакет (этоs singleton), так как он начинается с заглавной буквы.

Используя символ подчеркивания -_ - не рекомендуется, так как этот персонаж имеет много специальных значений в Scala. Эти правила для идентификаторов могут быть найдены на страницах 141 и 142 Программирование в Scala, Odersky, Spoon & Веннерс.

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

Что еще более важно, возможно, просто нетна самом деле большая часть единой конвенции. Одной из причин этого может быть то, что Scala привлекает людей из самых разных слоев общества, таких как специалисты по функциональному языку, программисты на Java и энтузиасты веб 2.0.

 nafg16 апр. 2013 г., 06:29
Зачем звонишьsquare функция?
 Daniel C. Sobral07 сент. 2009 г., 03:12
@Marcus Downing: пример многострочного выражения неверен. Я'Я исправлю это.
 Daniel C. Sobral15 авг. 2009 г., 20:19
Хорошо яисправлю ответ. На самом деле, ясделаю это сообществом. Тем не менее, была некоторая дискуссия о создании методов и функций без параметровне используйте круглые скобки во всех случаях.
 Jens Schauder10 мая 2013 г., 15:06
Было бы неплохо, если бы кто-то мог добавить что-нибудь о именовании файлов, которые содержат несколько классов.
 Daniel C. Sobral05 сент. 2009 г., 00:22
Это сообщество вики. Преуспевать.
 Daniel Spiewak15 авг. 2009 г., 18:48
На самом деле, я думаю, что "оставь равных стильМеньше подвержен ошибкам, так как это фактически сокращение для явного аннотирования модуля. Намерение очень ясно, и это намного более кратко чем явная аннотация. Стоит отметить, чтовсе Методы побочных эффектов должны быть объявлены в скобках, особенно включая arity-1. Методы без скобоктолько для чистых функций и логических методов доступа к свойствам.
 Marcus Downing04 сент. 2009 г., 22:20
Хороший ответ, который можно сделать с большим количеством примеров. Вы не возражаете, если я добавлю немного?
 Marcus Downing06 сент. 2009 г., 18:05
Готово. Вы хотите проверить раздел о понимании и заполнить раздел о занятиях?
 Daniel C. Sobral16 апр. 2013 г., 15:49
@nafg Я понятия не имею, каково было мое намерение, но я, конечно, нене согласен с тем, что говорится, поэтому яЯ исправлю это.
 Flaviu Cipcigan15 авг. 2009 г., 20:19
На самом деле, книга «Программирование в Scala» рекомендует не использовать скобки метода, если метод не имеет аргументов.а также не имеет побочных эффектов (например, при доступе к состоянию объекта). Поэтому звонок какprintln() должен иметь круглую скобку, ноqueue.size или жеarray.length Безразлично»т (см. Единый принцип доступа -en.wikipedia.org/wiki/Uniform_access_principle). Последний пример будетqueue.size() а такжеarray.length в Яве, которая нене уважать этот принцип.

предложено сообществу, Это н'Даже пока официально, но это единственная (насколько мне известно) кодификация принятых сообществом конвенций.

PDFТекст
 sdkfasldf21 мая 2012 г., 08:54
В этом руководстве по стилю должно быть больше оснований для принятия решений.
 robinst05 мая 2010 г., 14:50
Самая новая версия здесь:davetron5000.github.com/scala-style
 metasim05 июн. 2016 г., 15:52
Я думаюЛи Хаои 'новые статьи заслуживают крика.

Руководство по стилю Scala доступен. Это'не является 100% официальным (расположен на "Документация сообщества для Scala " сайт), но кажется самым стандартным руководством по стилю для Scala.

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

Чтобы ответить на ваш второй вопрос (своего рода): в общем, каждый класс / признак / объект должен получить свой собственный файл, названный в соответствии с соглашениями об именах Java. Однако в ситуациях, когда у вас много классов, которые разделяют одну общую концепцию, иногда проще (как в краткосрочной, так и в долгосрочной перспективе) поместить их все в один файл. Когда вы делаете это, имя файла должно начинаться со строчной буквы (все еще camelCase) и описывать эту общую концепцию.

 Daniel C. Sobral15 авг. 2009 г., 17:03
Укажите, пожалуйста, какие-либо ошибки в моем ответе. Я не хочу распространять информацию об ошибочных стилях - мы достаточно разошлись.

Ваш ответ на вопрос