Эта книга является библией для многих программистов, но вот в среде программистов 1С, к сожалению, не очень распространено чтение подобной фундаментальной литературы.
Книга более 400 страниц и так много порой лениво читать, да и времени всегда не хватает. По этому я решил выделить в виде цитирования по разделам самые важные моменты. А также снабдил текст своими примерами кода.
В этой статье я привожу выдержки (цитаты) из книги "Чистый код" Роберта Мартина (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.2024
Системы контроля исходного кода отлично запоминают, кто и когда внес то или иное исправление. Нет необходимости загрязнять код подобными ссылками.
Закомментированный код
В программировании редко встречаются привычки более отвратительные, чем закрытие комментариями неиспользуемого кода. Никогда не делайте этого!
Нелокальная информация
Если вы должны написать комментарий, проследите за тем, чтобы он описывал находящийся поблизости код. Не излагайте информацию системного уровня в контексте локального комментария.
Заголовки функций
Короткие функции не нуждаются в долгих описаниях. Хорошо выбранное имя компактной функции, которая выполняет одну операцию, обычно лучше заголовка с комментарием.
УдалитьВременныйКаталог(Знач ПутьККаталогу);
Форматирование
Мы хотим, чтобы читатель, заглянувший «под капот» программы, был поражен увиденным — нашей аккуратностью, логичностью и вниманием к мелочам. Мы хотим, чтобы на него произвела впечатление стройность кода. Мы хотим, чтобы он уважительно поднял брови при просмотре модулей. Мы хотим, чтобы наша работа выглядела профессионально. Если вместо этого читатель видит беспорядочную массу кода, словно написанного шайкой пьяных матросов, то он заключит, что такое же неуважение к мелочам проникло и во все остальные аспекты проекта.
Вы должны позаботиться о том, чтобы ваш код был хорошо отформатирован. Выберите набор простых правил, определяющих формат кода, и последовательно применяйте их в своей работе. Если вы работаете в составе группы, то группа должна выработать согласованный набор правил форматирования, соблюдаемых всеми участниками. Также полезно иметь средства автоматизации, которые применяют правила форматирования за вас.
Вертикальное форматирование
Типичная длина кода составляет 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С. Но лично мне они нравятся больше. Например, принцип "Зависимые функции" позволяет не раскидывать логически связанные функции по модулям, избавляет от долгих переходов. В книжке автор приводит пример, когда регистрировал свои действия при правке кода и с ужасом обнаружил, что больше всего времени тратимся на скроллинг мышкой. Да и многие другие моменты очень помогают ориентироваться в хорошо написанном коде. В передаче кучи параметров в функции я стал по другому относится. Не возвращать Неопределенно тоже заставляет задуматься.
В общем, статья к размышлению.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
в среде программистов принято рассказывать как они вошли в профессию после 2-х недельных курсов и сразу
создали нетлентки.
«Если честно, то ко многим принципам описанным в этой заметки я пришел сам, за более чем десятилетий стаж работы программистом.» — аналогичный путь!
Автор, тут пример неудачный.
Показать
Если ты передаешь параметры функции в одной структуре, ты все равно ожидаешь все параметры, которые содержатся в структуре.
В данном случае, тебе нужно лезть в функцию, чтобы посмотреть какие же параметры должны быть в структуре.
Что же тут хорошего?
У Мартина, видимо, речь идет о том, чтобы уменьшить количество параметров, которые используются в функции.
И если функция использует слишком много параметров — разбивай ее на несколько функций, а не собери все параметры в одну коллекцию и подпихни их через нее.
мде…
Функция ПроизвестиРасчет()
Попытка
Исключение
Сообщить(«»)
КонецПопытки
КонецФункции
Показать
И это ещё без учёта транзакций!
У нас своя библия )
80% фикси клали на эти правила — «Нам за это не платят». В корпоративных информационных системах треш, угар и содомия.
(4) Поддерживаю, безудержная обработка ошибок приводит к «В этой транзакции уже происходили ошибки» и ищи теперь где что сломалось.
(4) тут просто тоже неудачный пример.
В суть в другом:
Если нужно сделать несколько действий, результаты которых нужно проверять, то лучше все действия сделать в одной попытке, как то так.
То есть это пример расходится со стандартом, а не рекомендации из книги
Аргументы-флаги
плохо
УчитыватьСкидки= Истина;
ВыполнитьРасчет(УчитыватьСкидки);
хорошо
Если УчитыватьСкидки Тогда
ВыполнитьРасчетСУчетомСкидок();
Иначе
ВыполнитьРасчетБезУчетаСкидок();
КонецЕсли;
При такой конструкции код только усложнится для понимания. В двух процедурах будет выполнятся одинаковый код «Расчет», его куда деть? Еще одну процедуру Расчет() делать?
(5)
Неужели франчи 100% выполняют эти правила и им доплачивают?
Кладут обычно не потому что не доплачивают, а потому что не умеют.
(8) По идее да. Тут как бы палка о двух концах, либо более понятно, но многословно, либо более запутано.
Просто если переменная переключатель где то далеко, то придется её искать.
(5) Тут каждый для себя лично решает, как он программирует.
Про примеры да они не уклюжие. Не прет фантазия, точнее не всегда получается идеальную ситуацию придумать под принцип. Думаю может разместить на github чтобы , могли примеры предлагать.
Будет ли это интересно кому то?
(9) Не умеют, не хотят. Никто не контролирует. Франчи тоже жгут, но я фикси и копаюсь в продуктах жизнидеятельности других фикси.
(13)
это лишь доказывает убогость хранилища 1с
(13) Книга о том, что хорошо структурированный код помогает, а плохо структурированный мешает
.
Я недавно открывал обработку переделанную из типовой, так вот там 50% кода было закомментировано. Просто было жесть пролистать кучу зеленого текста. И автор наверное тоже может возразить «это же не влияет на работу», «а вдруг понадобится». Но это потеря времени того, кто смотрит такой код. Я все зачистил.
Ещё пример, кода в обработке функции были разбросаны не выполнялся принцип «Зависимые функции». Очень не удобно прыгать было по незнакомому коду.
Это примеры из жизни с которыми все сталкиваются.
И вас никто не обязывает, это же не принципы. Это книга направляет вас, дает возможность задуматься, если вы никогда не задумывались о том, как вы пишите код.
Опять же есть принцип «Правила форматирования в группах». Т.е. никто вас не обязывает как то строго форматировать свой код, тут даже нет ни одного такого примера в книги. Хотите венгерской пользоваться пожалуйста, главное же не это. Главное понятные названия функций, сгруппированный код, а не разбросанный по модуль и т.д.
(14)ну EDT к примеру уже и современный GIT поддерживает — а далее — можно использовать общие инструменты по ревью кода.
Но, лично моё мнение, всё равно это никак не заменяет комментарии в коде.
Да, когда такие комментарии начинают наслаиваться друг на друга — это выглядит ужасно — но бывает это не так уж часто
Да, программисты ленятся писать такие комментарии, особенно когда многократно редактируют свой код — но это тоже не так уж важно — главное иметь хоть какую-то пометку — а там уже можно её раскручивать через историю
Да, использование репозитариев хранения истории изменений при этом никто не отменяет.
Да, размещение комментариев, по определённому стилю, позволяет потом лего автоматизированно анализировать такой код (по истории из репозитария это может быть намного сложнее)
И да, при выполнении сравнения объединения конфигураций (особенно при обновлении типовых) комментарии пометок доработок намного удобнее, чем анализ истории по хранилищу (но тут конечно можно возразить — что для этого как раз таки есть тройное сравнение, мерджи и мастер бранчи в GIT…)
Ну а Мартин он такой — это его стиль — жёстко всем навязывать своё мнение — ибо он уже авторитет (но не для всех — это надо тоже помнить). Поэтому именно так и нужно воспринимать его текст — «он требует» — а Вы просто внимательно относитесь к тому что там он требует и вырабатывайте свою концепцию — тут главное иметь именно свою (желательно общую для вашей текущей команды) концепцию работы — и ей придерживаться! Ну и критически к ней относиться — если заметите недостатки — значит пора её совершенствовать, но и тут тоже спешить не стоит.
(3) И нужно помнить о клиент-серверном взаимодействии. Если серверная функции вызываются с клиента, то нужно учитывать количество вызовов сервера, объем передаваемых данных.
(3)Сейчас в 1С есть определённый стиль формирования комментариев для функций и их аргументов — в т.ч. там есть правила для описания комментария для структурных аргументов — тогда они показываются в подсказке к функции (в EDT). Но на чтении листинга текста да — всё равно скажется не очень хорошо (жаль в IDE нет особого режима показа текста — специально для чтения/анализа — когда всякие такие подсказки сразу отображаются в тексте (что и как должно отображаться — должно быстро настраиваться) — тогда можно было бы рядом с вызовом функции показывать описание параметров её структурного аргумента (а ещё и вычисленные к вызову функции значения — если их можно вычислить при компилировании, иначе — имена источников этих значений)
Мне передача аргументов через структуры очень нравится. Наиболее важные преимущества тут кстати ещё и в:
1. Нет строго порядка аргументов — не нужно задумывать об этом при вызове функций, особенно когда позже к функции добавляются новые аргументы
2. Относительно легко решаются вопросы с необязательными аргументами и их значениями
3. А главное — такие структуры аргументов могут передаваться через кучу вложенных вызовов функций — и бывает так что нужно расширить аргументы какой-то вложенной функции — так вот со структурой это делается очень легко — а без неё — придётся модифицировать все промежуточные функции.
4. Если Вы добавили к типовой функции новые аргументы, а потом в новом типовом релизе к ней добавились новые типовые аргументы — то в случае со структурной — проблемы крайне маловероятны — а вот без неё — проблем может быть очень много — причём трудно выявляемых при обновлении
5. Структура аргументов легко вручную сериализуется (в случае необходимости, например, для передачи между контекстами — там где типовая неявная сериализация не работает).
Единственное о чём тут надо помнить — это то, что стуркутры — это динамические объекты — каждый раз создавая структуры — вы создаёте новый экземпляр — и он не будет равен другому экземпляру структуру но с такими же элементами. Причём даже как ключи, скажем «Соответствия» эти структуры будут различны (хотя в сериализованном в строку виде — могут быть идентичны)
Наиболее существенно это для функций из модулей повторного использования.
Лично в таких случаях — либо передаю в такие функции — структуры, уже сериализованные в строку
Либо создаю такие структуры через специальную функцию из модуля повторного использования — она принимает исходные аргументы и возвращает кешируемую, им соответствующую, структуру.
(14)
Доказывает, но вопрос не в этом. Вопрос в том, что всё равно приходится работать с ним и комментарий про Петю довольно часто упрощает работу и экономит очень много времени.
Ещё пример — сравнение-объединение. Вываливается сто тысяч изменённых строк и сиди потом вычисляй, изменено это в новом релизе или изменено Васей. Каждый такой комментарий может экономить иногда часы. Но автор где-то слышал, что где-то есть какой-то гит, в котором вроде как можно посмотреть историю — значит снесём старый мир и сделаем тут город-сад, плевать на детали!
(15)
Так вот об этом и речь. Что есть ситуации, которые можно или нужно решать вот так или вот так. А не «венгерская нотация устарела, не используйте её», «комментарий про Петю мешает чувству прекрасного, удалить!».
Принцип «Зависимые функции» тоже далеко не всегда достижим. Я и сам всегда мечтаю расположить их так, чтобы было удобно и логично, но если в модуле несколько логических блоков и каждый или не каждый вызывает одни и те же, то уже никакие «зависимые функции» не получатся. Вопрос неплохо решается классами там, где есть полноценное ООП, но в 1С оно неполноценное, так что и решения этой проблемы тоже будут неполноценные. И человеку, верящему в практики, а не в ситуации, тоже, наверное, будет невыносимо на такое смотреть.
Тот же закомментированный код — если он точно устарел и использоваться больше не будет, то конечно надо удалить. А если это потуги, временные заглушки или источник вдохновения для переписывания — то я лично просто выношу их в #Область Старый_код. И не мешают, и всегда под рукой. И получается служение практик для решения ситуаций, а не «ненавижу зелёные буквы, Мартин сказал удалить!!!».
Каждый программист с N летним опытом работы может издать книгу рецептов.
Но не всем рецептам можно следовать необдуманно.
И тем более я бы на месте автора поостерегся явно волюнтаристских заявлений.
Венгерская нотация спасла не один проект.
А ее отсутствие наоборот, приводит даже в типовых конфигурациях к примеру к объявлению переменных с именем Объект и потом конечно же такая переменная пересечется с реквизитом метаданных.В принципе у каждого проекта (группы разработки) есть тимлид который первым делом должен продумать этот вопрос.
У 1С к примеру есть стандарты разработки — там есть указания по именованию функций
В любом случае эта книга копилка опыта ,а не руководство к бездумному подражанию
Я уже как-то высказывал мнение в похожей теме, что это все фигня.
Программист с опытом приходит к этому сам. Разве что пару практик, которые он упустил, сможет почерпнуть. Если не приходит — то боржоми тоже не поможет. А неопытному программисту это все филькина грамота. У него другие проблемы — он бьется чтобы программа хоть как-то заработала. Другими словами, «чистый код» — это результат эволюции программиста, который не вдолбишь. Туда либо эволюционируют, либо нет.
И через 5 мин нашел в типовой и актуальной бухгалтерии подтверждение своих слов )
(20) так в том то и дело это Принципы, а не инструкция. Просто если ты читаешь книгу там плюсом идет куча описаний, жизненных ситуаций и т.д. А выдержки в статье вы почему то сразу все восприняли, как инструкция, которую вам навязывают.
В этом кажется и беда 1С программистов, большенство из нас это программисты одиночки, работающие по одному человеку в компании или мелкими группами 2-3 сотрудника. И тут конечно не возникает потребности ни в чистом коде, не в общих правилах форматирования. Каждый сам за себя. Я лично в такой компании работаю и никто ничего менять не хочет. А принципы эти сформировали люди у которых несколько десятков программистов в проекте. Вы представьте, если сейчас человек 30 начнет пилить вашу конфигурацию и каждый со своим взглядом на форматирование, название переменных. Это же просто трешь будет.
(24)
По-моему, это больше Ваша беда — делать безапелляционные выводы из всего. Вы работаете в маленькой компании, где никто ничего меня не хочет — и вот уже «большинство» — это одиночки без потребностей в чистом коде.
Если это не навязываемые инструкции — тогда я не знаю, что это. Не знаю, были ли там примеры в книгах, был ли там основной посыл о том, что практики должны служить цели, а не цель должна быть — служить практикам. Но в данной статье ни примеров разных ситуаций, ни посыла нет. Есть список практик, которые мы все ДОЛЖНЫ выполнять. потому что пророк Мартина нам так сказал.
Вообще я тоже очень люблю практики. Почти со всеми, кроме парочки вышеперечисленных я полностью согласен. Но за 10 лет работы в сфере 1С-программирования я понял что ничего страшнее, чем слепое служение каким-то практикам (обычно новомодным и с крутыми английскими именами) нет. Плохие имена переменных, отсутствие комментариев, перепутанные функции — всё это локальные проблемы локального кода, которые вполне по силам победить даже одному программисту.
Но когда появляется культ служения практикам, обычно проще сразу сменить место работы. Когда вместо работы начинаются ежечасные выгрузки конфигурации в Git, когда программисты часами сидят возле белой доски и рисуют смайлики друг другу, когда на каждую строку кода надо создать тикет, а потом тикет на тикет на тикет, когда весь отдел бросает всю работу и садится писать супернавороченную канбан-доску с преферансом и поэтессами, а вместо выходных всех обязывают явиться на какой-нибудь тимбилдинг — можно смело забирать трудовую, тут уже если и станет всё нормально, то очень не скоро.
Именно поэтому эта статья больше вредна, чем полезна. Не потому, что в ней есть парочка недочётов, и не вопреки тому, что там куча полезной информации. А потому, что там основного нет — описания цели всего этого и последовательного убеждения людей, которые будут всему этому верить, в том, что все эти практики, они служат одной главной цели и применять-не применять должно решаться по ситуации, а не по вот этому евангелию.
(21)
А если без голословных утверждений сколько спасла или сколько погубила есть статистика?
(21)
Без венгерской нотации нельзя придумать название переменной?
(25)
Какое отношение подходы к работе имеют к правилам написания кода? Статья про оформление кода, а не про организацию работы команды разработчиков.
Вот что заметил больше всего «воинствующих атеистов» среди 1сников. Вместо того что бы взять вроде бы банальные и простые правила и работать они будут всем вокруг доказывать что в книжках которые они не читали всё не правильно и только их код предел совершенства, а написание кода через одно место называют «собственным стилем».
А кто то с этим разве спорит? По ситуации можно и венгерскую нотацию использовать, но писать весь код в таком стиле это жесть.
(25)
Вы то же делаете безапелляционные выводы что книга плохая, рекомендации плохие, венгерская нотация хорошо.
(21)
Где можно вашу почитать?
(20)
В стандартах 1С то же кстати рекомендуется удалять закомментированный код из продуктива. Может они с Мартином в сговоре?
(26)
(30)
В-Внимательность.
Нигде я не сказал что книга плохая. Наоборот.
Про именование переменных — чуть ниже опустите взгляд и увидите.
Если бы у функций был префикс такого бы не произошло.
(22) Т.е. опытному не стоит читать книги он и так лучше знает, а новичку тоже не стоит ведь скоро он станет опытным и тоже все будет знать. Отличная логика.
(32)
В-Внимательность.
Так я вроде нигде и не писал что вы сказали что она плохая.
Просто поинтересовался где можно вашу почитать, раз вы утверждаете что любой программист может написать свою.
И что я там увидеть должен? Что не так с методом создания объекта «ТаблицЗначений» ? Как по вашему он должен называться? Или что вы имеете ввиду?
Какой по вашему префикс нужен функции? Мне кажется никакой.
(34)В-Внимательность(2)
(29)
Даже плюсик поставл кто-то не вникая
(34)
Давайте это будет ваше домашнее задание ?
На принскрине все видно
(35)
Если не можете внятно объяснить то давайте без «давайте».
Вы знаете сейчас во многих средах разработки встроены средства проверки форматирования кода, например ESLint в JavaScript проектах. Сразу из коробки и постоянно выдает предупреждения. А можно настроить проект так, что он не будет собираться пока будут оставаться ошибки форматирования.
И все с этим живут, довольны считают это прогрессом. А мы отстаем лет на 10-15 не только технически, но и методологически. И все в штыки воспринимаем.
Я же написал последней строчкой «книга заставляет задуматься», а все сразу восприняли, что их заставляют, да кто я такой и даже Мартин чтобы заставлять…
***
Специально нагуглил на хабре. Уже такое выкладывали. Почитал комментарии, негатива нет вобще. Многие пишут, что читали. Обсуждают какие то пункты. Пусть с чем то не согласны, но вот чтобы в целом сказать это фуфло нет … Что не так с нами 1С-никами?
(36)
Что то не так…..
(36)Никто и не сказал что фуфло.
Вы как то с уважаемым TODD22 скачете мыслями по прериям и клавиатура у вас обгоняет разум.
А это нехорошо.
Вы внимательно почитайте здесь комментарии, примерно так же внимательно как на хабре хотя бы.
И поймете что здесь то же самое и написали.
Книга хорошая, но безумно следовать ее рекомендациям не стОит (или не стоИт, это уже по желанию)
(39)
и бездумно тоже….
(40)безумно и бездумно в данном контексте это синонимы
пишется вместе
Почему даже не спрашивайте
(41)исправил правило помню но когда пишу машинально ставлю пробел.
(33) Т.е. внезапно оказалось, что все на свете книги — они про «чистый код». Отличное обобщение.
(43)
Так автор вроде обсуждает книги про «чистый код», а не все на свете. Отличная попытка подмены понятия.
(44) Вот и я об этом. Книги по «чистому коду» — да, по большей части бесполезны.
Там все классно написано. И когда читаешь — думаешь, ну да. Все правильно. Именно так и надо делать.
Потому что большинство вещей там на уровне — «не делайте плохо, делайте хорошо».
Проблема в том, что невозможно прочитать «делай хорошо» и начать «делать хорошо». Ты или уже дорос до того, чтобы «делать хорошо» или пока еще нет.
Ну не сможет неопытный программист прочитав стопицот таких книг начать хорошо писать код. Так не работает.
(22)
(45)
Как ты дорастёшь если ничего не читаешь и перенимаешь чужой опыт описанный в книгах? Если не учится делать хорошо то так и будешь писать плохо. Если не перенимать чужой опыт и хорошие практики то так ничему не научишься.
Честно говоря я не понимаю на сколько надо быть тугим человеком что не смог осилить элементарные рекомендации из книги и начать их тут же применять. Вроде не квантмех и не мат анализ. Стоит ли тогда вообще заниматься программированием? Если сложно понять написанное в книге и попробовать применить. Я прочитал чистый код и начал что то применять, прочитал стандарты 1с и начал применять их. Написано вроде понятно и доступно.
Что вам из приведённых рекомендаций не понятно что вам это нужно вдалбливать?
Всё прекрасно работает.
(45)
Так надо значит брать и делать. В чём проблема? Написано что надо называть функции определённым образом, в чём проблема называть их? Если есть рекомендация по оформлению блоков кода то в чём сложность их оформить по рекомендации?
(45)
Именно читая и применяя на практике «неопытный» станет «опытным».
(45)Вот тут все не так.
Книги и придуманы затем чтобы учиться и передавать знания.
Это вам не интернеты )
Хотя бы потому что там есть технические редакторы которые смотрят толковая книга или нет.
В мое время считалось что средние знания по предмету можно только после 3 прочитанных книг иметь
А книги были толстые, не то что сейчас
Не вспоминайте только Руководство разработчика ) им убить можно
(47) Т.е. ты считаешь, что прочитав совет «пишите компактные функции», программист скажет «ой, а чего это я» и внезапно сможет грамотно структурировать код.
Прочитав «избегайте ложных ассоциаций» — обретет кристальную ясность мышления.
Давать хорошие имена переменным/методам — «ой, а чего это я плохие раньше давал, теперь буду давать хорошие»
«Не дублировать код» — «и действительно, зачем я раньше дублировал…»
Форматировал код абы как, прочитал что это почему-то плохо и начал форматировать хорошо.
«Функции должны быть без побочных эффектов, побочные эффекты это плохо» — «вау, надо же, а ведь правда — буду писать функции без побочных эффектов».
Ну, ок.
Вас я услышал, свое мнение высказал.
(49)
«внезапно» нет. Но он сможет при написании сразу руководствоваться этой рекомендацией. И это куда продуктивнее чем с начало писать портянки, а спустя год узнать что оказывается можно и нужно работать по другому. Если у вас это не получается и требуется «вдалбливать» дело в вас, а не в книге.
Сразу нет. Но в какой то момент начнёт понимать о чём речь.
У вас эта рекомендация вызывает сложности? В том же Python отступы сразу приучают писать к правильному форматированию и рекомендации PEP то же не просто так. И тысячи людей выбирают его как первый язык, учат и сложностей у них это не вызывает. Может конечно дело в 1сниках, которые бывает что по 7 лет работают программистами и не в курсе что на ИТС есть соглашение по написанию кода.
Да как минимум будет знать что есть такая рекомендация. Один раз запнётся об сразу закрепит теорию практикой, другое дело когда пишут такие функции и считают это нормальным подходом.
Пусть он сразу не поймёт 100% рекомендаций из книги, но если поймёт и начнёт применять на первых порах 10-20-30% то только выиграет от этого.
(50) Ок. Возможно, я слишком строг. Просто никогда не понимал пользы рекомендаций, вытекающих в одно действие из логики и здравого смысла. Всегда казалось, что программист, даже начинающий, должен в это немножко уметь. В противном случае, не факт что он занимается своим делом.
(51)
Забыл как этот эффект называется. Это когда мы читаем что то понятное и очевидное нам всё понятно. Но до прочтения для нас это знанием не является и мы этим не пользуемся как навыком.
Так же бывает что мы читаем книгу, вроде всё понятно, очевидно и банально. Но после прочтения можем воспроизвести в лучшем случае 10% рекомендаций из книги. Хотя все они казались простыми и очевидными.
(52) Вот второе ближе к теме. Сабжевые рекомендации — это признаки хорошего кода (во многом самоочевидные), а не руководство по его написанию (которое, увы, и не напишешь). Простое знание признаков хорошего кода мало дает к скилам написания хорошего кода.
Сердце хорошего кода — в грамотной алгоритмизации и структуризации, выборе эффективных абстракций и их взаимосвязей. По книжкам этому не научишься. А когда с этим начнет получаться, то большинство признаков хорошего кода прикладывается автоматически, как следствие.
(53)
не прикладывается. Почему то люди которые писали говнокод и не знали про «чистый код», «стандарты разработки» и прочие занимательные книги и спустя 7 лет продолжают писать точно такой же говнокод, только начинают это делать чуть лучше, быстрее, меньше ошибок, быстрее отладка, лучше разбираться в платформе, фреимворке и тд. Но в целом насмотрелся я на код людей с 5+ годами кодинга и почему то он как был говнокодом так и остался, а по вашей логике он должен был стать лучше ну 5 лет то не малый срок. Лучше он станет когда начнут работать над этим. И чем раньше тем лучше.
Во вторых не стоит изобретать велосипед если уже всё придумано за нас.
Незнание даёт?
(54)
Не-а. По моей логике этим людям ничего не поможет. Если человек не способен учиться даже на своих ошибках, то учиться на чужих и подавно не способен.
(55)На своих они учатся. Но на своих ошибках учится это долго, на чужих чуть быстрее, на хороших примерах ещё лучше.
Мало понять как не надо делать, надо понять как делать правильно. И неизвестно сколько надо сделать «итераций» что бы выработать правильный подход. Можно одну, а можно сто итераций и соответственно сто ошибок.
Но можно ускорится и прочитать как надо и как не надо делать от тех кто этот путь уже прошёл.
Как в строительстве прежде чем начать строить люди сначала делают проект ( чертежы, макеты , схемы ,расчеты )
Так и программировании желательно тоже такие проекты делать , т.е. заранее подумать над переменными , функциями , алгоритмами и т.д. Как лучше сделать ( сначала для общей задачи , а дальше уже для каждой функции по отдельности)
И когда у тебя в голове порядок , то в коде будет порядок ,
И как по мне , если нет полного понимания , хоть соблюдай все рекомендации , хоть не соблюдай порядка в коде не будет
(57)
Как в строительстве люди с начало учатся делать кладку по уровню, выполнять правильно штукатурные работы и тд и только потом берутся за работу.
А не берут кирпичи, вертят в руках в надежде что рано или поздно овладеют профессией строителя.
Имея проект, схемы, макеты и хорошее планирование кривыми руками ровный дом не построишь.
(56) Ну а мне кажется, что в части развития навыка написания хорошего кода внешним влиянием можно пренебречь.
Бест практисес ессно никто не отменял, но это немного другое.
Все упирается именно в то, насколько эффективно человек учится на своих ошибках. Насколько он самокритичен. Насколько склонен к анализу и совершенствованию. И так далее. Остальное вторично. Просто так получается, что такие люди еще и внимательно оглядываются по сторонам в поисках ответов. Но главное — это умение и желание анализировать и формулировать правильные вопросы.
(59)
Пренебрегать опытом сотен и тысяч людей не дальновидно.
Всё же не стоит забывать мантру программиста: «Я не буду изобретать велосипед, я возьму готовый и согну под себя», произносить в слух каждый раз когда берёшься за новую задачу.
(58) я к тому что , прежде чем писать код , надо его продумать и уже на этом этапе какой-то процент ошибок оформления кода уйдет. Да конечно , проектировщик должен знать рекомендации по оформлению чертежей (точнее там уже требования , но в случае с программированием будем говорить о рекомендациях) и может применять их на этапе о проектирования (не обязательно все ). На этом этапе он может разделить код на служебную часть и рабочую , подумать над переменными , подумать над функциями и т.д. т.е. он уже структурирует код.
(60) Опыт опыту рознь, к сожалению. Многие навыки проблематично передавать друг другу «на бумаге».
Мантра тоже имеет оговорки. Иногда эффективнее собрать самокат самому, чем адаптировать под эту задачу готовый самолет.
(62)
Никакой проблемы в передаче навыков по написанию понятно и структурированного кода не вижу кроме «не желания» получать их либо при определённых заболеваниях, но при таких заболеваниях уже точно не до программирования.
(29)
А цитату не приведёте, где я делал безапелляционные выводы о том, что книга плохая, рекомендации плохие? А то без цитат с вашими безапелляционными выводами и явно даже без прочтения того, что вы тут так оспариваете, больше похоже на базарный день. Целую сказку изобрели о том, как плохие одинэсники что-то всем вокруг доказывают, хотя сами ничего не читали, и только поклоняются своему коду. Вы бы для начала весь комментарий прочли, который у вас такие «наблюдения» вызвал.
Я говорил в каждом комментарии и повторю сейчас — книга и рекомендации не плохие и не хорошие, их применимость должна оцениваться в каждой конкретной ситуации. Плохим можно назвать разве что программиста, который слепо поклоняется чужим рекомендациям или напрочь их отвергает. Ну и комментаторов, которые лезут комментировать, не прочитав даже комментируемое 😉
(31)
А вы, видимо, утро начинаете с прочтения избранных мест из рекомендаций 1С и воздания хвалы Великому Нуралиеву)) Повторю ещё раз — прочтите хотя бы то, что вы так рвётесь комментировать.
(30)
С- Сперва добейся?))
(65)
Разумеется. Затем все берёмся за руки и поём гимн жёлтой программе. Вы разве ещё нет? Тогда мы идём к вам 🙂
Вы знаете другой способ определить «диванного специалиста по всем вопросам» от действительно знающего и умеющего?
Я сейчас работаю с клиентами, которые ранее работали с франчем. У тех ребят, была прекрасная привычка обфусцировать код(конкретно dll кой в краказябру превращали). Любая минимальная правка превращается в увлекательное часовое времяпрепровождение(Речь об Отчетах, печатных формах и обработках).
Стоит ли оно того, если лично мне и так норм( не мое мнение вопрос социального характера 🙂 )?
Так себе информация ) Единственное с чем я согласен, это не комментировать код, который неактуален, а лучше сразу удалить. Хоть сам и грешу этим =))
Через 10 лет 99% участников ветки будет рабствовать на где-нить на гидропонной ферме.
Набейте главные тезисы это статьи на булыжнике и прочтите спустя 10 лет, будет повод всплакнуть.
Пункт про «Содержательные имена» заставил улыбнуться. Вспомнился случай, как в одной организации уволился их сисадмин (по совместительству 1с программист), я пришёл посмотреть на ошибку в конфе, заглянул в модули, а там названия переменных, процедур и функций такие, что у самого грубого матершинника уши в трубочку свернутся. И ведь пришлось использовать эти вот самые матерные переменные в доработке сей конфы
(71) Нужно было применить правило бойскаута и все переименовать.
(58)
«Имея проект, схемы, макеты и хорошее планирование кривыми руками ровный дом не построишь».
НЕ имея проект, НИ схемы, НИ макеты и НИ планирование, кривыми руками ровный дом построишь 🙂
(73)скоро во всех вакансиях к программистам 1с начнут предъявлять требования — опыт строительства дома.
Ибо работа с проектом и сам факт необходимости ТЗ, а также открываемые им перспективы развития может оценить только человек, на
собственной шкурепрактике изучивший этот вопрос.Как бы чисто и по стандартам не писал программист, все равно тот, кому придется поддерживать, развивать и править его код скажет «ну и криворукий же был предыдущий погромист». Вывод: не существует двух программистов с одинаковым стилем программирования. Если такая коллизия случится, то вселенная коллапсирует.
(74) Тут речь идет не про ТЗ и Проект, Изначально имелось ввиду то , то что пока у человека не будет полного понимания задачи и способа ее реализации красивый код не напишешь. т.е. предполагается для начала «спроектировать» код в голове или на бумаге. Прежде чем сесть писать код , можно подумать какие функции должны быть что они должны делать, учесть плюсы и минусы выбранного подхода к решению задачи , подумать о том, что в дальнейшем может потребоваться расширения функционала . И этот подход можно применять не только к большим проектам , но и даже к написанию небольших отчетов и обработок.
(76) то есть вы считаете, что Проект и ТЗ изначально в строительстве даёт исполнителю понимание проблемы, а именно в программировании — не даёт?
(75) Это от человека зависит. Как правило кто сам говнокодит, то и других ругает.
В других языках ведь существует.
(77) Я такого не говорил , как раз я говорю обратное — что программист должен для себя составить «проект» как он будет выполнять задачу. Возможно я Вас немного не понял так как обычно ТЗ и Проекты идут для больших разработок. А их может и не быть
А тут допустим клиент просит вас написать ему небольшую обработку или отчет он может сказать это устно или оформить письменно что-то вроде ТЗ но не совсем например так :
Вроде бы простая задача . Но все равно , прежде чем бежать кодить , надо задуматься а как надо реализовать эту задачу , Сейчас клиент хочет что бы заполнялось по одной группе , а завтра захочет уже по нескольким + отдельные контрагенты. На каком этапе делать отбор контрагентов и т.д.
(6)
Вывести информативное сообщение об ошибке — это тоже ответственность программиста, использующего блок Попытка/Исключение.
(9) Кладут потому, что бизнес не готов платить за чистый работающий код. Только за работающий.
Стоимость поддержки смелл-кода не учитывается.
PS Хороший код можно поискать в продуктах. Не во всех.
Мне, например, приходит на ум одна конфигурация для гостиниц/отелей — точно не помню названия.. написана на английском диалекте 1С.
Думаю, делалась для турецких отелей и программистами пришедшими в 1С из другого языка.
(81) Бизнесу вообще не нужны продукты с открытым кодом. Майкрософт поставляет оем продукты не клиентам, а производителям компьютеров.
1с базовая или ее тонкий клиент тоже могла бы быть оем, но чего нет, того нет.