How to become an author
Streams
All streams Development Admin Design Management Marketing PopSci
Comments 39
смотрите, на картинке изображена архитектура, которая очень сильно зависит от компонента, наиболее приближенного к конечному пользователю

исходя из этого, можно сказать, что это архитектура с нарушением инверсии зависимости
0
Аналогично с названиями переменных в виде x и xx. Правда есть общепринятые исключения в виде e для ошибок, i,k — для счетчиков циклов, n — для размерностей и несколько еще.


Со времен динозавров существует венгерская нотация же. Не смотря на критику, ИМХО, крайне удобный подход, независимо от строгости типизаций используемого языка.

-6
И в каких случаях из хорошего названия непонятен тип и это проблема?
+1
Вот есть условная переменная с хорошим названием (хорошее же?) CurrencyType — определите по ее названию, что там? int, string, byte… итп?
+1
В зависимости от задачи, я могу в ней держать string в виде строкового кода валюты держать. «RUR», «EUR» и т.п.
И об этом вы не догадаетесь до тех пор, пока не увидите логику работы с этой переменной.
0
1. Я же не зря уточнил, что это должно быть проблемой, если вы не знаете как в проекте задаются валюты вам, независимо от названий переменных, придётся куда-то посмотреть чтобы увидеть справочник или пример использования в другом месте.
2. В хорошем коде это enum
+2
Вот честное слово, не хочу развивать холивар на эту тему.

Давайте останемся при своих — мне нравится венгерская нотация (и ее вариации) еще с прошлого века, и я нахожу ее полезной (для себя) до сих пор (даже в PHP), ну а вам (по вашим личным предпочтениям) — нет.
-2
C# строго типизирован и венгерская нотация не приносит здесь большой пользы. Всегда можно указать явный тип вместо var. Плюс если тип поменяется компилятор сам подскажет где поправить.
0
Вы рассуждаете как Торвальдс — «компилятор сам знает, что там» :)
Я же рассматриваю ее с точки зрения удобства чтения кода человеком, а не компилятором.
-2

Чтение дело субьективное но мне так больше нравится


decimal totalAmount = GetTotal();

чем


var d_amount = GetTotal();

Впрочем, еще раз, это дело привычки.

+1
Венгерская нотация — это же не постулат какой-то, это относительный пример сокращений для упрощения чтения кода :)

По сути, это тоже венгерская нотация:
Bitmap bmpSrc = new Bitmap ();
Image impDest = ...
Button btnReset = ...


0
Уточните, я мог отстать от индустрии: разве префиксы типа d, n, s…, «подсказывающие» тип переменной, не являются deprecated-практикой в C#? Да еще и в snake_case…

Очевидно же, что d_amount не удовлетворяет большинству принятых (включая Microsoft recommended) соглашений о именовании переменных.

Что же до var / …
Если тип очевиден (конструктор), резонно же использовать var:

    var man = new Human(Gender.Male);
    // но
    Human woman = GodObject.SpawnWoman();
0
Уточните, я мог отстать от индустрии: разве префиксы типа d, n, s…, «подсказывающие» тип переменной, не являются deprecated-практикой в C#?

Компилятор в логах осуждает, да.
-1
Сначала решаем проблему, потом делаем код красивым
Тут главное, чтобы это «потом» наступило.
+2
Лично знаю 2 примера, когда слишком торопливо выброшенный на рынок продукт почил в бозе, а конкуренты через полгода вышли с отлаженной схемой и загребли рынок.

Поэтому грань здесь весьма тонкая.
+1
Все написанное выше — IMHO. Интересны сторонние мнения…
Мне кажется, что автору стоило бы сделать пару уточняющих комментариев по собственному примеру.

— 1 —
Это замечательный пример «работающего» кода. Почему? Потому, что он не учитывает, что рано или поздно, наш endpoint отвалиться.


Почему бы не предположить, что в проекте выбрана такая схема обработки исключений, что исключение обрабатывается выше по цепочке, а не в самом методе Do(int x)?
Т.е., наверное, следует как-то отметить, что вызвавший код, к примеру, может сам обработать исключение. Что, если junior (а программист на опыте, вероятно, в подобных советах не нуждается), решит непременно лишний раз обработать исключение, следуя совету автора, но «потеряет» при этом call stack, написав код вида:

            try
            {// сделать что-то
            }
            catch (Exception e)
            {
                // вывести что-то в лог
                throw e;
            }


Если автор рассчитывает на не самую подготовленную аудиторию, может, стоит осветить поподробней?

— 2 — Точно так же, возможно, не стоит безапелляционно утверждать, что этот же метод обязан быть асинхронным. Возможно, метод выше по стеку (вызвавший, в конечном итоге, наш метод Do), сам вызван в отдельном потоке / Task. Тогда, вероятно, наша асинхронная версия Do всегда будет вызываться как 

    string markup = Do(42).Result;


Асинхронность всегда имеет тенденцию «подниматься вверх по стеку». Если в дизайне проекта её нет, то начинать вводить её надо не с метода Do().
+1
ТС очевидно слишком упрощает задачи/подходы в рамках «слишком общей» статьи.
Но вы правы, было бы неплохо добавить несколько абзацев с видением решения проблемы со стороны автора.
0
Очень дельные замечения. Но это больше об интеграции кода в существующий проект. А здесь мне были нужны простые примеры проблемы/решения. Но уточнить этот момент однозначно стоит, спасибо.
0
UFO landed and left these words here
Вы просто не понимаете разницу этих предлогов. Вам лишь бы какой-то из них вставить.
Наверное, надо привыкать к безграмотности, согласен :(
-4
И тут меня сразу тянет писать какие-то абстракции, какую-то инфраструктуру, чтобы оттянуть момент реальной работы.
Это называется проектирование наперед. Мне вообще непонятно почему большинство разработчиков пытаются в коде воплотить какую-то серебряную пулю, которая будет решать все проблемы на свете.
Почему нельзя написать дубово, просто и понятно. А когда потребуется поменять, то оценка времени будет точной в силу простоты кода.
На практике же напишут generic фреймворк, который по фантазиям разработчика должен решать какие-то выдуманные варианты использования, в нем будет куча защит от дурака и т.д. В результате для того, чтобы сделать простую фичу, надо выкинуть общий код который не используется, все упростить, адаптировать(отрефакторить) текущий код под новую фичу, чтобы в результате весь код смотрелся органично в текущих вариантах использования.
0
Пара ремарок:
"… наш endpoint отвалиться." -> «наш endpoint отвалится.»
… «за тесты» -> «про тесты» или «о тестах»
-1
Ваш «намёк на одессу» скорее выглядит использованием жаргонного языка…
-2
Так одесский говор и состоит из жаргонизмов, так что грань тонка.
+2
Ваше дело, конечно. Хотите выглядеть неграмотным — пишите «за тесты».
-2
Вы хотите сделать мне стыдно? Простите, это выйдет. Если бы я мог писать так же «безграмотно» как Бабель, я был бы просто в воссторге.

Давайте закроем тему.
+1
я думаю что многие знают как писать хороший код, но всегда есть такая вешь как бизнес который подгоняет разработку и тут если бизнес логика меняется сильно, нужно иногда большие куски переписать + миграция данных, а это долго и может привести к багам потому делаються хаки, потом когда рефакториться всё то многое можно пофиксить, но и тут бизнес не дремлет, наверно хороший код получается только в чисто технических проектах, где спецификация продумывается тем кто умеет писать и потому логика построения всех компонентов примерно одинакова и не меняется со временем ну и новые фичи это всеголишь расширение функционала который был изначально запланирован, построить же бизнес приложение которое которое легко менять значит писать поддержку совсем динамических данных, и тут приложение из простого моментально превращается в очень сложное
+1
Хороший код должен быть предпочтительнее плохого для хорошего бизнеса. А вот с последним таки и есть проблема, хотя бы потому, что сейчас хороший бизнес — это быстрый бизнес.

Опять же, для примера, возьмите свой код, который вы написали месяц назад и попробуйте его бегло прочесть. Вы понимаете, что там происходит? Если да — я вас поздравляю. Если нет, значит у вас проблема с читаемостью кода.

Совершенно неадекватный критерий. Например, у меня каким-то образом очень хорошая память на процесс написания кода, так что трудностей с пониманием старого кода никогда не возникало. А потом я несколько раз удивлялся, насколько же этот код идет в разрез со всеми мыслимыми метриками качества вообще.

Покрывайте сложные, высчитываемые вещи. Расчеты, преобразования, сложные мерджи данных. То, где легко ошибиться.

Опять же, практика подсказывает, что если пишешь код в вменяемом состоянии, то ошибиться в сложных вещах на порядки сложнее, чем в каких-нибудь совсем тривиальных.
0
Например, у меня каким-то образом очень хорошая память на процесс написания кода, так что трудностей с пониманием старого кода никогда не возникало


Я бы сказал, что это ваша индивидуальная особенность. Я забываю достаточно быстро. Коллеги +- так же. Отсюда и совет, который хотя и не подходит всем (например вам) но большинству подойдет.

Опять же, практика подсказывает, что если пишешь код в вменяемом состоянии, то ошибиться в сложных вещах на порядки сложнее, чем в каких-нибудь совсем тривиальных.


Согласен. Но потом приходит рефакторинг и хотелось бы быть наверняка уверенным, что код все еще работает правильно.
0
Only those users with full accounts are able to leave comments. Log in, please.

Most reading

Your account

Sections

Information

Services

Language settings
Support
© 2006–2021 «Habr»