Первые 5 простых способов сделать метод лучше

Да-да, я в курсе, все пишут идеальный код и чё я вообще лезу со своим кодстайлом в эпоху, когда код пишут модели. Но мало ли, кому-то пригодится для «друга»

1️⃣Ранний возврат. У него есть кое-что общее с Маx: кто, что и сколько бы о нём ни говорил, используют всё равно ещё не все. Смысл в чём: если какой-то параметр критичен для выполнения метода, то явная его проверка на входе
➡️сокращает количество ненужных операций
➡️упрощает процесс поиска требований к данным

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

2️⃣Заключите контракт. Если метод что-то возвращает, сразу обозначьте это что-то. Можете даже назвать Результат – я вот часто так делаю. Присвойте Неопределено или пустое значение ожидаемого типа. Если результат метода – коллекция, сразу опишите коллекцию. Если это структура с важными для последующей обработки ключами: укажите эти ключи

Функция ВажныеДанные(ВажныеПараметры)
    Результат = Новый Структура();
    Результат.Вставить("ПервыйКлюч", Ложь);//показываем, что тип булево
    Результат.Вставить("ВторойКлюч", Справочники.Контрагенты.ПустаяСсылка());//показываем, что ссылка определенного типа
    Результат.Вставить("ТретийКлюч", Неопределено);//показываем, что может быть 
                                                    //составной тип
                                                    //произовольное значение 
                                                    //значние может быть не заполнено
                                                   //лучше указать, что именно

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

3️⃣Соблюдайте контракт. Не меняйте описанный результат: его тип или свойства (ключи, колонки и т.д.). Ибо грех и кары небесные.

4️⃣Явное получение необходимых данных. Если в рамках метода нужно что-то, кроме входящих параметров - позаботьтесь об этом сразу: обеспечьте прозрачность используемой информации. А ещё может быть полезно для оптимизации

//Пример (простой)

Для Каждого СтрокаТаблицы из ТабличнаяЧасть Цикл
    //какой-то код
    ОченьНужныеДанные = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(СтрокаТаблицы.Свойство, "ИмяРеквизита");
    //какой-то код
КонецЦикла;

Из хорошего о разработчике, написавшем этот код:
➡️не обращается через точку к реквизиту - знает, что фу-фу-фу, западло и мама не велит
➡️шарит за БСПшную функцию для получения реквизита
Из плохого:
➡️не в курсе, что внутри БСПшной функции - запрос, и ебашит его в цикле
➡️в целом пох на то, как будет читаться его код – получение нужных данных может быть спрятано очень искусно в нагромождениях чего попало или в другом методе

Вердикт: ебанно❌ А вот так – лучше👍

МассивСсылок = ОбщегоНазначенияКлиентСервер.СвернутьМассив(ТабличнаяЧасть.ВыгрузитьКолонку("Свойство")); 
ОченьНужныеДанные = ОбщегоНазначения.ЗначениеРеквизитаОбъектов(МассивСсылок, "ИмяРеквизита");
Для Каждого СтрокаТаблицы из ТабличнаяЧасть Цикл
    //какой-то код
    ОченьНужныеДанныеПоСтроке = ОченьНужныеДанные[СтрокаТаблицы.Свойство];
    //какой-то код
КонецЦикла;

И вот уже сразу понятно, какие дополнительные данные нужны внутри метода, и даже код оптимизирован

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

5️⃣Чем меньше возвратов - тем лучше. В идеальном методе после раннего возврата существует только один – в последней строке исполняемого кода.

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

#медвежийкодстайл