Соглашения об именах делают код лучше обслуживаемым?

Question

Мне нравится давать моим переменным, методам и объектам описательные имена. Очевидно, что я не перейду за борт, но позвольте привести несколько примеров.

public class Account
{
    public decimal Balance { get; set; }
}

Account account = new Account();
account.Balance = 1000;

Некоторые люди предпочли бы пойти на следующее, что на самом деле не имеет смысла для меня, если вы не ленивый машинистка.

Account acc = new Account();
acc.Balance = 1000;

Проблема в том, когда у вас есть логика с этими сокращениями. Вы очень запутались в том, что происходит.

Представьте себе следующие объекты.

public class Account { public DebitOrder DebitOrder { get; set; } }
public class DebitOrder { BankDetail BankDetail { get; set; } }
public class BankDetail {}

Account acc = new Account();
DebitOrder do = new DebitOrder();
BankDetail bd = new BankDetail();

if(acc.DebitOrder.SomeProperty == do.SomeProperty)
{

}

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

Обозначает ли соглашение об именах более удобный для сопровождения код?

Answer 1

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

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

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

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

Answer 2

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

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

Например, счетчик в цикле может иметь простое имя, если тело цикла мало и счетчик не перерисовывается, имеет другое значение:

for (int i = 0; i < 10; i++) arr[i] = 0;

Лямбда-выражения могут быть более читабельными при использовании короткого имени:

var items = source.Select(n => n.ToString() + ".");

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

Например, будет работать n для числового значения, как в вышеприведенном лямбда-выражении. Использование чего-то более длинного, которое все еще является аббревиатурой, например itnum или itmid, заставляет имя содержать больше информации, но недостаточно, чтобы быть полезным, так что itemNumber или itemId будет лучше.

Answer 3

Когда я программирую на таких языках, как C #, я часто даю своим переменным короткие имена только потому, что их легче набирать, и я могу разместить больше кода на экране.Это хорошо работает, когда вы находитесь в зоне и точно знаете, что это такое, но именно по тем причинам, которые вы упомянули, это будет очень запутанным для постороннего или даже для вас через несколько часов.Хорошие IDE позволяют легко переименовывать переменные, что я определенно рекомендовал бы сделать перед уходом из вашего проекта на ночь или перед тем, как поделиться им..