ЕМ
Максимум - плстфикс
Size: a a a
2018 November 20
AA
что противоречит стандартам Совместимо 1С
1с Совместимо Префиксы рекомендует ;)
PZ
что противоречит стандартам Совместимо 1С
В стандарте разработки есть замечательная строка.
Если в этом есть необходимость то от стандарта можно отступить
Если в этом есть необходимость то от стандарта можно отступить
ЕМ
да ладно, мПеременная в модулях и в типовых есть
Давно не видел уже
AS
1с Совместимо Префиксы рекомендует ;)
AS
Примеры некорректных имен переменных:
масРеквизитов, соотвВидИмя, новСтр
масРеквизитов, соотвВидИмя, новСтр
AS
P Z
В стандарте разработки есть замечательная строка.
Если в этом есть необходимость то от стандарта можно отступить
Если в этом есть необходимость то от стандарта можно отступить
в этом необходимости нет
AS
достаточно потратить время на нормальное наименование переменных
AS
у меня нанэйминг уходит 20% времени, так как это заставляет думать о правильности архитектурных решений
А что вы на префиксы так ополчились? Это все лишь вопрос код стайла. Код от этого хуже не станет. Разве что глаз кому то режет)
Z
Есть смысл в префиксах только для переопределяемых в расширении методов, чтобы они между собой не конфликтовали, если переопркделяют кортежем. больше нет
AS
для этого есть геттер
AS
так что в префиксах смысла нет в принципе, либо проблема инкапсуляции, либо лени
n
Хоть на канале стандартов и поругали это правило, а я его в некоторых случаях горячо поддерживаю. Немного в другом виде правда, использую для обозначения того является ли параметр только входным, либо еще и модифицируется. Либо только выходным (например текст ошибки).
n
Ну вот пример чистой функции на несколько строк: валидация каких то данных по условию.
Есть два варианта:
1) Вернуть структуру с полями Ошибка, Описание. Тогда каждый раз при использовании придется значение сохранять в отдельную переменную, проверять, выводить
2) Вернуть булево как результат и текст ошибки в параметре, тогда можно использовать следующим образом Если ВалидироватьЗначение(Значение, Ошибка) Тогда ... сообщить об ошибке КОнецЕсли
Есть два варианта:
1) Вернуть структуру с полями Ошибка, Описание. Тогда каждый раз при использовании придется значение сохранять в отдельную переменную, проверять, выводить
2) Вернуть булево как результат и текст ошибки в параметре, тогда можно использовать следующим образом Если ВалидироватьЗначение(Значение, Ошибка) Тогда ... сообщить об ошибке КОнецЕсли
PZ
А вы про переменные?
Z
Ну вот пример чистой функции на несколько строк: валидация каких то данных по условию.
Есть два варианта:
1) Вернуть структуру с полями Ошибка, Описание. Тогда каждый раз при использовании придется значение сохранять в отдельную переменную, проверять, выводить
2) Вернуть булево как результат и текст ошибки в параметре, тогда можно использовать следующим образом Если ВалидироватьЗначение(Значение, Ошибка) Тогда ... сообщить об ошибке КОнецЕсли
Есть два варианта:
1) Вернуть структуру с полями Ошибка, Описание. Тогда каждый раз при использовании придется значение сохранять в отдельную переменную, проверять, выводить
2) Вернуть булево как результат и текст ошибки в параметре, тогда можно использовать следующим образом Если ВалидироватьЗначение(Значение, Ошибка) Тогда ... сообщить об ошибке КОнецЕсли
я за 1 вариант
ВМ
Хоть на канале стандартов и поругали это правило, а я его в некоторых случаях горячо поддерживаю. Немного в другом виде правда, использую для обозначения того является ли параметр только входным, либо еще и модифицируется. Либо только выходным (например текст ошибки).
Если параметр процедуры модифицируется - это тоже code-smell. Сеттеры и геттеры хорошо бы разделять.