понедельник, 24 июля 2023 г.

[prog.c++.flame] Написать работающий код не фокус, фокус написать этот код нормально

Давным-давно, еще на первом курсе нам, студентам-программистам, рассказали, что главное требование к программе -- это ее работоспособность. Т.е., программа должна работать, это главное. Все остальное (включая ресурсоемкость, понятность и сопровождабельность кода) вторично.

Однако, мне думается, что это главное требование к программе многими сейчас воспринимается как исключительная доблесть (исключительная еще и в том смысле, что исключается и все остальное). Т.е. если я написал работающий код, то я уже молодец.

Но, как по мне, написать работающий код -- это вовсе и не доблесть, и не достижение. Это нормально. Только когда код начинает работать так, как задумывалось, только тогда и начинается предметный разговор.

А раз главное требование выносится за скобки (ну реально, а какой смысл рассматривать код, который не работает?), то остается все остальное. От чего многие любители писать "просто работающий код" либо отмахиваются, либо вообще не осознают.

В частности, есть такие вещи как корректность, надежность, понятность и сопровождаемость кода. И, как по мне, основной фокус при программировании вовсе не в том, чтобы написать код, который работает. А в том, чтобы работающий код оказался корректным, надежным, понятным и сопровождаемым.

Но когда встречаешь в коде что-то вроде:

class data_holder {
    opaque_data * data_;

public:
    data_holder() {
        data_ = make_data(); // Упс №1.
        if(-1 == init_data(data_)) { // Упс N2.
            throw std::runtime_error{"unable to initialize data"};
        }
    }
    ~data_holder() {
        destroy_data(data_);
    }

    void do_something();
};

или что-то вроде:

bool try_do_something() {
   ... // Какие-то действия.
   int r = call_some_pure_c_function();
   if( !r ) {
       revert_some_changes();
       return -1; // Упс №3.
   }
   ... // Еще какие-то действия.
   return true;
}

или читаешь вопрос вроде вот такого (Упс №4), то...

...у меня в последнее время нехило бомбит. Поскольку пофиг на ошибки, которые происходят из-за элементарной невнимательности. Но ведь многое из того, что попадается на глаза происходит из-за нежелания изучать инструмент и, особенно, нежелание (неумение) следовать практикам более безопасного использования этого инструмента. Вот что особенно удручает.


Упс №1. Результат make_data следовало бы проверять, т.к. может быть возвращен и nullptr.
Упс №2. При таком раскладе деструктор у data_holder вызван не будет. Соответственно, destroy_data так же не будет вызван.
Упс №3. Должно быть true или false, а не -1. И да, тот же GCC по рукам за такое не бьет.
Упс №4. Я на полном серьезе полагаю, что если кому-то платят за разработку на C++, то такие вопросы должны решаться самостоятельно.


Все совпадения с реальным кодом случайны и непреднамеренны.

6 комментариев:

Stanislav Mischenko комментирует...

> И, как по мне, основной фокус при программировании вовсе не в том, чтобы написать код, который работает. А в том, чтобы работающий код оказался корректным, надежным, понятным и сопровождаемым.

В программировании то конечно, вопрос в том есть ли на это спрос. Насколько я могу судить сейчас больше популярно мнение, что если заменить, к примеру, несчастные плюсы на что-нибудь ещё, то все проблемы решатся сами собой. Также я встречал такие решения типа отдать код на аудит, либо послать своих программистов не туда, куда вы возможно подумали, а на курсы. Подобные решения менее популярны чем замена языка программирования, ибо тут надо сразу раскошелится. К тому же они все относительно бесполезны, если в компании уже не заведено ставить во главу угла именно корректность, надёжность, понятность кода.
Припоминается случай, когда программистов уволили из одной компании, на основании их низкой активности в Jira (или другом подобном инструменте, не суть). То есть именно так бизнес смотрит на программистов. Заявления типа, за то у меня код красивый, тут не сработают.

eao197 комментирует...

@Stanislav Mischenko

Плюсы -- это просто наиболее яркий пример, т.к. здесь просчеты быстро бьют по рукам.

Я уверен, что если бы плотно пропрограммировал на Java/C#/Go в течении полугода-года, то с неменьшей частой бы обнаруживал косяки в Java/C#/Go коде.

Stanislav Mischenko комментирует...

@eao197

На мой взгляд дело не в количестве косяков, а в пороге вхождения. Языки навроде Java и C# (на этих языках я много писал) требуют меньшего объёма знаний, чтобы на них писать на приемлемом уровне.

eao197 комментирует...

@Stanislav Mischenko

Я своим постом как бы возражаю против приверженности такой вещи, как "приемлемый уровень". Особенно когда этот уровень реально низок.

Stanislav Mischenko комментирует...

@eao197

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

eao197 комментирует...

@Stanislav Mischenko

Я бы не сказал, что не нужен, и что не бьет.

Он-то как раз бьет, но это битьё отложенное, его стоимость размазывается на стоимость саппорта и сопровождение. Но вот подсчитать это, похоже, готовые не многие.

Не говоря уже про то, что вообще люди, которые программируют кое как, вряд ли принимают хорошие решения в процессе проектирования/написания программы. По крайней мере мне так кажется.