ASP.NET Core Best Practices

09/14/2023

1. Cache aggressively
2. Understand hot code paths
3. Avoid blocking calls
4. Return large collections across multiple smaller pages

By Mike Rousos

This article provides guidelines for maximizing performance and reliability of ASP.NET Core apps.

Art of Readable Code

Key 1. Fundamental Theorem of Readability.

Code should be written to minimize the time it would take for someone else to understand it (Time-Till-Understanding metric).

Key 2. Packing Information into Names. Pack information into your names: 

1.   Choose Specific Words; 
2.   Finding More 'Colorful' Words, (Word Alternatives: send - deliver, dispatch, announce, distribute, route; find - search, extract, locate, recover; start - launch, create, begin, open; make - create, set up, build, generate, compose, add, new) ItТs better to be clear and precise than to be cute;
3.   Avoid Generic Names Like tmp and retval;
4.   Prefer Concrete Names over Abstract Names;
5.   Attaching Extra Information to a Name;
6.   Shorter Names Are Okay for Shorter Scope;
7.   Use Name Formatting to Convey Meaning;

Key 3. Actively scrutinize your names by asking yourself, 'What other meanings could someone interpret from this name?'

Before you decide on a name, play devil's advocate and imagine how your name might be misunderstood. The best names are resistant to misinterpretation. 

1.  When it comes to defining an upper or lower limit for a value, max_ and min_ are good prefixes to use. 
2.  For inclusive ranges, first and last are good. For inclusive/exclusive ranges, begin and end are best because theyТre the most idiomatic.
3.  When naming a boolean, use words like is and has to make it clear that itТs a boolean. Avoid negated terms (e.g., disable_ssl).
4.  Beware of usersТ expectations about certain words. For example, users may expect get() or size() to be lightweight methods.

Key 4. Aestetics vs Design: Consistent style is more important than the 'right' style.

1.   Use consistent layout, with patterns the reader can get used to.
2.   Make similar code look similar.
3.   Group related lines of code into blocks: Rearrange Line Breaks to Be Consistent and Compact; Use Column Alignment When Helpful; Break Code into 'Paragraphs'; 

Key 5. The purpose of commenting is to help the reader know as much as the writer did.

 What not to comment:

•   Facts that can be quickly derived from the code itself.
•   'Crutch comments' that make up for bad code (such as a bad function name)-fix the code instead.

 Thoughts you should be recording include:

•  Insights about why code is one way and not another ('director commentary').
•  Flaws in your code, by using markers like: TODO: Stuff I haven’t gotten around to yet; FIXME: Known-broken code here; HACK: Admittedly inelegant solution to a problem; XXX: Danger! major problem here;
•  The 'story' for how a constant got its value.

 Put yourself in the reader’s shoes:

•  Anticipate which parts of your code will make readers say 'Huh?' and comment those.
•  Document any surprising behavior an average reader wouldn’t expect.
•  Use 'big picture' comments at the file/class level to explain how all the pieces fit together.
•  Summarize blocks of code with comments so that the reader doesn’t get lost in the details.

Key 6. Making Comments Precise and Compact: Comments should have a high information-to-space ratio

1.   Avoid pronouns like 'it' and 'this' when they can refer to multiple things.
2.   Describe a function’s behavior with as much precision as is practical.
3.   Illustrate your comments with carefully chosen input/output examples.
4.   State the high-level intent of your code, rather than the obvious details.
5.   Use inline comments (e.g., Function(/* arg = */ ... ) ) to explain mysterious function
6. arguments.
7.   Keep your comments brief by using words that pack a lot of meaning.

Key 7. Making Control Flow Easy to Read: Make all your conditionals, loops, and other changes to control flow as 'natural' as possible-written in a way that doesn't make the reader stop and reread your code.

1.  In a comparison better to put the changing value on the left and the more stable value on the right.
2.   You can also reorder the blocks of an if/else statement. Generally, try to handle the positive/easier/interesting case first.
3.   Programming constructs, like ternary operator (: ?), do/while loop, and goto often result in unreadable code; usually best not to use them, as clearer alternatives almost always exist.
4.   Nested code blocks require more concentration to follow along. Each new nesting requires more context to be 'pushed onto the stack' of the reader.
5.   Returning early can remove nesting and clean up code in general. 'Guard statements' - simple cases at the top of the function are especially useful.

Key 8. Break down your giant expressions into more digestible pieces.

 a. introduce 'explaining variables' that capture the value of some large subexpression. This approach has three benefits: breaks down a giant expression into pieces; documents the code by describing subexpression with a succinct name; helps the reader identify the main 'concepts' in the code.

 b. manipulate your logic using De Morgan's laws—this technique can sometimes rewrite a boolean expression in a cleaner way (e.g., if (!(a && !b)) turns into if (!a || b)).

Key 9. How the variables in a program can quickly accumulate and become too much to keep track of. You can make your code easier to read by having fewer variables and making them as 'lightweight' as possible:

 a. Eliminate variables that just get in the way. 

 b. Reduce the scope of each variable to be as small as possible. 

 c. Prefer write-once variables. Variables that are set only once (or const, final, or otherwise immutable) make code easier to understand.

Key 10. Extracting Unrelated Subproblems: separate the generic code from the project-specific code. 

 As it turns out, most code is generic. By building a large set of libraries and helper functions to solve the general problems, what’s left will be a small core of what makes your program unique.

Key 11. One Task at a Time: 

Code should be organized so that it's doing only one task at a time (defragmenting).

 

Key 12. Turning Thoughts into Code

1.   Describe what code needs to do, in plain English, as you would to a colleague.
2.   Pay attention to the key words and phrases used in this description.
3.   Write your code to match this description.

Key 13. Writing Less Code: most readable code is no code at all 
[ Adventure, excitement-a Jedi craves not these things. ^ Yoda ]

 Each new line of code needs to be tested, documented, and maintained. Further, the more code in your codebase, the 'heavier' it gets and the harder it is to develop in.

 Avoid writing new lines of code by:

1.   Eliminating nonessential features from your product and not overengineering.
2.   Rethinking requirements to solve the easiest version of the problem that still gets the job done.
3.   Staying familiar with standard libraries by periodically reading through their entire APIs.

Key 14. Testing and Readability: Test code should be readable so that other coders are comfortable changing or adding tests.

1.   Make Tests Easy to Read and Maintain
2.   Making Error Messages Readable
3.   Pick the simplest set of inputs that completely exercise the code.
4.   Prefer clean and simple test values that still get the job done.
5.   Give your test functions a fully descriptive name so it’s clear what each is testing. Instead of Test1(), use a name like Test_<FunctionName>_<Situation>.

Appendix: Designing and Implementing

 a. First, start by coding a naive solution. This helped us realize two design challenges: speed and memory use.

 b. Next, try a 'conveyor belt' design. This design improved the speed and memory use but still wasn’t good enough for high-performance applications.

 c. Our final design solved the previous problems by breaking things down into subproblems.

CSS кнопки и псевдоэлементы

Здравствуйте, друзья. За последний месяц я экспериментировал с псевдо-элементами, особенно, с их использованием в создании кнопок. Таким образом, удалось создать крутые эффекты, которые раньше можно было сделать только со спрайтами. В этом уроке я покажу как создать кнопку с изюминкой, используя только якорный тег и мощь CSS.

7 любимых выражений программистов

«Ты же программист!»? В общем дискредитировало себя это слово.  Я как-то привык своих людей называть разработчиками (developers) и для меня программист — это эдакий антипод разработчика. Ну и с годами опыта я познал большое количество антипаттернов для хорошего разработчика, пользоваться которыми он должен как можно реже. Чем реже я их слышу, тем я счастливее. Итак, приступаем.

001. А у меня на компе работает

Эта фраза знакома всем, кто хотя бы несколько месяцев работает в индустрии и просто должна быть исключена из лексикона любого разработчика. Чувак, если ты отправляешь на тестирование код, который не работает у тебя на компе, то тебе не место в профессии! По определению у тебя на компе код всегда работает. Разве может быть иначе? А не работает он у тестировщика, клиента, да кого угодно, потому, что ты не учел какие-то нюансы, различия в окружении, данных, погоде на Марсе и твоя задача выяснить, что именно и исправить, а не пытаться сразу откосить и доказать свою невиновность. Нет ничего страшного в том, что ты чего-то не учел. В моей практике бывали случаи учесть которые мог бы только… Да никто не мог бы! 

Software disenchantment

 Source   French   Russian  

I’ve been programming for 15 years now. Recently our industry’s lack of care for efficiency, simplicity, and excellence started really getting to me, to the point of me getting depressed by my own career and the IT in general.
Modern cars work, let’s say for the sake of argument, at 98% of what’s physically possible with the current engine design. Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. All planes converged to the optimal size/form/load and basically look the same.
Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”:

@tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I’ll make my time back in 41 years, 24 days :-)

You’ve probably heard this mantra: “programmer time is more expensive than computer time”. What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time.

Гуглотех - google TeX

Прикольная функция появилась в Google.

Пишем в исходнике веб-странички в угловых скобках что-то вроде:

img src=http://chart.apis.google.com/chart?cht=tx&chl=x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}

и получаем на выходе в формате PNG что-то вроде:



После "chl=" можно вписывать любую корректную теховскую формулу разумного размера.

При этом некоторые символы, по-особому обрабатываемые в URL,
возможно, придется заменять числовыми кодами.
Например, "+" внутри формулы теряется, а "%2B" - нет.

Nine Nasty UX Truths - Девять простых UX истин

В интернетах есть множество материалов по теории UX, но советы ниже являются результатом тяжелой работы автора, что-то вроде шишек, набитых в процессе. Antoine признается, что облажался бессчётное количество раз за последние 20 лет, и описанные истины — это лишь некоторые из способов избежать провалов. Не повторяйте ошибок, наслаждайтесь.

Четыре истины о дизайне

Вообще-то это не сложно, даже в половину не так трудно, как вы думаете.

1. Цвет не имеет смысла

Пользователи не понимают вашего цветокодирования. Зеленый значит «хороший» для вас, но для кого-нибудь другого на другом экране это может значит «нечитаемое» или «гусиное дерьмо» или «Сайгон? Что? Я до сих пор в Сайгоне?». Каждый человек видит цвет исключительно по-своему, если вообще видит. Он любит одни цвета, и ненавидит другие. И это в значительной степени непредсказуемо. Вы не сможете угадать.

Цвет не является вербальным или рациональным. Он контекстен и эмоционален. Цвет — сильный инструмент, но сам по себе он не имеет смысла.

Единственное что вы можете сделать с цветами это:
Любой цвет: элемент имеет цвет
Другой цвет: элемент отличается от другого элемента
Серый: что-то сломано
Красный: дизайнер ненавидит вас и хочет разозлить