Парадигмы 1MIT, Стандартные замечания - История изменений

E.f.suvorov: /* Лучше прописывать типы сложных функций явно */

2017-12-02T10:53:34Z

‎Лучше прописывать типы сложных функций явно

E.f.suvorov: /* Лучше прописывать типы сложных функций явно */

2017-12-02T10:52:05Z

‎Лучше прописывать типы сложных функций явно

E.f.suvorov: /* Используйте pattern matching с let и where вместо вспомогательных функций */

2017-12-02T10:49:04Z

‎Используйте pattern matching с let и where вместо вспомогательных функций

E.f.suvorov: /* Лучше прописывать типы сложных функций явно */

2017-12-02T10:33:49Z

‎Лучше прописывать типы сложных функций явно

E.f.suvorov: /* Лучше прописывать типы функций явно */

2017-12-02T10:33:40Z

‎Лучше прописывать типы функций явно

E.f.suvorov: /* Haskell */

2017-12-02T10:28:16Z

‎Haskell

E.f.suvorov: /* Добавляйте правильный shebang */

2017-12-02T10:26:42Z

‎Добавляйте правильный shebang

E.f.suvorov: /* Иногда стоит использовать map вместо list comprehension */

2017-12-02T10:24:44Z

‎Иногда стоит использовать map вместо list comprehension

E.f.suvorov: /* Не используйте одну переменную для нескольких вещей */

2017-12-02T10:22:21Z

‎Не используйте одну переменную для нескольких вещей

E.f.suvorov: /* Проверяйте инварианты и корректность входных параметров при помощи assert */

2017-12-02T10:21:39Z

‎Проверяйте инварианты и корректность входных параметров при помощи assert

← Предыдущая		Версия 10:53, 2 декабря 2017
Строка 518:		Строка 518:
	# В некоторых случаях типы получаются настолько сложными, что лучше доверить их вывод компилятору. Впрочем, в таком случае я считал, что функция получилась слишком сложной и её стоит разделить на несколько.		# В некоторых случаях типы получаются настолько сложными, что лучше доверить их вывод компилятору. Впрочем, в таком случае я считал, что функция получилась слишком сложной и её стоит разделить на несколько.
	# Есть мнение, что лучше называть типовые переменные (<code>a</code>, <code>b</code> в примерах выше) так, чтобы они не совпадали по названиям с переменными внутри функции (<code>f</code>, <code>z</code>, <code>x</code>, <code>xs</code> в примерах выше) --- тогда они не путаются.		# Есть мнение, что лучше называть типовые переменные (<code>a</code>, <code>b</code> в примерах выше) так, чтобы они не совпадали по названиям с переменными внутри функции (<code>f</code>, <code>z</code>, <code>x</code>, <code>xs</code> в примерах выше) --- тогда они не путаются.
		+	# Максимально обобщайте типы, если пишете самостоятельно: не <code>sort :: [Int] -> [Int]</code>, а <code>sort :: Ord a => [a] -> [a]</code>.

← Предыдущая		Версия 10:52, 2 декабря 2017
Строка 517:		Строка 517:
	# В некоторых случаях типы настолько очевидны, что писать лишнюю строчку незачем.		# В некоторых случаях типы настолько очевидны, что писать лишнюю строчку незачем.
	# В некоторых случаях типы получаются настолько сложными, что лучше доверить их вывод компилятору. Впрочем, в таком случае я считал, что функция получилась слишком сложной и её стоит разделить на несколько.		# В некоторых случаях типы получаются настолько сложными, что лучше доверить их вывод компилятору. Впрочем, в таком случае я считал, что функция получилась слишком сложной и её стоит разделить на несколько.
		+	# Есть мнение, что лучше называть типовые переменные (<code>a</code>, <code>b</code> в примерах выше) так, чтобы они не совпадали по названиям с переменными внутри функции (<code>f</code>, <code>z</code>, <code>x</code>, <code>xs</code> в примерах выше) --- тогда они не путаются.

@@ Строка 420: / Строка 420: @@
 '''Осторожно''':
 # <code>let</code> --- это выражение, которое что-то возвращает (конкретно --- свою правую часть после <code>in</code>), его можно использовать где угодно. А <code>where</code> --- это блок кода после функции, живущий отдельно от выражения.
-# В <code>where</code>, в отличие от <code>let</code>, можно писать многострочные определения функций.
+# В <code>where</code>, в отличие от <code>let</code>, можно писать многострочные определения функций и даже несколько функций.
 === Вместо имён неиспользуемых переменных пишите <code>_</code> ===

@@ Строка 502: / Строка 502: @@
   foldr' _ z []     = z
   foldr' f z (x:xs) = f x (foldr' f z xs)
 '''Do''':

← Предыдущая		Версия 10:33, 2 декабря 2017
Строка 497:		Строка 497:
	# В случае с guards может быть полезно писать <code>otherwise</code>, потому что Haskell обычно не может доказать, что случаи исчерпываются перечисленным. Например, он не знает, что для любых двух переменных либо <code>a < b</code>, либо <code>a >= b</code>.		# В случае с guards может быть полезно писать <code>otherwise</code>, потому что Haskell обычно не может доказать, что случаи исчерпываются перечисленным. Например, он не знает, что для любых двух переменных либо <code>a < b</code>, либо <code>a >= b</code>.

−	=== Лучше прописывать типы функций явно ===	+	=== Лучше прописывать типы сложных функций явно ===
		+
		+	'''Don't''':
		+	foldr' _ z [] = z
		+	foldr' f z (x:xs) = f x (foldr' f z xs)
		+
		+
		+	'''Do''':
		+	foldr' :: (a -> b -> b) -> b -> [a] -> b
		+	foldr' _ z [] = z
		+	foldr' f z (x:xs) = f x (foldr' f z xs)
		+
		+	'''Причины''':
		+
		+	# Иногда можно так опечататься, что тип функции Haskell всё равно выведет, но он будет совсем неверный. Например, вместо <code>f x (foldr' f z xs)</code> написать <code>f (foldr' f z xs)</code> или <code>x (foldr' f z xs)</code> --- это всё компилируется. Как следствие, вы обнаружите это только при попытке использования функции, и тогда ошибка несоответствия типов будет занимать от половины до десятка экранов, понять будет гораздо сложнее. Более того --- нет никаких гарантий, что это ошибка возникнет при первом использовании функции.
		+	# При чтении кода иметь сигнатуру перед глазами довольно приятно: обычно это даёт сильную подсказку о том, что делает или может делать функция.
		+
		+	'''Осторожно''':
		+	# Не все согласны, что типы надо прописывать явно, руководствуйтесь style guide или чьим-нибудь чувством прекрасного.
		+	# В некоторых случаях типы настолько очевидны, что писать лишнюю строчку незачем.
		+	# В некоторых случаях типы получаются настолько сложными, что лучше доверить их вывод компилятору. Впрочем, в таком случае я считал, что функция получилась слишком сложной и её стоит разделить на несколько.

← Предыдущая		Версия 10:28, 2 декабря 2017
Строка 496:		Строка 496:

	# В случае с guards может быть полезно писать <code>otherwise</code>, потому что Haskell обычно не может доказать, что случаи исчерпываются перечисленным. Например, он не знает, что для любых двух переменных либо <code>a < b</code>, либо <code>a >= b</code>.		# В случае с guards может быть полезно писать <code>otherwise</code>, потому что Haskell обычно не может доказать, что случаи исчерпываются перечисленным. Например, он не знает, что для любых двух переменных либо <code>a < b</code>, либо <code>a >= b</code>.
		+
		+	=== Лучше прописывать типы функций явно ===

@@ Строка 292: / Строка 292: @@
 # В мире Linux Shebang --- это общепринятый способ запуска скриптов независимо от того, на каком языке они написаны. Хорошо бы, чтобы ваш код его поддерживал. Это требуется не только в чистом Linux, но и в некоторых ситуациях под Windows.
 # Вы не знаете заранее, где установлена нужная версия Python; где-то она может быть в <code>/usr/bin/local/python3</code>, где-то в <code>/usr/bin/python</code>, а где-то --- вообще в неочевидном месте (например, при использовании [http://eax.me/python-virtualenv/ Virtualenv]). По этому поводу прописывать какой-то конкретный путь в Shebang нехорошо, лучше использовать утилиту <code>/usr/bin/env</code> (она гарантированно есть на всех разумных системах), которая просто запустит команду с названием <code>python3</code> (а где она лежит --- сама разберётся).
-'''Мифы''': пока не придумал.
+'''Мифы''':
 '''Осторожно''':

@@ Строка 252: / Строка 252: @@
 # Аналогично, не стоит передавать list comprehension в качестве второго параметра для <code>map</code>.
 # <code>map</code> возвращает не список, а ''генератор''. Условно, это такой список, который можно прочитать только один раз. Это обычно подходит, если результат <code>map</code> сразу идёт в какую-то функцию, но не подходит, если вам нужен именно список значений. В таком случае сконструируйте список, явно вызвав <code>list(...)</code>.
 # Если вы присваиваете в срез уже существующего списка или матрицы, то не требуется превращать результат <code>map</code> в отдельно живущий список. Rule of thumb: если из результата работы <code>map</code> будет произведено копирование, причём ровно одно, его в список можно не превращать.
 # <code>np.array</code> ругается, если ему передать в качестве аргумента результат <code>map</code>. Поэтому всё-таки <code>np.array(list(map(...)))</code> (за исключением ситуации из предыдущего пункта --- там хватит обычного <code>list</code>).

@@ Строка 105: / Строка 105: @@
 '''Мифы''':
 # ''Если сделать несколько переменных, придётся придумывать нормальные имена, а это никому не нужно''. Действительно, придётся придумать нормальные имена, но это довольно полезно. В первую очередь для вас: с нормальными именами переменных вы можете понять, что делает кусок кода, взглянув только на него, а не на всю программу сразу.
-# ''Дополнительные переменные замедляют программу''. В программе у вас вряд ли больше нескольких десятков/сотен/тысяч переменных. Одно выделение — это ни о чём. А в, скажем, C++, выделить место под ''все'' локальные переменные — это вообще одна ассемблерная инструкция в начале функции; так что от их количества ничего не зависит.
+# ''Дополнительные переменные замедляют программу''. В программе у вас вряд ли больше нескольких десятков/сотен/тысяч переменных. Одно выделение — это ни о чём. А в, скажем, C++, выделить место под ''все'' локальные переменные — это вообще одна ассемблерная инструкция в начале функции; так что от их количества ничего не зависит. Более того ---- современные оптимизаторы умные и сами догадаются, что в какой-то момент переменная не используется и её место (в памяти или даже в регистре) можно переиспользовать под другую.
 # ''Если кусок кода маленький, то можно уследить за смыслом переменной''. Воспринимать строчку в отдельности от остальных мозгу проще. Если вы видите строчку вроде <code>a = a ** 2</code>, вы, скорее всего, по контексту догадаетесь, что теперь <code>a</code> — это площадь квадрата. Но через несколько строчек может использоваться другое предположение: <code>a</code> — это удвоенная сторона. Если вы не прочитаете эти строчки ''одновременно'', вы не заметите эту ошибку.

@@ Строка 52: / Строка 52: @@
 # Если понаставить слишком много <code>assert</code>'ов, код становится невозможно читать.
 # Не стоит проверять корректность интерпретатора/компилятора. Например, после строчки <code>a = x[2]</code> строчка <code>assert a == x[2]</code> бессмысленно, равно как и проверка отсортированности массива чисел после вызова <code>sort</code>.
-# Не стоит писать в <code>assert</code> код с побочными эффектами. Некоторые языки и/или оптимизаторы (например, Java) могут просто вырезать все <code>assert</code> в не-отладочном режиме.
+# Не стоит писать в <code>assert</code> код с побочными эффектами. Некоторые языки и/или оптимизаторы (например, Java или Visual C++) могут просто вырезать все <code>assert</code> в не-отладочном режиме.
 # Если вы пишете production-сервис для Яндекс/Google, то падение программы нежелательно и вместо <code>assert</code> следует использовать другие конструкции и восстанавливать работу программы.