Конечно, это зависит от того, что человек считает «хорошей практикой». Разные языки обычно пытаются навязывать / поощрять свое собственное мнение о том, что такое «хорошая практика кодирования».
Некоторые примеры хороших практик, которые пытаются поощрять некоторые языки:
Код отступа на логических уровнях:
Если есть одна практика, с которой почти все программисты согласны, что это хорошая практика, это то, что разные блоки кода должны иметь отступ.
Например, рассмотрим следующий код Java:
static boolean isPrime(final int x) {
if (x % 2 == 0 && x != 2) {
return false;
} else if (x > 1) {
final int MIDWAY = (x-1) / 2;
for (int i = MIDWAY; i > 1; i--) {
if (x % i == 0) {
return false;
}
}
return true;
}
return false;
}
Рекомендуется делать отступы кода в разных областях (например, тело функции, блок for, блок if). Тем не менее, вы НЕ ДОЛЖНЫ делать отступы в своем коде согласованным образом (или даже вообще) в большинстве языков. Ничто не мешает мне написать все это без отступов, как это:
static boolean isPrime(final int x) {
if (x % 2 == 0 && x != 2) {
return false;
} else if (x > 1) {
final int MIDWAY = (x-1) / 2;
for (int i = MIDWAY; i > 1; i--) {
if (x % i == 0) {
return false;
}
}
return true;
}
return false;
}
Вы могли бы даже написать все это в 1 строку, если хотите! Код все еще будет работать, но он будет намного менее читабельным.
Однако языки, использующие синтаксис вне правил (например, Python, Nim), заставляют вас делать отступы в коде согласованным образом. Так, например, следующий код Python:
def is_prime(x):
if x % 2 == 0 and x != 2:
return False
elif x > 1:
MIDWAY = int((x-1) / 2)
for i in range(MIDWAY, 1, -1):
if x % i == 0:
return False
return True
return False
ДОЛЖЕН быть отступ. Это не будет работать, если это не так. Не может Я не могу написать этот код без отступа, потому что блоки определяются с отступом (а не {}, что используется большинством языков).
Хорошо, Python позволяет вам быть НЕМНОГО гибким с вашим отступом. 1-лайнер может идти по одной линии, например так:
def is_prime(x):
if x % 2 == 0 and x != 2: return False # This is allowed.
elif x > 1:
MIDWAY = int((x-1) / 2)
for i in range(MIDWAY, 1, -1):
if x % i == 0: return False # So is this
return True
return False
Но это только для 1-лайнеров. Блоки, содержащие несколько операторов (например, блок elif), не могут быть сделаны в 1 строке.
Константы именования LIKE_THIS:
Общепринятым соглашением о кодировании является присвоение имен константам CAPITALISED_WITH_UNDERSCORES. Это просто, чтобы вы (и другие программисты) могли сразу отличить нормальную переменную от константы.
Теперь у Ruby нет пользовательских констант ( sob ), но у них есть что-то вроде этого: Ruby выдаст вам предупреждение, если вы попытаетесь изменить переменную с именем LIKE_THIS. Э.Г.
my_var = 5 # creating a normal variable
my_var = 42 # this is ok
puts my_var
ANOTHER_VAR = 21 # creating a pseudo-constant
ANOTHER_VAR = 32 # interpreter will complain about this
puts ANOTHER_VAR # Will still work though
Этот вывод этого кода:
42
test.rb:5: warning: already initialized constant ANOTHER_VAR
test.rb:4: warning: previous definition of ANOTHER_VAR was here
32
Таким образом, Ruby поощряет (но не заставляет) следовать наилучшей практике именования ваших констант с помощью UPPERCASE_WITH_UNDERSCORES.
Использование констант над переменными:
Как правило, если вы создаете переменную, которую вы назначаете только один раз (может быть, это просто для хранения промежуточного значения или вам просто не нужно повторно присваивать ему), эта переменная ДОЛЖНА быть константой (например, MIDWAY var в приведенном выше Java-коде; если я не намерен переназначать его, почему бы не сделать это намерение явным для других, сделав его постоянным?).
В Rust переменные являются неизменяемыми (то есть постоянными) по умолчанию, если не указано иное (что противоположно тому, что делают Java и C ++). Пример кода Rust:
let x = 42; // declaring an immutable variable
x = 10; // compiler will give an error; can't reassign to x.
let mut y = 42; // declaring a mutable (i.e. "normal") variable
y = 10; // allowed
В этом смысле Rust рекомендует вам использовать константы по умолчанию и действительно думать о том, когда они должны быть переменными (тогда как в большинстве других языков вы используете переменные по умолчанию и редко думаете о том, когда они должны быть константами).
ПРИМЕЧАНИЕ: ТЕХНИЧЕСКИ неизменяемые переменные - это не то же самое, что константы в Rust (Rust на самом деле имеет константы, объявленные с ключевым словом const, но они оцениваются во время компиляции). Но поскольку они действуют как константы в других языках, я буду называть их константами для целей этого поста.
Кроме того, большинство языков не будут так сильно поощрять вас к активному использованию хороших практик, как они будут препятствовать (или просто прямо мешать) вам использовать «плохие» практики.
Например, общепринятое мнение гласит, что использование goto является плохой практикой, поэтому большинство языков даже не имеют goto (исключая C & C ++)!
Отсюда, однако, мнения, как правило, расходятся в отношении того, какие функции считаются настолько плохими (с точки зрения поощрения «плохой практики»), которых стоит не иметь. Например, чрезмерное использование break и continue в циклах считается плохой практикой (по тем же причинам, что и goto), поэтому у Scala даже нет break или continue (ну, по крайней мере, нет встроенный в язык)! Разработчики Go считали, что обработка исключений имеет тенденцию злоупотребляться (то есть искушать программистов писать сложный код и рассматривать слишком много обычных ошибок как «исключительные»), поэтому Go даже не обрабатывает исключения! Многие языки считают код, злоупотребляющий операторами ++ и --, хитрым и неясным, поэтому они просто не имеют таких операторов (Rust, Python, Swift 4 и т. Д.). Обратите внимание, что здесь не так много консенсуса относительно того, что считается хорошей и плохой практикой.
Итак, вы получили исчерпывающий список (может добавить к нему в будущем) некоторых языков, которые пытаются так или иначе поощрять хорошие методы кодирования (или, по крайней мере, то, что они считают хорошая практика кодирования).