uz
Feedback
Clean Code

Clean Code

Kanalga Telegram’da o‘tish

Советы по написанию кода, обзоры распространенных ошибок и многое другое. Ссылка: @Portal_v_IT Сотрудничество: @oleginc, @tatiana_inc РКН: clck.ru/3Ht6ch

Ko'proq ko'rsatish

📈 Telegram kanali Clean Code analitikasi

Clean Code (@codeclean) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 12 233 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 10 263-o'rinni va Rossiya mintaqasida 53 498-o'rinni egallagan.

📊 Auditoriya ko‘rsatkichlari va dinamika

невідомо sanasidan buyon loyiha tez o‘sib, 12 233 obunachiga ega bo‘ldi.

02 Iyul, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -84 ga, so‘nggi 24 soatda esa -5 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.

  • Tasdiqlash holati: Tasdiqlanmagan
  • Jalb etish (ER): Auditoriya o‘rtacha 4.81% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 3.15% ini tashkil etuvchi reaksiyalarni to‘playdi.
  • Post qamrovi: Har bir post o‘rtacha 589 marta ko‘riladi; birinchi sutkada odatda 385 ta ko‘rish yig‘iladi.
  • Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 0 ta reaksiya keladi.
  • Tematik yo‘nalishlar: Kontent clean, собеседование, sql, программирование, golang kabi asosiy mavzularga jamlangan.

📝 Tavsif va kontent siyosati

Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
Советы по написанию кода, обзоры распространенных ошибок и многое другое. Ссылка: @Portal_v_IT Сотрудничество: @oleginc, @tatiana_inc РКН: clck.ru/3Ht6ch

Yuqori yangilanish chastotasi (oxirgi ma’lumot 03 Iyul, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.

12 233
Obunachilar
-524 soatlar
-227 kunlar
-8430 kunlar
Postlar arxiv
Compact Functions Компактные функции. Есть всего два привила. Первое: функции должны быть компатными. Второе: функции должны быть еще компактнее. Лучше 10 функций по 20 строк, чем один монстр на 200 строк. Чем компактнее вы будете писать свои функции, тем более примитивными и очевидными они будут казаться для читающего. #functions

Dependency Inversion Principle Суть принципа инверсии зависимостей проста: заменить композицию агрегацией. Вместо создания зависимостей напрямую, класс должен требовать их у более высокого уровня через аргументы метода или конструктора. При этом зависимость должна передаваться не в виде экземпляров конкретных классов, а в виде интерфейсов или абстрактных классов. Подробнее вы можете прочитать в статье. S O L I D #solid

Ad Hominem Переход на личности. Инспектируйте программу, а не программиста. Замечания о его личности лишь усложняют восприятие им критики. Если вы пишите негативные комментарии, пишите «патч» или «код» вместо «ты». Например, вместо "У тебя глюк в get_message" пишите "После применения этого патча в get_message появился глюк" #cleancode

Dublication Дублирование. Каждый раз, когда в программе встречается повторяющийся код, он указывает на упущенную возможность для абстракции. Возможно, дубликат мог бы стать функцикй или даже отдельным классом. "Сворачивая" дублирование в подобные абстракции, вы расширяете лексикон языка программирования. Другие программисты могут воспользоваться созданными вами абстрактными концепциями. Повышение уровня абстракции ускоряет программирование и снижает вероятность ошибок. #tips

Interface Segregation Principle Принцип разделения интерфейса. Создавайте узкоспециализированные интерфейсы, предназначенные для конкретного клиента. Клиенты не должны зависеть от интерфейсов, которые они не используют. S O L I D #solid

Function arguments Аргументы функции. Ограничение количества параметров функции невероятно важно, поскольку оно упрощает тестирование функции. Наличие более чем трёх аргументов приводит к комбинаторному взрыву, когда вам приходится перебирать массу различных случаев с каждым отдельным аргументом. Идеальная ситуация — отсутствие аргументов. Один или два аргумента — хорошо, а трех уже следует избегать. #functions

Group the blocks by meaning Группируйте блоки по смыслу. Используйте психологический эффект восприятия — «Эффект близости»: близко расположенные фигуры при восприятии объединяются. Получить код, подготовленный для анализа и обобщения можно, расположив рядом строки, объединенные смыслом или близкие по функционалу, разделив их пустой строкой. #formatting

Liskov Substitution Principle Принцип подстановки Барбары Лисков. Цель этого принципа заключаются в том, чтобы классы-наследники могли бы использоваться вместо родительских классов, от которых они образованы, не нарушая работу программы. Если оказывается, что в коде проверяется тип класса, значит принцип подстановки нарушается и вам следует пересмотреть свое решение. #solid

photo content

Avoid positional markers Избегайте позиционных маркеров. Они обычно просто добавляют шум. Позвольте функциям и именам переменных вместе с правильными отступами и форматированием придать визуальную структуру вашему коду. #comments

Quality your working WakaTime - сервис, который считает Ваше рабочее время. Большой плюс данного сервиса в том что он сам включается когда Вы начинаете писать код, и сам видит когда Вы ушли. Он умеет логировать самую разную информацию, от количества рабочих часов над проектом, до составления графика об использовании языков программирования. #work #quality #apps

Readme Driven Development RDD — это крайне простая практика. Пишите Readme в первую очередь, вот в принципе и все. A какие приемущества это вам даст читайте в статье. #architecture

Don't ignore caught errors Не игнорируйте обнаруженные ошибки. Ничего не делать с обнаруженной ошибкой не дает вам возможности исправить или отреагировать на указанную ошибку. Вывод ошибки на консоль (console.log) не намного лучше, так как часто он может потеряться в море других вещей, напечатанных на консоли. Если вы добавляете какой-либо фрагмент кода в try / catch, это означает, что вы думаете, что там может произойти ошибка, и поэтому вам нужно правильно на нее отреагировать. #errors

Favor functional programming over imperative programming Отдавайте предпочтение функциональному программированию над императивным. Функциональные языки программирования могут быть чище и проще для тестирования. Используйте этот стиль, когда сможете. Однако нужно быть предельно осторожным и хорошо понимать, что делает функция и как именно она выполняется, иначе это может привести к накладным расходам. #functions

Используйте значимые и произносимые имена переменных. #variables

Open-Closed Principle Принцип открытости-закрытости Программные сущности (классы, модули, функции) должны быть открыты для расширения, но не для модификации. Рассмотрим простой пример ниже. При добавлении нового Animal придётся дополнять код функции AnimalSound. Если подобная архитектура используется в реальном проекте, функцию придётся постоянно расширять, добавляя в неё новые выражения if. Решение: У каждого класса, описывающего животного, будет собственный метод MakeSound и, к примеру, при переборе массива с животными достаточно будет вызвать метод MakeSound для каждого элемента массива. #cleancode #solid

photo content

Все хотят иметь дело только с понятным чистым кодом. Но не все могут его создавать. Версия для C#, проверь себя! Clean Code Game #cleancode #apps

Solid. Single Responsibility Principle Принцип единственной ответственности. Класс должен быть ответственен лишь за что-то одно. Если класс отвечает за решение нескольких задач, его подсистемы, реализующие решение этих задач, оказываются связанными друг с другом. Изменения в одной такой подсистеме ведут к изменениям в другой. Правильное применение принципа единственной ответственности приводит к высокой степени связности элементов внутри модуля, то есть к тому, что задачи, решаемые внутри него, хорошо соответствуют его главной цели. #codeprinciples #solid

Ballast Балласт. Какая польза от конструктора по умолчанию, не имеющего реализации? Он только попусту загромождает код. Неиспользуемые переменные, невызываемые функции, бессодержательные комментарии - все это бесполезный балласт, который следует удалить. Поддерживайте чистоту в своих исходных файлах, следите за их структурой и не допускайте появления балласта. #cleancode