Комментарии 76
Не совсем понятно где работает автор.
Ну, да, чистый код лучше не чистого. Но надо понимать что люди не компьютеры и не просто исполняют заданные программы, а постоянно решают задачи, в условиях к которым включены и собственные эмоции.
Эго - это как раз и есть взрослая часть личности, которая находит компромисс между своими интересами и правилами. Так что если чел настоящий эгоист, за него можно только порадоваться.
Вынужден с вами не согласиться.
Профессионал это и профессиональная этика и стиль кода.
У меня могут быть какие угодно эмоции, но если через год я не могу разобраться в собственном коде, а другие разработчики избегают мой код - никакой эгоизм не в оправдание. Это просто непрофессионализм.
И наоборот - иногда встречяю код, который приятно читать, учусь и подбираю для себя массу полезного.
Спустя 15-20 лет в разработке я отказался от проявления эго.
Городость за качественную работу - это да, но эго и гордыни нет.
Не существует единственного правильного стиля кода. Общепринятые стили очень сильно различаются между языками, конкретными технологиями и областями и даже отдельными проектами, они могут быть диаметрально противоположными.
Есть какой-то набор идей, как написать более красивый и понятный код, но местами они лежат на грани между объективностью и предпочтениями.
Из примеров:
В C# любят писать геттеры-сеттеры на всё (даже в примере автора они зачем-то есть, хотя ничего не делают), в Python стараются обходиться без них.
В некоторых языках делают приватным всё подряд, в некоторых делают данные публичными и неизменяемыми, а рядышком люди пишут код на Python, в котором ни приватности, ни неизменяемости - и мир не рушится.
В Java под Android из-за неудачного решения одного мужика из Google названия полей классов m_camelCase, а в такой же java здорового человека просто используется camelCase.
Есть функциональные языки типа хаскелля, в них тот же самый код будет совсем иначе выглядеть.
Иногда люди накладывают сознательные ограничения на язык программирования - например, не используют исключения в С++ или goto.
Я вот смотрю на примеры автора на С# и меня прям коробят эти циклы for(int i; i < groups.length - 1; ++i), но это мои личные предпочтения.
А ещё код не существует сам по себе, он обычно существует в контексте какого-то проекта с каким-то устоявшимся стилем, и приходится подстраиваться под него.
В C# любят писать геттеры-сеттеры на всё (даже в примере автора они зачем-то есть, хотя ничего не делают),
Это не совсем предпочтение — как правило свойства сериализуемые, а поля — нет.
В некоторых языках делают приватным всё подряд, в некоторых делают данные публичными и неизменяемыми, а рядышком люди пишут код на Python, в котором ни приватности, ни неизменяемости — и мир не рушится.
Ну правилам инкапсуляции правильно делать все по-умолчанию приватным и неизменяемым, а уже потом открывать или делать изменяемым при необходимости. Все-таки это тоже не совсем субъективно — удобней ориентироваться в иммутабельном коде, в нем сложнее допустить ошибку, да он так и чище выглядит.
Это не совсем предпочтение — как правило свойства сериализуемые, а поля — ненетн
Но не везде это нужно, как минимум, и это вряд ли основная причина. Ну или, как минимум, не единственная
Геттеры и сеттеры на "вообще все" нарушают yagni. Раздувая и без того немаленький ныне код.
На "вообще все" их и не делают. Их делают на то, что доступно снаружи объекта. Иными словами, хорошее правильное поле (field) должно быть private (и в редких случаях - protected), а public или internal делают только свойства.
(я сейчас про C#, где геттеры-сеттеры дешевы: public string Name {get; set;} vs private string _name;)
Я на плюсах пишу поля классов в виде m_camelCase, мне это кажется удобным - при чтении кода видно где поле класса, а где локальная переменная. В подобном наименовании есть какая-то порочная практика в принципе, или вопрос именно в разнице между стилями Java под Android и просто Java?
Я говорю именно про java под android и просто java. Язык один и тот же, программисты примерно тоже, но пишут по-разному. Причина: один из первых разработчиков Android когда-то решил, что он чаще читает код в браузере, а не в IDE с подсветкой, и типа так удобнее: https://habr.com/ru/post/333596/?ysclid=l6dcku117u402263940
Java разрешает в классе иметь методы и поля с одинаковыми именами. В С++ так вроде бы нельзя, там префикс m_ спасает от коллизий имён.
В любом случае и в С++ и в java можно писать и так и так, это скорее вопрос предпочтений.
Это подмена тезиса — вы возражаете против утверждения, что якобы есть единый принцип чистого кода для всех языков. Но автор статьи такого не утверждал. Он сказал, что плохие кодеры прячут неумение писать понятный код под "вкусовщиной" и "это мой стиль", не заботятся о читаемости.
Действительно, формальных принципов чистого кода нет и не может быть, так как подход к написанию кода зависит от огромного количества факторов — парадигма, архитектура, принятые в языке идиомы, выбранные конвенции, да и просто размер продукта. В конечном итоге единственный рабочий критерий — это упомянутое Р. Мартином wtf/min.
Но отсутствие единых чётко формулируемых принципов хорошего кода не означает отсутствие самого хорошего кода. Тут как с литературой — нельзя создать "список принципов хорошего писателя", прочитав который любой мало-мальски грамотный человек превратится в Достоевского. Так и тут со всеми этими SOLID, DRY, GRASP, LoD, SoC и прочего, что новички часто зубрят, но не умеют применять.
Ну так это тоже ваши эмоции ) Более взрослые, да. В итоге, суть вопроса сводится к банальному "конфликту поколений".
Ну, не знаю. Лично я считаю, что с менее компетентными коллегами стоит, наоборот, найти общий язык, и через эту связь попытаться донести ценности, чем окукливаются в своем коконе. Но это чисто мое мнение. Конечно, они все равно возьмут только нужное, но хотя-бы показать весь ассортимент, мне кажется - стоит того.
Есть инструменты форматирования кода, они помогают.
Хотел бы я, как автор статьи, жить в прекрасном мире, где по названию функции, написанной неизвестно кем, можно понять, что она делает, и дальше не читать код. К сожалению, реальные программы совсем другие.
А ещё важнее, что в реальную чужую программу мы обычно залезаем тогда, когда она работает не так, как задумывал автор. И тут красивыми названиями не отделаться.
В реальную программу мы обычно залезаем тогда, когда от бизнеса приходит требование на доработку. И если команда разработки большая, часто видишь чужой код.
Но ведь к этому нужно стремиться. Хотя бы чтобы часть функций была понятна.
Это несомненно.
Но автор почему-то уверен, что, разбодяжив код на два экрана вместо одного, он увеличил его понятность. Вот это уже спорно.
Вообще, два экрана хуже одного, так как не видимы одновременно. Автор в ответ, вероятно, сказал бы, что это просто пример, иллюстрирующий в маленькой статье какие-то общие мысли. Но тогда мы возвращаемся к тому, оформление – в немалой степени дело вкуса и конкретных обстоятельств, а не какие-то железные правила. А также не надо забывать о том, что каждый из его отдельных геттеров-сеттеров (или что там было в статье) всё равно надо проверять при поиске ошибок.
Вообще, тут ещё надо разбираться, понятность для кого мы увеличиваем. У какого-нибудь гуру программирования в голове много паттернов, и ему понятен сложный код, а простой индусский крестьянин ничего сложнее присваиваний с одной операцией в правой части в линейной последовательности понимать не обучен, циклы уже с трудом. Среднее где-то посередине, но откуда нам известно, что нужно ориентироваться на среднее? Это всё не такие простые вопросы.
Быстрый код лучше медленного. Стабильный лучше глючного. Короткий лучше длинного. Понятный лучше умного.
Простое лучше сложного. KISS forever.
0) Работающий лучше неработающего
-1) Поэтому он пишет такой код, который нужен, чтобы не стать неработающим
Я много раз видел код, который "просто работает". К сожалению, чаще всего это его единственное достоинство. И в тот момент, когда такой код нужно "немного подправить", оказывается, что быстрее будет написать с нуля, чем разобраться.
А если бы код был не рабочим, но хорошо структурированным и читаемым, то подправить его мог бы любой разработчик за разумное время.
Поэтому мои приоритеты такие:
Читаемость.
Эффективность.
Красота.
А что за красота? А где приоритет, что код вообще работает? На первом месте всегда выполнение функционала должно быть, нет?
А если бы код был не рабочим, но хорошо структурированным и читаемым, то подправить его мог бы любой разработчик за разумное время.
Если он не работает, то его правка может быть равносильна полному переписыванию с нуля, как в первом примере. Выглядит как крайность
А что за красота?
Красота - это такие вещи как лаконичность, семантический сахар. Они делают код эстетически более приятным, но не сильно влияют на читаемость или эффективность.
Если он не работает, то его правка может быть равносильна полному переписыванию с нуля, как в первом примере.
Представьте ситуацию, когда новую фичу начал имплементировать крутой разработчик, но в середине работы его чем-то отвлекли. Например, его навыки понадобились, чтобы срочно пофиксить баг, или его сбил автобус. Если код хорошо структурирован, то его может подхватить и дописать менее квалифицированный разработчик. А если крутой разраб будет писать в стиле "смотри как я умею" (привет однострочникам в 400 символов), то именно в этом случае придётся или потратить много времени, чтобы во всём разобраться, или потратить много времени, чтобы переписать с нуля.
Я считаю, что лучше сделать часть работы, которую потом можно доделать, чем всю работу, которую потом придётся переделывать. Именно моэтому функциональность не в приоритете.
А если разработчик может писать так, чтобы сразу было и читаемо, и работало, то это просто прекрасно.
Как часто у Вас разработчик не закончив фичу отдаёт её на доделку?
Менее квалицифированному разработчику имхо в сложном коде с идеально продуманными абстракциями будет сложнее разобраться. И запороть он сможет всё гораздо сильнее, т.е. нарушить где то такие то продуманные первым разрабом правила, а потом уже то всё поправить будет гораздо сложнее, чем если бы он в одном месте кучу кода написал.
Я считаю, что лучше сделать часть работы, которую потом можно доделать, чем всю работу, которую потом придётся переделывать. Именно моэтому функциональность не в приоритете.
А я считаю, что лучше сделать, чтоб работало, чем, чтоб было круто и красиво, но не работало. https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
А продумывать заранее миллион абстракций - ну не знаю.
Но заметьте, я не предлагаю писать плохо или в один метод всё запихнуть. Я за то, чтоб сначала код в принципе работал, но без оверинжиниринга. Чтоб увидеть реальные кейсы\проблемы, собрать те же логи, найти места для расширения.
А что за красота?
Красота - это такие вещи как лаконичность, семантический сахар. Они делают код эстетически более приятным, но не сильно влияют на читаемость или эффективность.
Если он не работает, то его правка может быть равносильна полному переписыванию с нуля, как в первом примере.
Представьте ситуацию, когда новую фичу начал имплементировать крутой разработчик, но в середине работы его чем-то отвлекли. Например, его навыки понадобились, чтобы срочно пофиксить баг, или его сбил автобус. Если код хорошо структурирован, то его может подхватить и дописать менее квалифицированный разработчик. А если крутой разраб будет писать в стиле "смотри как я умею" (привет однострочникам в 400 символов), то именно в этом случае придётся или потратить много времени, чтобы во всём разобраться, или потратить много времени, чтобы переписать с нуля.
Я считаю, что лучше сделать часть работы, которую потом можно доделать, чем всю работу, которую потом придётся переделывать. Именно моэтому функциональность не в приоритете.
А если разработчик может писать так, чтобы сразу было и читаемо, и работало, то это просто прекрасно.
Простое лучше сложного.
Простейшая пузырьковая сортировка лучше быстрой и сложной? :)
Одновременно соблюсти все принципы KISS редко получается и тогда, вы выбираете каким из них отдать предпочтение.
Смотря для каких целей. Если речь об обучении первокурсников - то в этом контексте, возможно, да.
Но в общем случае порядок имеет значение, конечно. Можно использовать SPIFE - Stability, Performance, Intuitive, Functional, Extendable - именно в таком порядке.
Ну это как посмотреть:
пузырьковая сортировка даёт среднюю сложность О(n^2), а быстрая - О(n log(n)), так что "быстрая сортировка" проще "сортировки пузырьком" )))
Явное лучше неявного :)
Я художник, я так вижу
Господи Боже, от одного взгляда на этот пример у меня болит мозг…
Вот тут-то и проблема, имхо. Есть пишущий (код), а есть читающий. И если читающему неуютно, то он начинает обвинять пишущего в неуважении и эгоизме. Насколько вообще уместны этические оценки в, казалось бы, технических делах - автору виднее. Выход очевиден. Если речь идёт о производстве, то устанавливаются соответствующие стандарты, люди договариваются на берегу, и дальше обсуждают только очевидно вредящие делу нарушения. А то все побросают работу и будут на основе коротких фрагментов кода обвинять друг друга в эгоизме и бог ещё знает каких смертных грехах.
Тут дело в том, что мы не стоим на месте, а меняемся вместе со временем. И то, что нам очевидно сейчас, будет совсем неочевидно через пару лет. Вот отсюда и эта неуютность.
Вот у меня есть кусок кода, который я вымучивал почти месяц - там сложные математические расчеты - три цикла друг в друге с кучей ветвлений по условиям. Так вот я, вернувшись к нему через полгода, не смог понять практически ничего (кода рабочий, кстати), хотя параллельно с написанием кода я задокументировал алгоритм (даже с картинками).
Мне кажется, дело здесь не в красоте или некрасивости - дело как раз в пресловутом "я художник, я так вижу". Сегодня художник видит так, а через год - по другому. Вот и вся недолга.
Ну вообще , если поручить поддерживать код условному джуну Васе , то вполне вероятно, он будет лучше всего именно первый "плохой" поддерживать по причине того, что всё в нём поймёт.
Или взять задачу , что надо код из одного языка быстро конвертировать в другой.
Но вообще лично у меня ситуация не раз была, что я считал свой код хорошим, но смотря на него через год, менял мнение.
Джун Вася будет его лучше поддерживать только потому, что не додумается, что трудность в чтении этого кода - это не проблема его неопытности, а это сам код плох. Так что Вася будет грызть этот кактус пока и в самом деле не начнет с ним справляться, но такими темпами сгорит весьма быстро.
Ну с первым вариантом кода она будет гораздо быстрее справляться. Т.к. сравните количество знаний операторов и функций, которые нужны для поддержки первого кода и второго. При том что важно также и твёрдое знание, а не "один раз видел где-то". Другое дело, что если он будет править только первый код, так джуном и останется, а в другое место его и стажёром не возьмут.
А может, если джун Вася всё понял в плохом коде, то код не так уж и плох?
Код из статьи я за разумное время не понял.
Я понимаю инженеров-строителей-архитекторов, у них гравитация, сопромат, роза ветров и плавание почвы. Материальные основания для строгих правил.
Внутри компьютера ограничений гораздо меньше, эти ограничения известны. И в статье нет каких-то новых материальных оснований для ограничений. Был бы автор, а не переводчик, можно было бы спросить "обоснуй объективно".
Материальным будет разве что голод, который наступит если бизнес будет настолько критичен к code-style, чтобы при прочих равных за него увольнять. Но это уже совсем другая история.
Был бы автор, а не переводчик, можно было бы спросить "обоснуй объективно".
А зачем?
Ну вдруг у него был инсайт и он что-то такое понял. Сомнительно, но всё же, спросить стоило бы.
А так да, понятно что очередной идейно намагниченный видит мир только так, и никак иначе.
Так вроде бы написано прямо во вступлении:
It is a pet peeve of mine
Проблема, однако, немного шире. Вот вы поняли, что нет объективного обоснования для того или иного code style (не новость, прямо скажем)… а дальше что?
Тут всё как всегда, возможно лично меня это никогда не коснётся и я до пенсии доживу не потратив ни калории на удовлетворение чьего-то чувства "читабельности" или "красивости". Но учитывая, какую идейную заряженность имеет каждый такой тредик, думаю, мне просто повезло не столкнуться с подобным.
Code-style это ведь часть айсберга. Есть другие подобные конвенциональные, необоснованные явления, что давят на человечка посильнее, чем душный ревьюер. Да и ревьюера можно понять, если он сам понимает, а вот если не понимает, то такого понять нельзя и принять тоже. Впрочем, это другое!
В общем, коллективное осознание массовой шизофрении субъективности это путь из царства необходимости в царство свободы.
Но учитывая, какую идейную заряженность имеет каждый такой тредик
А какую, кстати?
В общем, коллективное осознание массовой шизофрении субъективности это путь из царства необходимости в царство свободы.
Каким же образом?
Если вернуться к практике: вот у нас есть команда разработчиков, человек так в 50. Должен быть в ней code style — который, как мы помним, нельзя объективно обосновать — или же надо его отвергуть, как "конвенциональное, необоснованное явление"?
Если программист не умеет читать "по диагонали" - то и написать код, пригодный для чтения "по диагонали", он сможет разве что случайно, как бы он не уважал коллег.
Неоднократно наблюдал, как после доработки "профессионалом" код из семантически наполненного письма другу превращался в набор инструкций для машины.
Лучше просто не допускать к коду людей, которые не умеют читать. Сначала плавать научитесь, потом бассейн наполним.
Правило двух секунд: "если на то, чтобы понять, что делает строчка кода, вам понадобилось более двух секунд — она должна быть переписана".
И про предметную область верно замечено выше. Бизнес-логики там всякие, абстракции. И всё может поместиться в одну строку в итоге.
for(int i; i < groups.Length - 1; i++)
{
commandTextBuilder
.Append(AddParametersAndGenerateValueRow(groups[i], i, command))
.AppendLine(",");
}
command.CommandText = commandTextBuilder
.AppendLine(AddParametersAndGenerateValueRow(groups[i], i, command))
.ToString();
Во-первых, у вас будет выход за границы массива при коллекции нулевой длины.
Во-вторых,
string.Join(",", ...) гораздо короче и понятнее, чем for(...) { }, и позволяет не повторять одинаковый кусок кода (или проверять индекс, чтобы решить, где ставить разделитель). Под капотом тот же StringBuilder.В-третьих,
AddParametersAndGenerateValueRow() берёт на себя две обязанности: генерит строку и генерит сайд-эффект, нарушая SRP. Что закономерно отразилось в ужасном названии функции.
Уважаемый автор, ваш пример №3 на чистый код не тянет. Там нет ни одного комментария. Это неуважение к команде.
Выскажу очень еретическую мысль.
Отсутствие общего хорошего стиля имеет свои преимущества.
Даже если мы говорим о разных способах табуляции. Даже если мы говорим об откровенной лапше и говнокоде. И даже если все это легко правится автофиксами и проверяется линтерами. И даже в большой команде. Конечно я не говорю о бесполезности приведения кода к нормальному и общему стилю, но все же, очередной раз делая ревью, не стоит править весь авторский стиль.
- Итак про плюсы. Представьте себе файлик с кучей разных стилей, говнокодом, разными отступами, по разному названными переменными и так далее. По началу он конечно раздражает количеством энтропии. Однако при поиске бага, глаза сами тут же полезут в места с неправильными, не логичными отступами. Что характерно, программисты, которые не однообразно ставят отступы, допускают больше ошибок. Т.е. хороший стиль, он как дезодорант, добавляет коду хороший запах скрывая содержимое. Или, переформулирую, хороший программист, зачастую, пишет код с четким стилем, но программист с четким стилем, не обаятельно хороший. Ну и конечно хороший стиль особо не помогает развиваться, конечно, думая о коде для его форматирования, мы все же развиваемся, но лучше просто писать код.
- Второй плюс заключается в узнавании авторов. Конечно их можно посмотреть через гит или аналоги, но все же через стиль это проще. И зачастую зная авторов, вы узнаете и типичных их ошибки, точнее их стиль мышления и можете предположить к каким ошибкам он ведет. Свыше того четко виден их уровень, типа написать crud — может, но с проверкой безопасности затупит.
- Третий плюс в экономии времени. Действительно код в одном стиле читать проще, только одинаковое написание кода не ведет к одинаковому мышлению, поэтому все равно, при переходе от одного автора к другому, в чтении происходит заминка. А вот на привод к одному стилю бывает что тратится до 90% времени. И ладно если у вас настроены линтеры, автофиксы, и все это проверяется прямо перед пушем. Но ведь бывает стилизация через ревью или очень редкие правила. Да еще и ревью идет не сразу, и зачастую с первого раза не высказываются все претензии, или комментарий в стиле "вот тут ошибка А подправьте ее во всем реквесте". Тогда больше одного двух реквестов в день ждать не стоит. И весьма большую часть времени разработчик будет тратить на борьбу с прокрастинацией, ибо править стиль ему банально не интересно.
- Еще странный плюс, это количество ошибок. Этот плюс конечно сомнительный, ведь когда мы правим стиль, мы можем найти ошибки, также после правок стиля порой наши ошибки найти легче, плюс на местах стыковки с чужим говнокодом ошибок станет больше, но все же. Тратя время не на работу над стилем, и держа код похожим на наш образ мышления, мы совершаем меньше ошибок и проще их находим.
Резюмируя.
Уменьшение количества стилевых правил может дать дополнительную информацию о коде и значительно сократить время на его написание, также уменьшает количество ошибок и облегчает правки, если речь о куске кода одного автора.
И я нисколько не против общего стиля, я даже за, просто наболело. Но все же пример с письмами у автора поста не корректный, автор исходил из тезиса, что эти письма в любом случае напишут и мысль в них будет одинаковая, вне зависимости от подчерка. Это не так. Вероятней их содержимое сократилось бы, а отношение авторов писем стало бы более негативным. Это нормально. Мы люди, и когда нас заставляют делать что-то не приятное мы работаем хуже. Также как программисты, мы обычно стремимся у уменьшению энтропии, но наши возможности ограниченны. А фанатичное отношение к чему-то, даже к хорошему коду, при возведении в абсолют, приносит весьма большое количество вреда, и даже зачастую больше чем пользы.
Как-то долго и сложно объясняется... Есть ведь простая красивая формулировка: "пиши код так, будто поддерживать его будет психопат, знающий, где ты живёшь".
Для меня третий вариант выглядит не многим лучше первого: он точно также зашумлён, просто вместо того чтобы всё делать вручную и в одном методе, ударились в другую крайность и побили код на кучу мелких методов. Чтобы понять что и как работает в итоге всё равно придётся их все просмотреть.
Причём (почти) все эти методы специализированные, не подразумевающие повторного использования. Зачем, например, выделять добавление параметров в метод AddParametersAndGenerateValueRow? Ладно бы там была сложная логика, но это буквально размазывание ответственности по методам.
Вобщем, на мой взгляд, второй вариант лучший из представленных (хотя и не идеальный). В идеале, наверно, стоило бы разделить логику на два метода - подготовка данных и их сохранения. И второй метод можно спокойно вынести в репозиторий, если используется этот шаблон проектирования (что заодно позволяет немного абстрагироваться от базы данных).
После прочтения уже десятков статей на хабре на эту тему я понимаю, что статьи не могут поменять ровно ничего. Лучший способ распространить свое видение - это делом показывать, что оно лучше. Если в ваших проектах любой баг обнаруживается за минуты, любая доработка безболезненно влезает в рамки спринта и не приносит регресса, любой джун въезжает в процесс за неделю - то есть смысл делиться этой фактурой с коллегами, мягко продвигать свой подход. Если все действительно классно, то коллеги проникнуться и понесут знание в свои проекты и другие команды.
Любой код пишется в неодинаковых обстоятельствах и решает неодинаковые задачи. Потому стиль постоянно разный при всем желании сделать все по уму. К тому же код – он живой. И стиль в начале может не соответствовать стилю в конце, если нет времени и возможности его довылизывать.
Вот, например, два месяца назад мне поставили задачу сделать очередной оптимальный подбор и запихнуть результат в систему. Решено, оформлено и откомментировано. А потом на него начали наслаиваться проверки и подпроверки (оптому что пользователь вносит коррективы в процессы, к которым код), выяснилось, например, что типов упаковки не три, как предполагалось изначально, а больше, и они вообще должны быть настраиваемые. А еще через несколько недель выяснилось, что для формы вывода надо вообще типы упаковок другие, потому что то, что заложено в системе, не всегда соответствует физическому виду, и по физике типы склад составляет вообще сам, посмотрев глазками. Формы вывода надо был делить по признаку, который надо было еще распознать общим анализом полученных результатов массива. Да еще чертова масса требований.
Весь стиль посыпался как карточный домик. То, на что хватало массива, стало необходимым делать через классы и коллекции, обращения к другим программам и обработки, которые были в одном общем цикле, надо было выносить в отдельные функции, так как их стала куча дублирующих. В результате я сказал, что все перепишу набело с нуля. Но это был только один процесс.
А был бы большой проект с кучей тесно связанных модулей – я бы заново ничего не переписал, а продолжил бы так, как оно есть, накручивать и накручивать модули, вставлять куски, дублировать элементы кода и пр., то есть, просто ничего не осталось бы, кроме как продолжаь писать грязный код.
Причем хороший стиль и удобство чтения не всегда связаны. Один китаец написал код в 40 строчек и 26 подпрограмм по три-четыре строчки каждая. Вроде бы по уму – каждой заполняемой ячейке декларации свой код, который можно модульно поменять при изменении условий расчета (корпорация международная). А реально-замучаешься колесико крутить. Я даже распечатал декларацию и подписал ячейке ручкой имена подпрограмм чтобы понимать, куда лезть, пока разбирался.
Будучи дилетантом, который пишет программы в большинстве случаев для своего собственного образования я с интересом прочел Вашу статью. (Кстати в пример ужасного кода похоже закралась опечатка: класс называется record а используется он как records. И не инициализируется mdate_time которая далее в таком виде и попадает в базу данных. Думаю в виде начала эпохи unix )
У меня создалось впечатление, что разница стиля между Примером 1 и Примером 2 не принципиальная и стилистическая, а скорее относящаяся к использованию конкретно возможностей языка C#.
Несомненно, автор дал более "человеческое" название основному методу RunProc и оптимизировал множественные запросы к базе данных.
Но основным отличием стало то, что кусок кода с двумя вложенными циклами подсчета суммы по ключу был заменен на
var grouped = input.GroupBy(r => r.Name)
.Select(g => new {
Timestamp = g.First().Timestamp,
Name = g.Key,
Quantity = g.Sum(e => e.Quantity)
}).ToArray();Таким образом, тот же самый вложенный цикл должен быть реализован где то в другом месте. Ну или даже какой-то более сложный аналог с O(ln(n)).
При этом переход от Примера 2 к Примеру 3, на мой взгляд добавил еще больше специфики именно C# однако является хорошим примером не столько объектно-ориентированного, сколько процедурного программирования.
На самом деле мне всегда казалось что существует некое правило - каждая независимая задача должна решаться с использованием своего собственного метода ( процедуры, функции )) И тогда код будет легче читаться. Т.е. задача программиста в каждом процессе выделить подзадачи, грамотно их именовать и реализовать алгоритм.
Но, как и всегда должен быть баланс. И вот в этом балансе - делить ли задачу дальше или укрупнять и есть искусство написания кода.
Жаль, но я в это не умею. При этом продираться через деревья вызовов функций тоже не всегда просто. Видимо все же комментарии о том что делает данная процедура, это самое лучшее средство разобраться в будущем.
То есть никого не смущает, поле datetime timestamp)) это кстати не ключевые слова в базе?
Во вторых quantity мне не нравится, тут наверно ammount будем уважать коллег, которые знают английский.
Рекорд преобразуется в такой же рекорд, но с другим смыслом, я не понял?
Вы херачите данные в базу в цикле?
В третьих, чо за треш творится? Мы должны хернуть всё данные в базу, как они есть без мудацкий стримов. А потом уже из базы выбирать, то что вам нужно. Там групиповать и суммировать.
Где орм? Где Энтити, где айдишники? Я не верю, что в решётке такого нет!)))
Привет, в этом и есть искусство - называть переменные так чтобы было понятно что в них хранится.
Как мне кажется на границах разных сред ( База данных / приложение / веб интерфейс ) очень часто на выбор названия влияет одна из сред. И в другой среде такой выбор может казаться не очень логичным. ( К вопросу о datetime timestamp)
Что касается quantity, это вполне себе название для количественного поля, а amount для поля стоимости.
Ну а остальные комментарии вообще ведь не относятся к сути статьи. Человек перевел для нас статью о подходе к программированию, и качестве подчерка программиста. Каждый узнал какие то свои собственные кусочки кода и мнение потенциального читателя кода. И по сути автор рассматривал вопрос о том что делает код более понятным, а значит и качественным и пришел к верному выводу о разделении ответственности между частями кода и внедрении возможностей языка, дабы сделать код читабельнее.
А вот принятие решения о записи данных в базу это ведь вопрос очень неоднозначный. Где и какие преобразования делать, решает программист на основе своих задач и различные Active records не всегда будут полезны. Возможно, мы и наблюдаем кусочек реализации такого вот орм.
Ну и наверное с адресатом своего комментария вы ошиблись, так как я не автор ни статьи ни перевода, но по возможности ответил как сам понимаю.
Таким образом, тот же самый вложенный цикл должен быть реализован где то в другом месте. Ну или даже какой-то более сложный аналог с O(ln(n)).
На самом деле код стал линейным.
Я как начинающий питонист, считаю, что есть определенные нормы которые следует соблюдать всегда. Это наверно как и в любом языке. Отсуп от этих норм, скорее всего можно сделать в том случаее, если это будет понятно всем остольным от стажера до синьора.
"Работая над кодом, стремитесь к чувству гордости: за названия переменных и методов, за интервалы и переносы строк."
И всё?) Ну как минимум он еще должен работать.
По мне - так проблема взята с потолка. В реальности можно писать любой треш, конечно, но он не пройдёт ревью и отправят читать методичку.
«Это просто мой стиль кода»