Как правильно писать программы?

[AVM]

Цитата:

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

Продолжение читаем здесь.

[logout2d]

sergey83 в сообщении #341702 писал(а):

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

Я лично никогда так не делаю, с начало одно а потом что-то изменяется... Это как раз пример где вероятность возникновения ошибок велика. Что мешает сразу писать в файл, а потом проверить его правильность? Я делаю всегда так как должно быть в итоге, обычно поэтапно, но шаги не заменяются кардинально другими! Имхо вы тем самым себе создаете головную боль и дополнительную работу, потому что выгоды от такой "дебажной" замены нет никакой. Проанализируем этот кусок программы:
Допустим я предусмотрел в программе блок кода заменяющий на вывод на экран! Далее проверил результаты, все хорошо, работает. Отлично делаем программу дальше, и тут допустим мне снова надо посмотреть промежуточный результат, я переключаю на вывод на экран и программа не может дальше работать! Потому что последние апгрейды используют файл, а мы смотрим на экране, и из-за этого возникает крах программы. Тут мы понимаем что эта "дебажная" вставка ни к селу ни к городу и избавляемся от нее раз и навсегда!
Вывод: Алгоритм программы должен быть такой как мы хотим его видеть в итоговом результате! А все дебажные вставки должны быть отдельно! В примитивном случае это массаги, в более сложном виде это класс ведения лога или другие специально сделанные для этого классы.
Основной акцент в своем предыдущем посте я делал на слова "продуманность архитектуры программы", "каркас программы", "модуль программы", я еще раз говорю нужно больше продумывать это а не лепить все в один флакон!

-- Пн авг 02, 2010 15:03:22 --

Цитата:

по мере кодирования необходимо вносить изменения во многих местах программы

Данная цитата указывает на полное отсутствие понимания задачи в целом!
Поэтому и возникает необходимость вносить изменения "по мере кодирования".

[arseniiv]

А ещё есть условная компиляция...

[sergey83]

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

[Maslov]

sergey83 в сообщении #344365 писал(а):

Допустим, у программиста работающий код. Но он всё равно решил все выкинуть и написать код заново.

А почему он так решил? Ему просто заняться нечем, или к коду есть какие-то конкретные претензии? Если есть претензии, то от них, собственно, и зависит, что целесообразнее: "старых помыть или новых родить".

[sergey83]

Такой вариант. Начальник говорит: "С сегодняшнего дня наша контора аттестована по 5 классу CMM. После того, как один программист код написал, пишется отчет, код выкидывается, а по отчету эту же программу пишет другой программист." Верный путь написания программы находится путем проб и ошибок, переделываний. А второму программисту нужно только написать код по спецификации. Я ожидаю, что у него на это уйдет в 5 раз меньше времени, чем у первого программиста.

[Maslov]

sergey83 в сообщении #344391 писал(а):

Такой вариант. Начальник говорит: "С сегодняшнего дня наша контора аттестована по 5 классу CMM. После того, как один программист код написал, пишется отчет, код выкидывается, а по отчету эту же программу пишет другой программист."

Во-первых, в CMM определяются уровни, а не классы.
Во-вторых, компании с таким начальником не светит не только 5-й уровень CMM, но даже второй (первый уровень есть у всех): многократное переписывание кода заново никакой CMM не требуется. А требуется проведение регулярной процедуры анализа кода (code review), в результате которой формируется список замечаний, которые затем устраняются.

sergey83 в сообщении #344391 писал(а):

А второму программисту нужно только написать код по спецификации.

А первый что, без спецификации код писал?

sergey83 в сообщении #344391 писал(а):

Я ожидаю, что у него на это уйдет в 5 раз меньше времени, чем у первого программиста.

И на чём же Ваши ожидания основываются? Есть реальный опыт?

[sergey83]

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

[Sanyok]

Хочу добавить от себя пару слов насчет длины имен переменных. Имхо, длина идентификатора переменной или константы должна находится в прямой зависимости от ее области видимости. Чем меньше область видимости, тем меньше длина. Поэтому для коротких циклов со счетчиком, таких как for, я всегда пишу:

Используется синтаксис C++

for(int i = start; i < end; ++i)
    a[i] = ....
 

К примеру, если у указателя область видимости - тело цикла, я его назову скорее всего p или ptr, если область видимости - функция, то скорей всего это будет pointer, а если область видимости - класс или файл, то dataPointer или что-то в этом духе. Глобальным константам я обычно даю имена длинные и обязательно состоящие только из заглавных букв.

Что касается написания программ сразу и без ошибок... Да, это очень просто. Например, можно написать архиватор rar:

Используется синтаксис C++

#include <string.h>
#include <process.h>
int main(int n, char **args)
{
    strcpy(args[0], "rar.exe");
    execv(args[0], args);
    return 0;
}
 

Совершенно без ошибок! :) Мораль этой шуточной программы: чем больше используешь готового, уже отлаженного кода, тем меньше ошибок. Если же создается что-то принципиально новое, то тут, имхо, без ошибок сложно обойтись.
Хотя опять же, зависит от языка, который будет при этом использоваться. Думаю, что при написании на C или C++ на кодирование уйдет 20% времени, на отладку - 80%, а при написании на Ada на кодирование уйдет 90% времени, а на отладку - 10%. При этом общее время написания программ (включая кодирование и отладку) на разных языках будет примерно одинаковым.