Code Quality

Жени, помислих над това, дето си лафихме предният път относно качеството на писането на код ии реших да си го напиша в
един файл, така че да мога да ти го пратя тия дни и да го прочетеш. Приготвяй се, стабилен спам иде :D

Качествен код или добър код...Честно казано качеството на кода е директно свързано с поддръжката на продукта, който се
разработва, докато продуктивността на програмирането на кода е нарастваща спрямо времето. Докато някакви нови неща се
добавят и промени се правят, времето си минава и първият разработчик минава на друг проект или забравя някои детайли
за даденият проект, или качеството на кода ако не е добро, промените стават доста рисковани и трудни.

Като цяло смятам, че програмистите са си наистина автори или творци като целевата група не е компютъра, а други програмисти.
Това включва и самите нас като такива. Времето, което аз лично отделям да чета код, сравнено с това да го пиша е най-малко в 10 към 1 отношение.
Постоянно чета стар код, за да мога да създам нов код. Писането на изчистен код е по-лесно за разбиране и по-бързо вникване в проекта,
и е съществено за създаването на успешен и лесен за поддръжка продукт.

Има един лаф на Martin Golding: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." :D :D
Та, да де, идеята ми е, че трябва да се стремим да пишем такъв "изчистен" код, но това ти е ясно. Програмирането, честно казано, малко ми наподобява един
физичен закон, по-точно вторият закон на термодинамиката, а той гласи: "Безпорядъчността на една затворена система, която не се намира в равновесие нарастваща
с времето, като достига максималната си стойност при достигане на равновесие".

С други думи, отнема адски много труд, за да пишеш "чист" код. Трябва доста концентрация и много практика зад гърба на човека, за да се извърши това по време
на процеса. Аз лично, за да си доизпипам нещата по кода, трябваше да се отуча от навици, които ме бяха научили на разни места като училище и от четенето на
лоши примери, от които съм научавал различни програмни езици.

Честно казано, за толкова опит през годините и за тоя целият текст, който е по-горе, смятам че качественият код е до четимост. Така, че дори и малки промени
като това да смениш начина или навиците си за именуване на променливи прави доста голяма промяна, когато след време се върнеш на този код или някой друг
го гледа.

Ето няколко прости примера, които се сещам в момента:

1. Имена на променливи и методи. Също така namespace-овете са доста по-четливи, отколкото това m_, което е за member.
Кофти код:
class Example {
    private:
        std::string m_dsc;
        std::string get();
}

Добър код:
class Example {
    private:
        std::string description;
        std::string getDescription();
}

2. Използвай имена, които са лесни за казване.

Кофти код:
auto genymdhms = time(NULL);
auto modymdhms = time(NULL);

Добър код:
auto generationTimestamp = time(NULL);
auto modificationTimestamp = time(NULL);

3. Може би, най-важната част, бъди постоянна в именоването. Не използвай двете, за да извършваш едно и също нещо в различни класове.

Пример:
    class HTTPRequest {
        public:
            virtual auto get() -> std::string = 0;
    }

    class HTTP2Request {
        public:
            virtual auto fetch() -> std::string = 0; // Прави същото като горният пример
    }

4. Използвай терминология. Другите програмисти мисля, че ги знаят, ако не, за тях си е.

Пример:
    По-добре е да е requestQueue, отколкото requests, като име на променлива.

5. Използвай действията на променливата, за да дефинираш метод. Разбира се, ако идват много дълги, просто разбиваш на подметоди.

Пример:

class Product {
    private:
        double price;

    public:
        inline auto increasePrice(double amountToAddToPrice) -> void {
            this->price += amountToAddToPrice;
        }
}

6. Фунцкиите. Тук ще посъкратя малко
    - Колкото по-малка е една функция, толкова по-добре
    - Функцията трябва да прави само едно нещо
    - Колкото по-малко аргументи, толкова по-добре. Повече от три аргумента, вече става too much.

        Пример:

            Кофти код:
                Circle makeCircle(double x, double y, double radius)

            Добър код:
                Circle makeCircle(Point center, double radius)

    - Без странични неща. Функциите трябва да правят това, което името им казва.
    - Избягвай изхода, освен ако не е return на фунцкията. Ако един return не ти стига, значи функцията не прави едно единствено нещо.

        Пример:

            Кофти код:
                addSignature(email);

            Добър код:
                email.addSignature()

    - Error handling-а най-добре да става чрез exception-и. По-добре да се връщат exception-и и да се прихващат чрез try/catch, отколкото return code-ове.

7. Коментари
    - Не коментирай кофти код, просто го пренапиши.
    - Ако кодът е четим, не са ти нужни изобщо коментари.

        Пример:

            Кофти код:
                // Check to see if the student is eligible for benefits
                if(student->flags && ELIGIBILITY_FLAGS::HOURLY_FLAG && student->age > 20)

            Добър код:
                if(student->isEligibleForBenefits())

    - Ако ти се налага да коментираш, направи го така, че да изразиш какво си искала да направиш или предупреди хората
        Пример:
            // if we sort the array here, the logic becomes simpler in calculateAge() method
            // this operation may take a very long time to run
    - Използвай коментари, от които може да бъде изведена документация. Например doxygen. Други коментари би било добре да се избягват.
        Пример:
            /**
              * Sum numbers in a vector.
              *
              * This sum is the arithmetic sum, not some other kind of sum that only
              * mathematicians have heard of.
              *
              * @param values Container whose values are summed.
              * @return sum of `values`, or 0.0 if `values` is empty.
              */
            double sum(std::vector<double> & const values) {
                ...
            }

Като цяло, това е което исках да споделя като опит. Други неща, за които можеш да се оглеждаш и да разбереш, че не са като хората са неща като:
    - Големи класове
    - Един главен обект и много дъщерни
    - Многоезичност в един файл
    - Прекалено използване на static
    - Hardcode-ване
    - Прекалено много наследявания
    - Последователно свързване - Когато един клас изисква методите си да бъдат извикани в дадена последователност.
    - Затворени цикли от референции и/или изисквания на библиотеки/класове/разни други неща.

Абе, трудничко си е, но определено си струва всяка една секунда от този труд, който полагаш. Хората след теб ще ти се кланят, защото си оставила
чист и подреден код, който те разбират с лекота. Пък и, както казах в началото на спама, доста съществена част е в успеха на проекта.

Извинявай за спама, няма проблем ако не си съгласна с нещата, които съм написал. Даже, ако искаш можем да ги обсъдим, хаха. Поздрави