Комментарии 24
Чётко и ясно. Самое главное - полезно.
И ни слова про табличную запись кода...
А что это такое?
Это когда однотипные участки кода и данных форматируются в соответствии со своей структурой, превращаясь как бы в "таблицу".
Позволяет кардинально сокращать размер листингов, одним взглядом оценивать сложную структуру кода и легко выявлять трудноуловимые ошибки.
Просто супер-метод #1 для программинга и оптимизации кода.
Если я вас правильно понял, то вы имеете в виду частный случай data-driven programming?
"Табличная запись кода" даже не гуглится
Ну, я описал своими словами то, что использую в каждом своём проекте на многих языках программирования - если Гугл этого не знает, то это проблема Гугла :)
Эта методология должна как-то называться, я же не один такой умный.
Напишите статью. Почитаем.
Уже написал. В этом руководстве по стилю есть раздел с примером табличного форматирования.
https://hi-lab.ru/arduino-mega-server/manuals/programming/62-ams-code-style
Так это про оформление кода, а не архитектуру.
Насколько я понял, речь идёт об описании принципа табличного форматирования - в этой статье есть соответствующий раздел и пример.
У вас даже в названии фигурирует слово "форматирование".
Возможно это применимо к написанию кода для микроконтроллеров, там да, каждый бит имеет ценность, поэтому архитектуру закладывают на уровне форматирования, так как весь код пишется в одном файле.
Грубо говоря то что у нас лежит в отдельном модуле, там будет в отдельном блоке.
Но это мои предположения.
Это универсальный метод и он применим (почти) для любого языка программирования.
Скорее всего это метод форматирования, связанный с выравниванием пробелами, чтобы знаки пунктуации находились в одном столбце.
Основной минус: при добавлении переменной или функции с более длинным названием выравниваются все остальные строки.
Давно уже изобрели tools для автоформатирования.
В golang вообще на уровне языка это встроено и ни кто не тратит время на споры.
Да, при изменении названий блок придётся переформатировать.
Но со временем начинаешь писать однотипный код с однотипнными названиями, что почти исключает переформатирование.
Принцип единственной ответственности (single responsibility principle) подразумевает, что каждая функция или метод должны выполнять только одну конкретную задачу.
Сам Р.Мартин говорит, что такое описание не соответствует Принципу единственной ответственности...
Приводите пример хороших имен используя calculateTotal. Вот calculateTotal что? Это как раз пример не очень хорошего нейминга.
Соглашусь. Стоило бы назвать calculateTotalCost , потому что даже в этом контексте может быть ещё calculateTotalQuantity ( суммарное количество товаров в корзине) , calculateTotalDiscount ( общая скидка). Может, ещё что-то.
Весь этот JS выполняет calculate... , я считаю, что наоборот — все глаголы лишние. Редкие исключения конкретных действий , типа open close. Но calculate ни в какие ворота не подходит.
И в описательной части интерфейса: приходят писатели в душе — "для применения этой настройки необходим restart". Видели столбы, начинающиеся одинаково "Show ...." , по 10 штук рядом с простыми галками. Кроме психологической атаки на мою самооценку (реально представляешь себя в палате для ограниченных), так еще и место съедает.
У америкосов это заметно, особенности языка с детства, растягивать смысл. Я вижу это же заболевание и у автора. И понимаю предков программирования с их сестрой Краткостью.
Assembler. Чище не придумаешь.
Принцип единственной ответственности (single responsibility principle) подразумевает, что каждая функция или метод должны выполнять только одну конкретную задачу.
Самый холиварный принцип. Для того чтоб понять, нужно прочесть не один десяток мнений, статей, видосов и самого дядю Боба.
Суть его в том что причиной изменения функции должен быть один актор. Например: бухгалтерия и менеджеры. Можно написать один класс который будет обслуживать их обеих. В итоге у функции будет две причины для изменения, что не соответствует принципу.
Вместо бухгалтерии может быть что угодно, в том числе системные вещи.
Проще говоря, написание чистого кода может казаться более медленным процессом в начале, но в долгосрочной перспективе это экономит много времени и упрощает работу.
На самом деле чистый код и в краткосрочной перспективе пишется быстрее, чем грязный. Вопрос только в том, что писать код быстро и чисто сразу не получится - нужно учиться этому. Чем меньше разработчик понимает то, что он делает, тем грязнее его код. А если понимаешь плохо, то и писать быстро не получится.
Как писать чистый код — советы для разработчиков с примерами