Выдержки из книги Чистый код
Разработка - Математика и алгоритмы
В этой статье я привожу выдержки (цитаты) из книги "Чистый код" Роберта Мартина (Robert Cecil Martin).
Весь текст сохранен в виде вырезок из книги без каких либо изменений. Примеры коды мои собственные.
Расплата за хаос
Если вы занимались программированием более двух-трех лет, вам наверняка доводилось вязнуть в чужом — или в своем собственном — беспорядочном коде.
Замедление может быть весьма значительным. За какие-нибудь год-два группы, очень быстро двигавшиеся вперед в самом начале проекта, начинают ползти со скоростью улитки. Каждое изменение, вносимое в код, нарушает работу кода в двух-трех местах. Ни одно изменение не проходит тривиально. Для каждого дополнения или модификации системы необходимо «понимать» все хитросплетения кода — чтобы в программе их стало еще больше. Со временем неразбериха разрастается настолько, что справиться с ней уже не удается. Выхода просто нет.
По мере накопления хаоса в коде производительность группы начинает снижаться, асимптотически приближаясь к нулю. В ходе снижения производительности начальство делает единственное, что оно может сделать: подключает к проекту новых работников в надежде повысить производительность. Но новички ничего не понимают в архитектуре системы. Они не знают, какие изменения соответствуют намерениям проектировщика, а какие им противоречат. Более того, они — и все остальные участники группы — находятся под страшным давлением со стороны начальства. В спешке они работают все небрежнее, отчего производительность только продолжает падать.
Основной парадокс
Программисты сталкиваются с основным парадоксом базовых ценностей. Каждый разработчик, имеющий сколько-нибудь значительный опыт работы, знает, что предыдущий беспорядок замедляет его работу. Но при этом все разработчики под давлением творят беспорядок в своем коде для соблюдения графика. Короче, у них нет времени, чтобы работать быстро!
Настоящие профессионалы знают, что вторая половина этого парадокса неверна. Невозможно выдержать график, устроив беспорядок. На самом деле этот беспорядок сразу же замедлит вашу работу, и график будет сорван. Единственный способ выдержать график — и единственный способ работать быстро — заключается в том, чтобы постоянно поддерживать чистоту в коде.
ГРЭДИ БУЧ
Чистый код прост и прямолинеен. Чистый код читается, как хорошо написанная проза. Чистый код никогда не затемняет намерения проектировщика; он полон четких абстракций и простых линий передачи управления.
МАЙКЛ ФИЗЕРС
Чистый код всегда выглядит так, словно его автор над ним тщательно потрудился. Вы не найдете никаких очевидных возможностей для его улучшения. Все они уже были продуманы автором кода.
Правило бойскаута
Хорошо написать код недостаточно. Необходимо поддерживать чистоту кода с течением времени. Все мы видели, как код загнивает и деградирует с течением времени. Значит, мы должны активно поработать над тем, чтобы этого не произошло.
У бойскаутов существует простое правило, которое применимо и к нашей профессии:
Оставь место стоянки чище, чем оно было до твоего прихода
Содержательные имена
Имена должны передавать намерения программиста
Имя переменной, функции или класса должно отвечать на все главные вопросы. Оно должно сообщить, почему эта переменная (и т. д.) существует, что она делает и как используется. Если имя требует дополнительных комментариев, значит, оно не передает намерений программиста.
Избегайте дезинформации
Программисты должны избегать ложных ассоциаций, затемняющих смысл кода.
Не используйте слова со скрытыми значениями, отличными от предполагаемого
Используйте удобопроизносимые имена
Людям удобно работать со словами. Значительная часть нашего мозга специализируется на концепции слов, а слова по определению удобопроизносимы.
Было бы обидно не использовать ту изрядную часть мозга, которая развивалась для разговорной речи. Следовательно, имена должны нормально произноситься.
Выбирайте имена, удобные для поиска
У однобуквенных имен и числовых констант имеется один специфический недостаток: их трудно искать в большом объеме текста.
Избегайте схем кодирования имен
У нас и так хватает хлопот с кодированием, чтобы искать новые сложности. Кодирование информации о типе или области видимости в именах только создает новые хлопоты по расшифровке.
Венгерская запись
В доисторические времена, когда в языках действовали ограничения на длину имен, мы нарушали это правило по необходимости — и не без сожалений. В Fortran первая буква имени переменной обозначала код типа. В ранних версиях BASIC имена могли состоять только из одной буквы и одной цифры. Венгерская запись (HN, Hungarian Notation) подняла эту проблему на новый уровень. Венгерская запись играла важную роль во времена Windows C API, когда программы работали с целочисленными дескрипторами (handle), длинными указателями, указателями на void или различными реализациями «строк» (с разным применением и атрибутами). Компиляторы в те дни не поддерживали проверку типов, поэтому программистам были нужны «подсказки» для запоминания типов.
В современных языках существует куда более развитая система типов, а компиляторы запоминают типы и обеспечивают их соблюдение. Более того, появилась тенденция к использованию меньших классов и более коротких функций, чтобы программисты видели точку объявления каждой используемой переменной. Объекты обладают сильной типизацией, а рабочие среды развились до такой степени, что могут выявить ошибку типа еще до начала компиляции! Таким образом, в наши дни венгерская запись и другие формы кодирования типов в именах превратились в обычные пережитки прошлого. Они усложняют изменение имени или типа переменных, функций и классов. Они затрудняют чтение кода. Наконец, они повышают риск того, что система кодирования собьет с толку читателя кода.
Код должен быть как можно более выразительным. Слишком длинные выражения, венгерская запись, «волшебные числа» — все это скрывает намерения автора.
Имена методов
Имена методов представляют собой глаголы или глагольные словосочетания.
Выберите одно слово для каждой концепции
Если вы используете переменную ЗаказанноеКоличество обозначая количество товара в заказе, придерживайтесь этого названия во всем модуле. Если же будет в одной части кода переменная ЗаказанноеКоличество, в другом просто Количество, в дальше КЗаказу это будет вызывать недоумение и лишнюю трату времени на сопоставления этих названий.
Функции
Компактность!
Первое правило: функции должны быть компактными. Второе правило: функции должны быть еще компактнее.
Желательно, чтобы длина функции не превышала 20 строк.
Блоки и отступы
Из сказанного выше следует, что блоки в командах if, else, while и т. д. должны состоять из одной строки, в которой обычно содержится вызов функции. Это не только делает вмещающую функцию более компактной, но и способствует документированию кода, поскольку вызываемой в блоке функции можно присвоить удобное содержательное имя.
Правило одной операции
Функция должна выполнять только одну операцию. Она должна выполнять ее хорошо. И ничего другого она делать не должна.
Чтение кода сверху вниз: правило понижения
Код должен читаться как рассказ — сверху вниз.
За каждой функцией должны следовать функции следующего уровня абстракции. Это позволяет читать код, последовательно спускаясь по уровням абстракции в ходе чтения списка функций. Я называю такой подход «правилом понижения».
Сказанное можно сформулировать и иначе: программа должна читаться так, словно она является набором абзацев, каждый из которых описывает текущий уровень абстракции и ссылается на последующие абзацы следующего нижнего уровня.
Команды switch
Написать компактную команду switch довольно сложно. Даже команда switch всего с двумя условиями занимает больше места, чем в моем представлении должен занимать один блок или функция.
Аргументы функций
В идеальном случае количество аргументов функции равно нулю (нульарная функция). Далее следуют функции с одним аргументом (унарные) и с двумя аргументами (бинарные). Функций с тремя аргументами (тернарных) следует по возможности избегать. Необходимость функций с большим количеством аргументов (полиарных) должна быть подкреплена очень вескими доводами — и все равно такие функции лучше не использовать.
плохо
ВыполнитьРасчет(Параметр1, Параметр2, Парметр3, Праметр4)
хорошо
ВыполнитьРасчет(ПараметрыРасчета)
Аргументы-флаги
Аргументы-флаги уродливы. Передача логического значения функции — воистину ужасная привычка. Она немедленно усложняет сигнатуру метода, громко провозглашая, что функция выполняет более одной операции. При истинном значении флага выполняется одна операция, а при ложном — другая!
плохо
УчитыватьСкидки= Истина;
ВыполнитьРасчет(УчитыватьСкидки);
хорошо
Если УчитыватьСкидки Тогда
ВыполнитьРасчетСУчетомСкидок();
Иначе
ВыполнитьРасчетБезУчетаСкидок();
КонецЕсли;
Бинарные функции
Функцию с двумя аргументами понять сложнее, чем унарную функцию. Например, вызов writeField(name) выглядит более доступно, чем writeField(outputStream, name). Хотя смысл обеих форм понятен, первая форма просто проскальзывает под нашим взглядом, моментально раскрывая свой смысл. Во второй форме приходится сделать непродолжительную паузу, пока вы не поймете, что первый
Тернарные функции
Разобраться в функции с тремя аргументами значительно сложнее, чем в бинарной функции. Проблемы соблюдения порядка аргументов, приостановки чтения и игнорирования увеличиваются более чем вдвое. Я рекомендую очень хорошо подумать, прежде чем создавать тернарную функцию.
Глаголы и ключевые слова
Выбор хорошего имени для функции способен в значительной мере объяснить смысл функции, а также порядок и смысл ее аргументов. В унарных функциях сама функция и ее аргумент должны образовывать естественную пару «глагол/существительное».
ПровестиДокументы(Документы);
Избавьтесь от побочных эффектов в функциях
Побочные эффекты суть ложь. Ваша функция обещает делать что-то одно, но делает что-то другое, скрытое от пользователя. Иногда она вносит неожиданные изменения в переменные своего класса — скажем, присваивает им значения параметров, переданных функции, или глобальных переменных системы. В любом случае такая функция является коварной и вредоносной ложью, которая часто приводит к созданию противоестественных временных привязок и других зависимостей.
Разделение команд и запросов
Функция должна что-то делать или отвечать на какой-то вопрос, но не одновременно. Либо функция изменяет состояние объекта, либо возвращает информацию об этом объекте. Совмещение двух операций часто создает путаницу.
Используйте исключения вместо возвращения кодов ошибок
Возвращение кодов ошибок функциями-командами является неочевидным нарушением принципа разделения команд и запросов. Оно поощряет использование команд в предикатных выражениях if :
Такие конструкции не страдают от смешения глаголов с прилагательными, но они приводят к созданию структур слишком глубокой вложенности. При возвращении кода ошибки возникает проблема: вызывающая сторона должна немедленно отреагировать на ошибку.
плохо
Результат= ПроизвестиРасчет();
Если Результат = Неопределено Тогда
Сообщить(«Ошибка»);
КонецЕсли;
хорошо
Функция ПроизвестиРасчет()
Попытка
Исключение
Сообщить(«»)
КонецПопытки
КонецФункции
Изолируйте блоки try/catch
Блоки try / catch выглядят весьма уродливо. Они запутывают структуру кода и смешивают обработку ошибок с нормальной обработкой. По этой причине тела блоков try и catch рекомендуется выделять в отдельные функции.
Функция ОпределитьПриоритет(ВидОперации)
Если ВидОперации = 1 Тогда
ИначеЕсли ВидОперации = 2 Тогда
Иначе
КонецЕсли
КонецФункции
Обработка ошибок как одна операция
Функции должны выполнять одну операцию. Обработка ошибок — это одна операция. Значит, функция, обрабатывающая ошибки, ничего другого делать не должна. Отсюда следует, что если в функции присутствует ключевое слово try, то оно должно быть первым словом в функции, а после блоков catch / finally ничего другого быть не должно (как в предыдущем примере).
Не повторяйтесь
Дублирование иногда считается корнем всего зла в программировании. Было создано много приемов и методологий, направленных на контроль и устранение дублирования.
Похоже, с момента изобретения подпрограмм все новшества в разработке программного обеспечения были направлены исключительно на борьбу с дублированием в исходном коде.
Комментарии
Не комментируйте плохой код — перепишите его. (Брайан У. Керниган и П. Дж. Плауэр)
Ничто не помогает так, как уместный комментарий. Ничто не загромождает модуль так, как бессодержательные и безапелляционные комментарии. Ничто не приносит столько вреда, как старый, утративший актуальность комментарий, распространяющий ложь и дезинформацию.
Грамотное применение комментариев должно компенсировать нашу неудачу в выражении своих мыслей в коде. Обратите внимание на слово «неудачу». Я абсолютно серьезно. Комментарий — всегда признак неудачи. Мы вынуждены использовать комментарии, потому что нам не всегда удается выразить свои мысли без них, однако гордиться здесь нечем.
Почему я так настроен против комментариев? Потому что они лгут. Не всегда и не преднамеренно, но это происходит слишком часто. Чем древнее комментарий, чем дальше он расположен от описываемого им кода, тем больше вероятность того, что он просто неверен. Причина проста: программисты не могут нормально сопровождать комментарии.
Комментарии не компенсируют плохого кода
Одной из распространенных причин для написания комментариев является низкое качество кода. Вы пишете модуль и видите, что код получился запутанным и беспорядочным. Вы знаете, что разобраться в нем невозможно. Поэтому вы говорите себе: «О, да это стоит прокомментировать!» Нет! Лучше исправьте свой код!
Объясните свои намерения в коде
плохо
РаспределитьСуммуПропорциональноКоэффициентам(РаспределяемаяСумма, КоэффициентыРаспределения, Точность);
хорошо
РаспределитьСуммуПропорциональноКоэффициентам(РаспределяемаяСумма, МассивКоэффициентов, Точность);
Юридические комментарии
Иногда корпоративные стандарты кодирования заставляют нас вставлять комментарии по юридическим соображениям. Например, заявление об авторских правах — необходимая информация, которая вполне может размещаться в комментарии в начале каждого файла с исходным кодом.
// Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved.
// Публикуется на условиях лицензии GNU General Public License версии 2 и выше.
Информативные комментарии
Иногда бывает полезно включить в комментарий пояснение к коду.
Предупреждения о последствиях
Иногда бывает полезно предупредить других программистов о нежелательных
последствиях от каких-либо действий. Например, следующий комментарий объясняет, почему конкретный тестовый сценарий был отключен:
// Не запускайте, если только не располагаете
// излишками свободного времени.
Комментарии TODO
Иногда бывает полезно оставить заметки «на будущее» в форме комментариев
// TODO - На данный момент эта функция не используется.
Усиление
Комментарий может подчеркивать важность обстоятельства, которое на первый взгляд кажется несущественным
Ссылки на авторов
// Добавлено Петей 10.05.2019
Системы контроля исходного кода отлично запоминают, кто и когда внес то или иное исправление. Нет необходимости загрязнять код подобными ссылками.
Закомментированный код
В программировании редко встречаются привычки более отвратительные, чем закрытие комментариями неиспользуемого кода. Никогда не делайте этого!
Нелокальная информация
Если вы должны написать комментарий, проследите за тем, чтобы он описывал находящийся поблизости код. Не излагайте информацию системного уровня в контексте локального комментария.
Заголовки функций
Короткие функции не нуждаются в долгих описаниях. Хорошо выбранное имя компактной функции, которая выполняет одну операцию, обычно лучше заголовка с комментарием.
УдалитьВременныйКаталог(Знач ПутьККаталогу);
Форматирование
Мы хотим, чтобы читатель, заглянувший «под капот» программы, был поражен увиденным — нашей аккуратностью, логичностью и вниманием к мелочам. Мы хотим, чтобы на него произвела впечатление стройность кода. Мы хотим, чтобы он уважительно поднял брови при просмотре модулей. Мы хотим, чтобы наша работа выглядела профессионально. Если вместо этого читатель видит беспорядочную массу кода, словно написанного шайкой пьяных матросов, то он заключит, что такое же неуважение к мелочам проникло и во все остальные аспекты проекта.
Вы должны позаботиться о том, чтобы ваш код был хорошо отформатирован. Выберите набор простых правил, определяющих формат кода, и последовательно применяйте их в своей работе. Если вы работаете в составе группы, то группа должна выработать согласованный набор правил форматирования, соблюдаемых всеми участниками. Также полезно иметь средства автоматизации, которые применяют правила форматирования за вас.
Вертикальное форматирование
Типичная длина кода составляет 200 строк, с верхним пределом в 500 строк. Хотя это не должно считаться раз и навсегда установленным правилом, такие показатели весьма желательны. Маленькие файлы обычно более понятны, чем большие.
Газетная метафора
Представьте себе хорошо написанную газетную статью. Естественно, статья читается по вертикали. В самом начале обычно располагается заголовок с общей темой статьи; он помогает вам решить, представляет ли статья интерес для вас. В первом абзаце приводится краткое изложение сюжета на уровне общих концепций, без приведения каких-либо подробностей. По мере продвижения к концу статьи объем детализации непрерывно растет, пока вы не узнаете все даты, имена, цитаты и т. д.
Исходный файл должен выглядеть как газетная статья. Имя файла должно быть простым, но содержательным. Одного имени должно быть достаточно для того, чтобы читатель понял, открыл ли он нужный модуль или нет. Начальные блоки исходного файла описывают высокоуровневые концепции и алгоритмы. Степень детализации увеличивается при перемещении к концу файла, а в самом конце собираются все функции и подробности низшего уровня в исходном файле. Газета состоит из множества статей, в большинстве своем очень коротких. Другие статьи чуть длиннее. И лишь немногие статьи занимают всю газетную страницу. Собственно, именно этим газеты так удобны. Если бы они состояли из одной длинной статьи с неупорядоченной подборкой фактов, дат и имен, то мы бы просто не смогли их читать.
Вертикальное разделение концепций
Практически весь код читается слева направо и сверху вниз. Каждая строка представляет выражение или условие, а каждая группа строк представляет законченную мысль. Эти мысли следует отделять друг от друга пустыми строками.
Вертикальное сжатие
Если вертикальные пропуски разделяют концепции, то вертикальное сжатие подчеркивает тесные связи. Таким образом, строки кода, между которыми существует тесная связь, должны быть «сжаты» по вертикали.
&НаКлиенте
Процедура СписокНоменклатураВыбор(Элемент, ВыбраннаяСтрока, Поле, СтандартнаяОбработка)
**
ВыбратьКоличество();
КонецПроцедуры
&НаКлиенте
Процедура ВыбратьКоличество()
Оповещение= Новый ОписаниеОповещения("ВыборКоличестваЗавершение", ЭтотОбъект);
***
КонецПроцедуры
&НаКлиенте
Процедура ВыборКоличестваЗавершение(Результат, ДопПараметры) Экспорт
***
КонецПроцедуры
Вертикальные расстояния
Вам когда-нибудь доводилось метаться по классу, прыгая от одной функции к другой, прокручивая исходный файл вверх-вниз, пытаясь разобраться, как функции связаны друг с другом и как они работают, — только для того, чтобы окончательно заблудиться в его запутанных нагромождениях? Когда-нибудь искали определение функции или переменной по цепочкам наследования? Все это крайне неприятно, потому что вы стараетесь понять, как работает система, а вместо этого вам приходится тратить время и интеллектуальные усилия на поиски и запоминание местонахождения отдельных фрагментов.
Концепции, тесно связанные друг с другом, должны находиться поблизости друг от друга по вертикали.
Объявления переменных.
Переменные следует объявлять как можно ближе к месту использования.
Зависимые функции.
Если одна функция вызывает другую, то эти функции должны располагаться вблизи друг от друга по вертикали, а вызывающая функция должна находиться над вызываемой (если это возможно). Тем самым формируется естественная структура программного кода. Если это правило будет последовательно соблюдаться, читатели кода будут уверены в том, что определения функций следуют неподалеку от их вызовов.
&НаКлиенте
Процедура ПересчитатьЦеныВКорзине()
КонецПроцедуры
&НаКлиенте
Процедура ПересчитатьЦеныВСтрокеКорзины(ТекущаяСтрока)
КонецПроцедуры
Концептуальное родство.
Некоторые фрагменты кода требуют, чтобы их разместили вблизи от других фрагментов. Такие фрагменты обладают определенным концептуальным родством. Чем сильнее родство, тем меньше должно быть вертикальное расстояние между ними.
Вертикальное упорядочение
Как правило, взаимозависимые функции должны размещаться в нисходящем порядке. Иначе говоря, вызываемая функция должна располагаться ниже вызывающей функции. Так формируется логичная структура модуля исходного кода – от высокого уровня к более низкому. Как и в газетных статьях, читатель ожидает, что самые важные концепции будут изложены сначала, причем с минимальным количеством второстепенных деталей. Низкоуровневые подробности естественно приводить в последнюю очередь. Это позволяет нам бегло просматривать исходные файлы, извлекая суть из нескольких начальных функций, без погружения в подробности.
Горизонтальное форматирование
Строки лучше делать по возможности короткими.
Длинна строки должна быть от 80 символов до 120 символов.
Горизонтальное разделение и сжатие
Горизонтальные пропуски используются для группировки взаимосвязанных элементов и разделения разнородных элементов.
Пример сжатие при арифметических
Горизонтальное выравнивание операциях.
Нет необходимости в горизонтальном выравнивании
Отступы
Код должен содержать отступы. Благо сейчас за отступы отвечают редакторы кода.
Правила форматирования в группах
У каждого программиста есть свои любимые правила форматирования, но если он работает в группе, то должен руководствоваться групповыми правилами.
Группа разработчиков согласует единый стиль форматирования, который в дальнейшем применяется всеми участниками.
Код программного продукта должен быть оформлен в едином стиле. Он не должен выглядеть так, словно был написан несколькими личностями, расходящимися во мнениях по поводу оформления.
Обработка ошибок
Используйте исключения вместо кодов ошибок
Начните с написания команды try-catch-finally
Размещая код в секции try команды try - catch - finally, вы утверждаете, что выполнение программы может прерваться в любой точке, а затем продолжиться в секции catch.
Блоки try в каком-то отношении напоминают транзакции. Секция catch должна оставить программу в целостном состоянии, что бы и произошло в секции try. По этой причине написание кода, который может инициировать исключения, рекомендуется начинать с конструкции try - catch - finally. Это поможет вам определить, чего должен ожидать пользователь кода, что бы ни произошло в коде try.
Не возвращайте null
На мой взгляд, при любых обсуждениях обработки ошибок необходимо упомянуть о неправильных действиях программистов, провоцирующих ошибки.
На первом месте в этом списке стоит возвращение null. Я видел бесчисленное множество приложений, в которых едва ли не каждая строка начиналась с проверки null.
Если ваша кодовая база содержит подобный код, возможно, вы не видите в нем ничего плохого, но это не так! Возвращая null, мы фактически создаем для себя лишнюю работу, а для вызывающей стороны — лишние проблемы. Стоит пропустить всего одну проверку null, и приложение «уходит в штопор».
Не передавайте null
Возвращать null из методов плохо, но передавать null при вызове еще хуже. По возможности избегайте передачи null в своем коде.
***
Если честно, то ко многим принципам описанным в этой заметки я пришел сам, за более чем десятилетий стаж работы программистом. Значит рано или поздно каждый должен выработать в себе определённые принципы помогающие писать понятный и поддерживаемый код.
Эти принципы несколько расходятся с теми, что описаны в стандартах разработки 1С. Но лично мне они нравятся больше. Например, принцип "Зависимые функции" позволяет не раскидывать логически связанные функции по модулям, избавляет от долгих переходов. В книжке автор приводит пример, когда регистрировал свои действия при правке кода и с ужасом обнаружил, что больше всего времени тратимся на скроллинг мышкой. Да и многие другие моменты очень помогают ориентироваться в хорошо написанном коде. В передаче кучи параметров в функции я стал по другому относится. Не возвращать Неопределенно тоже заставляет задуматься.
В общем, статья к размышлению.
Вступайте в нашу телеграмм-группу Инфостарт
Чистый код принципы программирования Роберт Мартин Robert Cecil Martin
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Математика и алгоритмы Разработчик 1С 8.3 Абонемент ($m)
Данная внешняя обработка для платформы 1С:Предприятие реализует усовершенствованный алгоритм Левенштейна для вычисления схожести строк с учетом различных лингвистических особенностей русского языка. В отличие от классической реализации, этот алгоритм учитывает фонетические, визуальные и контекстные особенности набора текста.
1 стартмани
07.11.2025 7047 18 InFlach 17
Математика и алгоритмы Запросы Разработчик 1С:Предприятие 8 Бесплатно (free)
Рассмотрим быстрый алгоритм поиска дублей с использованием hash функции по набору полей шапки и табличных частей.
08.07.2024 9200 ivanov660 9
Математика и алгоритмы Разработчик 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)
На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.
1 стартмани
30.01.2024 17005 stopa85 12
Математика и алгоритмы Бесплатно (free)
Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.
19.10.2023 25275 user1959478 57
Математика и алгоритмы Разное 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)
Расширение (+ обработка) представляют собою математический тренажер. Ваш ребенок сможет проверить свои знание на математические вычисление до 100.
2 стартмани
29.09.2023 15760 maksa2005 8
Математика и алгоритмы Инструментарий разработчика Разработчик 1С:Предприятие 8 Россия Абонемент ($m)
Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.
1 стартмани
09.06.2023 25590 13 SpaceOfMyHead 20
Математика и алгоритмы Разработчик 1С:Предприятие 8 Бесплатно (free)
Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.
03.04.2023 17753 RustIG 10
Механизмы платформы 1С Математика и алгоритмы Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
В статье анализируются средства платформы для решения системы линейных уравнений в 1С. Приводятся доводы в пользу некорректной работы встроенных алгоритмов, а значит потенциально некорректного расчета себестоимости в типовых конфигурациях.
23.11.2022 16636 gzharkoj 17
//плохо
ВыполнитьРасчет(Параметр1, Параметр2, Парметр3, Праметр4)
//хорошо
ВыполнитьРасчет(ПараметрыРасчета)
ПоказатьЕсли ты передаешь параметры функции в одной структуре, ты все равно ожидаешь все параметры, которые содержатся в структуре.
В данном случае, тебе нужно лезть в функцию, чтобы посмотреть какие же параметры должны быть в структуре.
Что же тут хорошего?
У Мартина, видимо, речь идет о том, чтобы уменьшить количество параметров, которые используются в функции.
И если функция использует слишком много параметров - разбивай ее на несколько функций, а не собери все параметры в одну коллекцию и подпихни их через нее.
Мне передача аргументов через структуры очень нравится. Наиболее важные преимущества тут кстати ещё и в:
1. Нет строго порядка аргументов - не нужно задумывать об этом при вызове функций, особенно когда позже к функции добавляются новые аргументы
2. Относительно легко решаются вопросы с необязательными аргументами и их значениями
3. А главное - такие структуры аргументов могут передаваться через кучу вложенных вызовов функций - и бывает так что нужно расширить аргументы какой-то вложенной функции - так вот со структурой это делается очень легко - а без неё - придётся модифицировать все промежуточные функции.
4. Если Вы добавили к типовой функции новые аргументы, а потом в новом типовом релизе к ней добавились новые типовые аргументы - то в случае со структурной - проблемы крайне маловероятны - а вот без неё - проблем может быть очень много - причём трудно выявляемых при обновлении
5. Структура аргументов легко вручную сериализуется (в случае необходимости, например, для передачи между контекстами - там где типовая неявная сериализация не работает).
Единственное о чём тут надо помнить - это то, что стуркутры - это динамические объекты - каждый раз создавая структуры - вы создаёте новый экземпляр - и он не будет равен другому экземпляру структуру но с такими же элементами. Причём даже как ключи, скажем "Соответствия" эти структуры будут различны (хотя в сериализованном в строку виде - могут быть идентичны)
Наиболее существенно это для функций из модулей повторного использования.
Лично в таких случаях - либо передаю в такие функции - структуры, уже сериализованные в строку
Либо создаю такие структуры через специальную функцию из модуля повторного использования - она принимает исходные аргументы и возвращает кешируемую, им соответствующую, структуру.
Функция ПроизвестиРасчет()
Попытка
Исключение
Сообщить(«»)
КонецПопытки
КонецФункции
неправильно маскировать от пользователя и администратора исходную проблему:
// на клиенте
Попытка
ВыполнитьОперацию();
Исключение
ПоказатьПредупреждение(,НСтр("ru = 'Операция не может быть выполнена.'"));
КонецПопытки;
Правильно записывать в журнал регистрации подробное представление исключения, а краткое представление добавлять в текст сообщения пользователю:
&НаСервере
Процедура ВыполнитьОперацию()
Попытка
// код, приводящий к вызову исключения
....
Исключение
// Запись события в журнал регистрации для системного администратора.
ЗаписьЖурналаРегистрации(НСтр("ru = 'Выполнение операции'"),
УровеньЖурналаРегистрации.Ошибка,,,
ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
ВызватьИсключение;
КонецПопытки;
КонецПроцедуры ПоказатьИ это ещё без учёта транзакций!
У нас своя библия )
В суть в другом:
Если нужно сделать несколько действий, результаты которых нужно проверять, то лучше все действия сделать в одной попытке, как то так.
То есть это пример расходится со стандартом, а не рекомендации из книги
Неужели франчи 100% выполняют эти правила и им доплачивают?
Кладут обычно не потому что не доплачивают, а потому что не умеют.
Стоимость поддержки смелл-кода не учитывается.
PS Хороший код можно поискать в продуктах. Не во всех.
Мне, например, приходит на ум одна конфигурация для гостиниц/отелей - точно не помню названия.. написана на английском диалекте 1С.
Думаю, делалась для турецких отелей и программистами пришедшими в 1С из другого языка.
1) При установке платформы можно выбрать язык, на котором будете кодировать (но тут как правило проблем нет)
2) у конфигурации тоже есть настройка языка, в конфигураторе.
Вообще работал с Отелем лет так 5-6 назад.
Его вообще писали для Турецких отелей как я понял тогда,
там большинство инсталляций.
Соответственно, язык - внутри на латинице.
Но если выставить конфигурации русскую локализацию -
то латинская работать будет продолжать,
а вот наоборот - не работает.
Аргументы-флаги
плохо
УчитыватьСкидки= Истина;
ВыполнитьРасчет(УчитыватьСкидки);
хорошо
Если УчитыватьСкидки Тогда
ВыполнитьРасчетСУчетомСкидок();
Иначе
ВыполнитьРасчетБезУчетаСкидок();
КонецЕсли;
При такой конструкции код только усложнится для понимания. В двух процедурах будет выполнятся одинаковый код "Расчет", его куда деть? Еще одну процедуру Расчет() делать?
Будет ли это интересно кому то?
"Вы ДОЛЖНЫ", "Вы ОБЯЗАНЫ", "НУЖНО"
А иначе что? Хаос поглотит нас? Кому мы должны или обязаны? Кому нужно?
Например, венгерская нотация, которую обозвали пережитком. Недавно я начал называть переменные, объявленные внутри процедуры, не как Переменная, а как прПеременная. И знаете что случилось? Стало УДОБНЕЕ! Реально, одного взгляда на переменную хватает, чтобы понять, что это не параметр функции, не имя реквизита или общего модуля, а именно переменная, объявленная тут же. Если раньше на клавиатуре клавиша F12 стиралась первой, то теперь я иногда даже забываю, что она означает.
Две буквы перед именем внутренней переменной упростили работу больше, чем все комментарии и понятные имена вместе взятые! И целый хоровод Мартинов, Майклов и прочих желающих может затребовать моей крови в Гаагском трибунале - это не изменит того факта, что очень простая венгерская манипуляция упростила мне работу. Иногда влажу в свой код годичной давности и вроде всё нравится, но коробит от того, что надо периодически подсматривать, переменная это или реквизит или ещё что-то. Сразу рука тянется дописать "пр".
И вот что теперь делать с этими "НУЖНО-ДОЛЖНЫ"?
Дальше:
Системы контроля бла-бла-бла
Кто-нибудь когда-нибудь пользовался хранилищем 1С? Сколько времени уйдёт выяснить с его помощью, что этот кусок кода добавлен Петей 10.05.2019? А оплачивать это время кто будет? Мартин?
Ещё:
Т.е. где-то кто-то уже получил нобелевскую премию за то, что исследовал и доказал, что использования команд в предикатных выражениях Если - это плохо? Нет, я не хочу что-то утверждать, просто мне кажется, что мне навязывают какую-то чушь под видом "это же очевидно ах вы не знаете мне вас жаль". Обсуждение "хороших практик" должно какими-то примерами из жизни сопровождаться, что ли? Потому что есть действительно простые вещи (вроде понятных имён переменных), а есть вот такие. Пример:
Процедура Хочу()
Если НЕ РеквизитСоответствует(Реквизит) Тогда
Сообщить("Нет");
Возврат;
КонецЕсли;
КонецПроцедуры
Процедура НеХочу()
Попытка
ЗапущуКаЯПроцедуруПоПересчётуНа100ЧасовСразуБезПроверок(Реквизит);
Исключение
Сообщить("Ничё не выйдет, реквизит не тот!
"Извините, что заставили вас ждать 100 часов, но Мартин сказал, что так правильнее писать код."
"С любовью, ваши программисты");
КонецПопытки;
КонецПроцедуры
ПоказатьСудя по тексту, первая процедура плохая, а вторая хорошая. Почему же у меня возникает смутное подозрение, что это не так?
В общем, читая, пиша (ничего более путного в словаре не нашёл), изучая и размахивая такими текстами нужно не забывать, для чего всё это делается. А то постоянно мучает чувство, что эти практики делаются ради делания практик.
Но, лично моё мнение, всё равно это никак не заменяет комментарии в коде.
Да, когда такие комментарии начинают наслаиваться друг на друга - это выглядит ужасно - но бывает это не так уж часто
Да, программисты ленятся писать такие комментарии, особенно когда многократно редактируют свой код - но это тоже не так уж важно - главное иметь хоть какую-то пометку - а там уже можно её раскручивать через историю
Да, использование репозитариев хранения истории изменений при этом никто не отменяет.
Да, размещение комментариев, по определённому стилю, позволяет потом лего автоматизированно анализировать такой код (по истории из репозитария это может быть намного сложнее)
И да, при выполнении сравнения объединения конфигураций (особенно при обновлении типовых) комментарии пометок доработок намного удобнее, чем анализ истории по хранилищу (но тут конечно можно возразить - что для этого как раз таки есть тройное сравнение, мерджи и мастер бранчи в GIT...)
Ну а Мартин он такой - это его стиль - жёстко всем навязывать своё мнение - ибо он уже авторитет (но не для всех - это надо тоже помнить). Поэтому именно так и нужно воспринимать его текст - "он требует" - а Вы просто внимательно относитесь к тому что там он требует и вырабатывайте свою концепцию - тут главное иметь именно свою (желательно общую для вашей текущей команды) концепцию работы - и ей придерживаться! Ну и критически к ней относиться - если заметите недостатки - значит пора её совершенствовать, но и тут тоже спешить не стоит.
Доказывает, но вопрос не в этом. Вопрос в том, что всё равно приходится работать с ним и комментарий про Петю довольно часто упрощает работу и экономит очень много времени.
Ещё пример - сравнение-объединение. Вываливается сто тысяч изменённых строк и сиди потом вычисляй, изменено это в новом релизе или изменено Васей. Каждый такой комментарий может экономить иногда часы. Но автор где-то слышал, что где-то есть какой-то гит, в котором вроде как можно посмотреть историю - значит снесём старый мир и сделаем тут город-сад, плевать на детали!
.
Я недавно открывал обработку переделанную из типовой, так вот там 50% кода было закомментировано. Просто было жесть пролистать кучу зеленого текста. И автор наверное тоже может возразить "это же не влияет на работу", "а вдруг понадобится". Но это потеря времени того, кто смотрит такой код. Я все зачистил.
Ещё пример, кода в обработке функции были разбросаны не выполнялся принцип "Зависимые функции". Очень не удобно прыгать было по незнакомому коду.
Это примеры из жизни с которыми все сталкиваются.
И вас никто не обязывает, это же не принципы. Это книга направляет вас, дает возможность задуматься, если вы никогда не задумывались о том, как вы пишите код.
Опять же есть принцип "Правила форматирования в группах". Т.е. никто вас не обязывает как то строго форматировать свой код, тут даже нет ни одного такого примера в книги. Хотите венгерской пользоваться пожалуйста, главное же не это. Главное понятные названия функций, сгруппированный код, а не разбросанный по модуль и т.д.
Так вот об этом и речь. Что есть ситуации, которые можно или нужно решать вот так или вот так. А не "венгерская нотация устарела, не используйте её", "комментарий про Петю мешает чувству прекрасного, удалить!".
Принцип "Зависимые функции" тоже далеко не всегда достижим. Я и сам всегда мечтаю расположить их так, чтобы было удобно и логично, но если в модуле несколько логических блоков и каждый или не каждый вызывает одни и те же, то уже никакие "зависимые функции" не получатся. Вопрос неплохо решается классами там, где есть полноценное ООП, но в 1С оно неполноценное, так что и решения этой проблемы тоже будут неполноценные. И человеку, верящему в практики, а не в ситуации, тоже, наверное, будет невыносимо на такое смотреть.
Тот же закомментированный код - если он точно устарел и использоваться больше не будет, то конечно надо удалить. А если это потуги, временные заглушки или источник вдохновения для переписывания - то я лично просто выношу их в #Область Старый_код. И не мешают, и всегда под рукой. И получается служение практик для решения ситуаций, а не "ненавижу зелёные буквы, Мартин сказал удалить!!!".
В этом кажется и беда 1С программистов, большенство из нас это программисты одиночки, работающие по одному человеку в компании или мелкими группами 2-3 сотрудника. И тут конечно не возникает потребности ни в чистом коде, не в общих правилах форматирования. Каждый сам за себя. Я лично в такой компании работаю и никто ничего менять не хочет. А принципы эти сформировали люди у которых несколько десятков программистов в проекте. Вы представьте, если сейчас человек 30 начнет пилить вашу конфигурацию и каждый со своим взглядом на форматирование, название переменных. Это же просто трешь будет.
По-моему, это больше Ваша беда - делать безапелляционные выводы из всего. Вы работаете в маленькой компании, где никто ничего меня не хочет - и вот уже "большинство" - это одиночки без потребностей в чистом коде.
Если это не навязываемые инструкции - тогда я не знаю, что это. Не знаю, были ли там примеры в книгах, был ли там основной посыл о том, что практики должны служить цели, а не цель должна быть - служить практикам. Но в данной статье ни примеров разных ситуаций, ни посыла нет. Есть список практик, которые мы все ДОЛЖНЫ выполнять. потому что пророк Мартина нам так сказал.
Вообще я тоже очень люблю практики. Почти со всеми, кроме парочки вышеперечисленных я полностью согласен. Но за 10 лет работы в сфере 1С-программирования я понял что ничего страшнее, чем слепое служение каким-то практикам (обычно новомодным и с крутыми английскими именами) нет. Плохие имена переменных, отсутствие комментариев, перепутанные функции - всё это локальные проблемы локального кода, которые вполне по силам победить даже одному программисту.
Но когда появляется культ служения практикам, обычно проще сразу сменить место работы. Когда вместо работы начинаются ежечасные выгрузки конфигурации в Git, когда программисты часами сидят возле белой доски и рисуют смайлики друг другу, когда на каждую строку кода надо создать тикет, а потом тикет на тикет на тикет, когда весь отдел бросает всю работу и садится писать супернавороченную канбан-доску с преферансом и поэтессами, а вместо выходных всех обязывают явиться на какой-нибудь тимбилдинг - можно смело забирать трудовую, тут уже если и станет всё нормально, то очень не скоро.
Именно поэтому эта статья больше вредна, чем полезна. Не потому, что в ней есть парочка недочётов, и не вопреки тому, что там куча полезной информации. А потому, что там основного нет - описания цели всего этого и последовательного убеждения людей, которые будут всему этому верить, в том, что все эти практики, они служат одной главной цели и применять-не применять должно решаться по ситуации, а не по вот этому евангелию.
Какое отношение подходы к работе имеют к правилам написания кода? Статья про оформление кода, а не про организацию работы команды разработчиков.
Вот что заметил больше всего "воинствующих атеистов" среди 1сников. Вместо того что бы взять вроде бы банальные и простые правила и работать они будут всем вокруг доказывать что в книжках которые они не читали всё не правильно и только их код предел совершенства, а написание кода через одно место называют "собственным стилем".
А кто то с этим разве спорит? По ситуации можно и венгерскую нотацию использовать, но писать весь код в таком стиле это жесть.
А цитату не приведёте, где я делал безапелляционные выводы о том, что книга плохая, рекомендации плохие? А то без цитат с вашими безапелляционными выводами и явно даже без прочтения того, что вы тут так оспариваете, больше похоже на базарный день. Целую сказку изобрели о том, как плохие одинэсники что-то всем вокруг доказывают, хотя сами ничего не читали, и только поклоняются своему коду. Вы бы для начала весь комментарий прочли, который у вас такие "наблюдения" вызвал.
Я говорил в каждом комментарии и повторю сейчас - книга и рекомендации не плохие и не хорошие, их применимость должна оцениваться в каждой конкретной ситуации. Плохим можно назвать разве что программиста, который слепо поклоняется чужим рекомендациям или напрочь их отвергает. Ну и комментаторов, которые лезут комментировать, не прочитав даже комментируемое ;)
В стандартах 1С то же кстати рекомендуется удалять закомментированный код из продуктива. Может они с Мартином в сговоре?
Разумеется. Затем все берёмся за руки и поём гимн жёлтой программе. Вы разве ещё нет? Тогда мы идём к вам :)
Вы знаете другой способ определить "диванного специалиста по всем вопросам" от действительно знающего и умеющего?
Ещё один ужасный стиль. В 99% случаев закомментированный код так и останется висеть балластом, совершенно бесполезным и отвлекающим внимание
И как - не умрёте вы от отвлечения внимания? Я говорю именно о временном комментировании на проекте, на котором идёт разработка. Если у меня есть новый код вместо старого - я его удаляю. Если я не знаю, какой из вариантов кода я буду использовать, я оставляю все варианты, пока не будет ясности.
Пройдёт год, и будете репу чесать над закомментированным кодом, вспоминая, для чего он был закомментирован. Если этот код будет читать другой программист, он ещё сильнее будет репу чесать. Суть-то в чём, любому программисту приходится читать (именно читать) много кода. И это чтение обычно не походит на чтение книги. Отдельные строки могут зачитываться и перечитываться вновь и вновь. Код буквально запутан. Нужно время, чтобы его "распутать". Чуть-чуть залип там, чуть-чуть здесь, а по итогу получились большие потери времени. Хорошо написанный код, в котором отличная декомпозиция, хорошие имена и нет никакого "мусора", просто пробегается глазами сверху вниз и сразу же понимается. Как статью в журнале прочитать. Плохой код нужно перечитывать вновь и вновь, бегать глазами вверх и вниз, крутить колёсико мыши, молотить по горячим клавишам, попутно пытаясь в голове выстроить логичную картинку.
Вот видите, уже самому тяжело копаться в собственном коде. А каково будет другим?..
(89)
Две буквы перед именем внутренней переменной упростили работу больше, чем все комментарии и понятные имена вместе взятые! И целый хоровод Мартинов, Майклов и прочих желающих может затребовать моей крови в Гаагском трибунале - это не изменит того факта, что очень простая венгерская манипуляция упростила мне работу. Иногда влажу в свой код годичной давности и вроде всё нравится, но коробит от того, что надо периодически подсматривать, переменная это или реквизит или ещё что-то. Сразу рука тянется дописать "пр".
Ужасный стиль. Не сегодня, так завтра в 1с наконец-то придёт рефакторинг. А в рефакторинге один из важнейших приёмов это выделение методов. Часть процедуры может быть выделена в отдельную функцию, тогда одни переменные процедуры могут стать параметрами функции, другие переменные станут уже переменными функции. Получится каша.
Другой момент. В современных IDE подсвечиваются поля классов отдельным цветом. До 1с и 1сников всё доходит с запозданием, но и подсветка переменных разного происхождения вот-вот появится. По-крайней мере в EDT до этого рукой подать. Когда это произойдёт, лишняя нотация станет совершенно бессмысленной
Вот когда это произойдёт, тогда мы и поговорим. А пока этого не произошло и эта нотация спасает
(84)
Я именно об этом и писал - о том, что многие просто любят заниматься теоретизацией и вешанием ярлыков исключительно потому, что кто-то написал об этом книжку. "Хорошие" практики становятся объектом культа, вместо того, чтобы использовать эти практики именно для решения задач здесь и сейчас.
в том-то и дело, что это не какая-то там теоретизация, а выстраданная с годами практика
Примеры приведите выстраданной годами практики, тогда и поговорим. Что-нибудь на тему "Как я удалил венгерскую нотацию с проекта и спас его" или "Как я пользуюсь секретным редактором кода 1С с подсветкой разного контекста переменных и постоянно вычищаю венгерскую нотацию". А пока не привели, могу только повторить то, что писал выше - ваши "выстрадывания" для меня - теоретизация, а использование венгерской нотации экономит мне секунды на каждой переменной и часы (а, может быть, уже и дни) в общей сложности.
И кстати, проверил только что в ВС Код - и там (сюрпрайз!) локальные переменные по цвету не отличаются от глобальных и параметров.
:)
"Мне плевать на всех, кодю как хочу"
Любой другой программист будет плеваться от вашей венгерской нотации, т.к. она ему совершенно непривычна, ибо никто в 1с её не использует. Код прежде всего пишется для людей. Венгерская нотация в 1с почти также ужасна, как и болезненная манера некоторых обгрызать имена переменных (стро, РасчТаб() и пр.). Есть всё-таки общепринятый codestyle, и надо ему придерживаться.
Настойчиво рекомендую прочитать книгу первоисточника. Автор статьи крайне неудачно повыдирал фразы, и ещё более неудачно подобрал примеры. В книге автор довольно подробно расписывает, что и для чего делается. Это нельзя передать в коротеньких комментариях.
Меня вообще поражает, почему best practices, общепринятые в "большом" программировании, напрочь отрицаются многими 1сниками.
[quote]практики делаются ради делания практик[/quote]
И зарабатывания на этом денег. Капитализм, сэр
Но не всем рецептам можно следовать необдуманно.
И тем более я бы на месте автора поостерегся явно волюнтаристских заявлений.
Венгерская нотация спасла не один проект.
А ее отсутствие наоборот, приводит даже в типовых конфигурациях к примеру к объявлению переменных с именем Объект и потом конечно же такая переменная пересечется с реквизитом метаданных.В принципе у каждого проекта (группы разработки) есть тимлид который первым делом должен продумать этот вопрос.
У 1С к примеру есть стандарты разработки - там есть указания по именованию функций
В любом случае эта книга копилка опыта ,а не руководство к бездумному подражанию
В-Внимательность.
Так я вроде нигде и не писал что вы сказали что она плохая.
Просто поинтересовался где можно вашу почитать, раз вы утверждаете что любой программист может написать свою.
И что я там увидеть должен? Что не так с методом создания объекта "ТаблицЗначений" ? Как по вашему он должен называться? Или что вы имеете ввиду?
Какой по вашему префикс нужен функции? Мне кажется никакой.
(29)
Даже плюсик поставл кто-то не вникая
(34)
Давайте это будет ваше домашнее задание ?
На принскрине все видно
Можно. Где-то в дебрях функции я вижу названия СтруктураПараметров и СтруктураТаблиц. Что из них было объявлено здесь, что - было передано, а что - вообще название реквизита формы? Или реквизита объекта? Или общего модуля? Можно потратить какое-то время на выяснение. Это время даже не будет очень большим - для одного названия. Только я так и не понял - в чём проблема назвать локальную переменную прСтруктураПараметров? Это какие-то религиозные убеждения? Или политические взгляды?
Программист с опытом приходит к этому сам. Разве что пару практик, которые он упустил, сможет почерпнуть. Если не приходит - то боржоми тоже не поможет. А неопытному программисту это все филькина грамота. У него другие проблемы - он бьется чтобы программа хоть как-то заработала. Другими словами, "чистый код" - это результат эволюции программиста, который не вдолбишь. Туда либо эволюционируют, либо нет.
Там все классно написано. И когда читаешь - думаешь, ну да. Все правильно. Именно так и надо делать.
Потому что большинство вещей там на уровне - "не делайте плохо, делайте хорошо".
Проблема в том, что невозможно прочитать "делай хорошо" и начать "делать хорошо". Ты или уже дорос до того, чтобы "делать хорошо" или пока еще нет.
Ну не сможет неопытный программист прочитав стопицот таких книг начать хорошо писать код. Так не работает.
Так надо значит брать и делать. В чём проблема? Написано что надо называть функции определённым образом, в чём проблема называть их? Если есть рекомендация по оформлению блоков кода то в чём сложность их оформить по рекомендации?
(45)
Именно читая и применяя на практике "неопытный" станет "опытным".
Прочитав "избегайте ложных ассоциаций" - обретет кристальную ясность мышления.
Давать хорошие имена переменным/методам - "ой, а чего это я плохие раньше давал, теперь буду давать хорошие"
"Не дублировать код" - "и действительно, зачем я раньше дублировал..."
Форматировал код абы как, прочитал что это почему-то плохо и начал форматировать хорошо.
"Функции должны быть без побочных эффектов, побочные эффекты это плохо" - "вау, надо же, а ведь правда - буду писать функции без побочных эффектов".
Ну, ок.
Вас я услышал, свое мнение высказал.
"внезапно" нет. Но он сможет при написании сразу руководствоваться этой рекомендацией. И это куда продуктивнее чем с начало писать портянки, а спустя год узнать что оказывается можно и нужно работать по другому. Если у вас это не получается и требуется "вдалбливать" дело в вас, а не в книге.
Сразу нет. Но в какой то момент начнёт понимать о чём речь.
У вас эта рекомендация вызывает сложности? В том же Python отступы сразу приучают писать к правильному форматированию и рекомендации PEP то же не просто так. И тысячи людей выбирают его как первый язык, учат и сложностей у них это не вызывает. Может конечно дело в 1сниках, которые бывает что по 7 лет работают программистами и не в курсе что на ИТС есть соглашение по написанию кода.
Да как минимум будет знать что есть такая рекомендация. Один раз запнётся об сразу закрепит теорию практикой, другое дело когда пишут такие функции и считают это нормальным подходом.
Пусть он сразу не поймёт 100% рекомендаций из книги, но если поймёт и начнёт применять на первых порах 10-20-30% то только выиграет от этого.
Забыл как этот эффект называется. Это когда мы читаем что то понятное и очевидное нам всё понятно. Но до прочтения для нас это знанием не является и мы этим не пользуемся как навыком.
Так же бывает что мы читаем книгу, вроде всё понятно, очевидно и банально. Но после прочтения можем воспроизвести в лучшем случае 10% рекомендаций из книги. Хотя все они казались простыми и очевидными.
Сердце хорошего кода - в грамотной алгоритмизации и структуризации, выборе эффективных абстракций и их взаимосвязей. По книжкам этому не научишься. А когда с этим начнет получаться, то большинство признаков хорошего кода прикладывается автоматически, как следствие.
не прикладывается. Почему то люди которые писали говнокод и не знали про "чистый код", "стандарты разработки" и прочие занимательные книги и спустя 7 лет продолжают писать точно такой же говнокод, только начинают это делать чуть лучше, быстрее, меньше ошибок, быстрее отладка, лучше разбираться в платформе, фреимворке и тд. Но в целом насмотрелся я на код людей с 5+ годами кодинга и почему то он как был говнокодом так и остался, а по вашей логике он должен был стать лучше ну 5 лет то не малый срок. Лучше он станет когда начнут работать над этим. И чем раньше тем лучше.
Во вторых не стоит изобретать велосипед если уже всё придумано за нас.
Незнание даёт?
Не-а. По моей логике этим людям ничего не поможет. Если человек не способен учиться даже на своих ошибках, то учиться на чужих и подавно не способен.
Мало понять как не надо делать, надо понять как делать правильно. И неизвестно сколько надо сделать "итераций" что бы выработать правильный подход. Можно одну, а можно сто итераций и соответственно сто ошибок.
Но можно ускорится и прочитать как надо и как не надо делать от тех кто этот путь уже прошёл.
Бест практисес ессно никто не отменял, но это немного другое.
Все упирается именно в то, насколько эффективно человек учится на своих ошибках. Насколько он самокритичен. Насколько склонен к анализу и совершенствованию. И так далее. Остальное вторично. Просто так получается, что такие люди еще и внимательно оглядываются по сторонам в поисках ответов. Но главное - это умение и желание анализировать и формулировать правильные вопросы.
Пренебрегать опытом сотен и тысяч людей не дальновидно.
Всё же не стоит забывать мантру программиста: "Я не буду изобретать велосипед, я возьму готовый и согну под себя", произносить в слух каждый раз когда берёшься за новую задачу.
Мантра тоже имеет оговорки. Иногда эффективнее собрать самокат самому, чем адаптировать под эту задачу готовый самолет.
Никакой проблемы в передаче навыков по написанию понятно и структурированного кода не вижу кроме "не желания" получать их либо при определённых заболеваниях, но при таких заболеваниях уже точно не до программирования.
Книги и придуманы затем чтобы учиться и передавать знания.
Это вам не интернеты )
Хотя бы потому что там есть технические редакторы которые смотрят толковая книга или нет.
В мое время считалось что средние знания по предмету можно только после 3 прочитанных книг иметь
А книги были толстые, не то что сейчас
Не вспоминайте только Руководство разработчика ) им убить можно
Должны были быть, но мусора тоже выпустили немало. Лично держал в руках книгу по Adobe Photoshop 4, где было сказано, что новое в версии - это команда "Add to Zip" в окошках "Открыть/Сохранить" (автор поставил ZipFolders и не разобрался), в книге по Corel Draw "check" вместо "установите флажок" перевели как "проверьте". В книжке по Visual Basic автор доказывал, что раз кнопка размещена на форме, то она наследует форму (или наоборот) - грубая ошибка: путать наследование и включение.
В книжке на ДВЕ ТЫСЯЧИ страниц всего-то около сотни кб текста.
(45)
Как ты дорастёшь если ничего не читаешь и перенимаешь чужой опыт описанный в книгах? Если не учится делать хорошо то так и будешь писать плохо. Если не перенимать чужой опыт и хорошие практики то так ничему не научишься.
Честно говоря я не понимаю на сколько надо быть тугим человеком что не смог осилить элементарные рекомендации из книги и начать их тут же применять. Вроде не квантмех и не мат анализ. Стоит ли тогда вообще заниматься программированием? Если сложно понять написанное в книге и попробовать применить. Я прочитал чистый код и начал что то применять, прочитал стандарты 1с и начал применять их. Написано вроде понятно и доступно.
Что вам из приведённых рекомендаций не понятно что вам это нужно вдалбливать?
Всё прекрасно работает.
И все с этим живут, довольны считают это прогрессом. А мы отстаем лет на 10-15 не только технически, но и методологически. И все в штыки воспринимаем.
Я же написал последней строчкой "книга заставляет задуматься", а все сразу восприняли, что их заставляют, да кто я такой и даже Мартин чтобы заставлять...
***
Специально нагуглил на хабре. Уже такое выкладывали. Почитал комментарии, негатива нет вобще. Многие пишут, что читали. Обсуждают какие то пункты. Пусть с чем то не согласны, но вот чтобы в целом сказать это фуфло нет ... Что не так с нами 1С-никами?
Вы как то с уважаемым TODD22 скачете мыслями по прериям и клавиатура у вас обгоняет разум.
А это нехорошо.
Вы внимательно почитайте здесь комментарии, примерно так же внимательно как на хабре хотя бы.
И поймете что здесь то же самое и написали.
Книга хорошая, но безумно следовать ее рекомендациям не стОит (или не стоИт, это уже по желанию)
Так и программировании желательно тоже такие проекты делать , т.е. заранее подумать над переменными , функциями , алгоритмами и т.д. Как лучше сделать ( сначала для общей задачи , а дальше уже для каждой функции по отдельности)
И когда у тебя в голове порядок , то в коде будет порядок ,
И как по мне , если нет полного понимания , хоть соблюдай все рекомендации , хоть не соблюдай порядка в коде не будет
Как в строительстве люди с начало учатся делать кладку по уровню, выполнять правильно штукатурные работы и тд и только потом берутся за работу.
А не берут кирпичи, вертят в руках в надежде что рано или поздно овладеют профессией строителя.
Имея проект, схемы, макеты и хорошее планирование кривыми руками ровный дом не построишь.
Ибо работа с проектом и сам факт необходимости ТЗ, а также открываемые им перспективы развития может оценить только человек, на
А тут допустим клиент просит вас написать ему небольшую обработку или отчет он может сказать это устно или оформить письменно что-то вроде ТЗ но не совсем например так :
Вроде бы простая задача . Но все равно , прежде чем бежать кодить , надо задуматься а как надо реализовать эту задачу , Сейчас клиент хочет что бы заполнялось по одной группе , а завтра захочет уже по нескольким + отдельные контрагенты. На каком этапе делать отбор контрагентов и т.д.
Стоит ли оно того, если лично мне и так норм( не мое мнение вопрос социального характера :) )?
О-о, собственный расширитель языка? Круто!
А мне максимум попадался "КирпичныйЗавод.ert". Плюс один хитрец увёл код за правый край экрана, чтобы его не было видно. Но забыл про линейку прокрутки :))).
В других языках ведь существует.
Системы контроля исходного кода отлично запоминают, кто и когда внес то или иное исправление. Нет необходимости загрязнять код подобными ссылками.
Буквально недавно обновлял большую очень сильно изменённую конфигурацию, и поэтому вернулся опять сюда, чтобы ещё раз пройтись именно по этому куску.
Возможно, где-то и существует способ работать с системами контроля версий при обновлении (или, как вариант, просто нет других возможностей), но в 1С при обновлении я вижу два окна - то, что было и то, что будет. Соответственно, если я обновляю конфигурацию на новую версию, я имею дело сразу с тремя версиями кода - то, что было в типовой, то, что есть сейчас и то, что будет в новом релизе. А теперь представим две ситуации.
В типовой:
Сумма = 0;
Разность = 3;
Число = 2;В новой версии:
Сумма = 1;
Разность = 3;
Число = 3;Теперь обновим текущий кусок кода версии 1:
// Вася
Сумма = 0;
Разность = 3;
Курс = 5;
// ВасяКогда я вижу этот кусок, я понимаю, что это - доработка, нужно только проверить, не конфликтует ли она с новой версией. Конфликт решается быстро:
// Вася
Сумма = 1;
Разность = 3;
Курс = 5;
// ВасяА теперь представим, что коммента про Васю не было. Т.е.
Сумма = 0;
Разность = 3;
Курс = 5;Что дальше? Дальше я его либо просто удаляю (предполагая, что это - старый типовой код, который обновился) и получаю на выходе запоротую конфигурацию. Либо включаю сравнение-объединение ещё и доработанной со старой типовой. И тогда мне нужно делать сразу две работы - проверять изменения новой по отношению к доработанной, а потом ещё и каждое изменение сверять со старой типовой! И всё это просто потому, что где-то в какой-то книжке написано, что именные комментарии нарушают икебану) Отличное решение!
В своей практике перед обновлением я сразу стараюсь узнать, работала ли предыдущая команда на результат, максимально упрощая себе жизнь и оставляя комменты в каждом изменённом куске, или же они самоудовлетворялись на культы из книжек. Если второе - сразу умножаю бюджет на 2.5.
Если КакоеТо Условие Тогда
// много
// всякой
// всячины
КонецЕсли;можно писать
Если НЕ КакоеТо Условие Тогда
Продолжить; // это если в цикле
КонецЕсли;
// много
// всякой
// всячиныили
Если НЕ КакоеТо Условие Тогда
Возврат; // это если в процедуре, в в функции - Возврат что-то там
КонецЕсли;
// много
// всякой
// всячиныИ лучше, когда в условии первая ветка (после Тогда) короче второй (после Иначе). Если короче вторая, то поменять их местами, заменив условие на противоположное, скажем > на <=, = на <> и т.д. В крайнем случае возьмите всё условие в скобки и добавьте спереди НЕ
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1060651
Создание 16.05.19 08:50
Обновление 16.05.19 08:50
Просмотры 28869
Загрузки 0
Рейтинг
49
Комментарии 108
Код открыт Да
Рубрики Математика и алгоритмы
Кому Разработчик
Тип файла Нет файла
Платформа Не имеет значения
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
