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

[ewert]

creative в сообщении #341029 писал(а):

Думаю не только я транслит не переношу.

Дело не только в возможных конфликтах. Дело ещё и в том, что транслитирование -- абсолютно чётко различает служебные слова и лично изобретённые. Что резко облегчает чтение.

[arseniiv]

ewert в сообщении #341053 писал(а):

абсолютно чётко различает служебные слова

...их выделение полужирным начертанием или другим цветом, что поддерживается почти всеми редакторами кода — от интегрированных сред до "технических" текстовых редакторов. Если имя вдруг совпадёт со словом (хотя обычно слова полагается хоть чуть-чуть знать), не беда, можно подобрать синоним! (Лично у меня часто проблемы со словом type в Delphi, приходится писать kind.)
А читать транслит, наоборот, тяжело: мы не привыкли его читать, и потому готовых зрительных образов слов транслита у нас нет, в отличие от русского языка и, может, английского, к которому, во всяком случае, нетрудно так же привыкнуть при написании всякого кода. А если для названия переменной, класса или метода приходится лезть в словарь — разве это плохо?

-- Вт июл 27, 2010 00:40:51 --

(Оффтоп)

Sonic86 в сообщении #337702 писал(а):

Вопрос у меня к бывалым программистам - реально ли взять и все-таки сразу написать код почти весь правильно, без такого занудного тестирования, просто из головы. Или все-таки процесс такого тестирования-исправления неизбежен - все равно на него придется потратить много времени? Я все-таки думаю, что можно.

Кстати, по теме. Я тоже не "бывалый программист" (это только пока, надеюсь ), но однажды (лишь однажды) у меня получилось написать довольно простую (но не тривиальную) программу целиком безошибочно. Скомпилировалась, запустилась, и — чудо! работала как было запланировано. Я ещё тогда очень удивился и попытался найти ошибки, но тщётно. Всего однажды.

[ewert]

arseniiv в сообщении #341061 писал(а):

...их выделение полужирным начертанием или другим цветом, что поддерживается почти всеми редакторами кода

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

[arseniiv]

ewert в сообщении #341067 писал(а):

Вообще, грамотным программирование может быть -- только в асках.

Спорно! А если вы кодом захотите обмениваться с, допустим, немцем? Сразу падают транслит и ASCII. Юникод не для того придуман, чтобы его оставить в тёмном прохладном месте. Вроде бы.
К тому же, если код выделяется цветами и прочим, это не означает, что в файл добавляются символы [#0..#31] - [#9, #10, #13]. Файл остаётся чистым (надеюсь, вы это знаете и так)!
Может быть, это и вопрос вкуса, но вопросы вкуса кончаются, когда код используется не только вами.

-- Вт июл 27, 2010 01:02:45 --

ewert в сообщении #341067 писал(а):

они не содержатся в стандарте языка

Но, не правда ли, они могут весьма помочь?

[ewert]

arseniiv в сообщении #341069 писал(а):

А если вы кодом захотите обмениваться с, допустим, немцем?

И ради бога. У немца -- все аски тоже есть, даже и более есть, чем у меня.

arseniiv в сообщении #341069 писал(а):

Но, не правда ли, они могут весьма помочь?

Неправда. Цветовыделение -- размыляет сознание. Программирование в жёстких кодах тем и хорошо, что дисциплинирует: сразу видно, что можно -- а что низзя.

[arseniiv]

ewert в сообщении #341072 писал(а):

сразу видно, что можно -- а что низзя.

Извините, а нельзя ли пример? Я, видимо, уже всё размылил, что можно. И чем мешает выделение ключевых слов (допустим для чистоты, что выделяются только они).

ewert в сообщении #341072 писал(а):

У немца -- все аски тоже есть, даже и более есть, чем у меня.

И как, спрошу я вас. Вторую половину кодовой таблицы мы имеем тоже. Притом несовместимую с Latin-1. Юникод имеет раздельные коды для символов из Latin-1 и кириллицы.

Забыл сказать, что кириллические идентификаторы (как позволяют юникодные среды) мне не по душе. И идентификаторы с буквами с диактритикой — будут мешать чтению. Ну, id из иероглифов, каны или, например, деванагари тоже, естественно. Как и русские, они будут непонятны многим. А для русских проблема ещё и в том, что мы привыкли к флексии (изменении окончаний в словах), а в идентификаторах никакая флексия не допустима, и потому ещё кириллические и транслитные имена в коде будут смотреться неудобно.
Но о комментариях забывать не надо. В них допустимы бо́льшие вольности.

[Yuri Gendelman]

creative в сообщении #340989 писал(а):

Yuri Gendelman в сообщении #340985 писал(а):

'matrixOfDates' можно заменить на 'chisloSvidanij'

Мне кажется не стоит давать имена из русского языка данного транслитом. Проще давать им англоязычные имена.

Я просто привел перевод для тех, кто уже знает boy и girl, но пока не знает, что одно из значений слова date - "свидание".

-- Пн июл 26, 2010 14:26:16 --

Sonic86 в сообщении #337702 писал(а):

Вопрос у меня к бывалым программистам - реально ли взять и все-таки сразу написать код почти весь правильно, без такого занудного тестирования, просто из головы.

Народная молва приписывает одному из древних программистов (Шура-Бура ?) мысль о том, что если программа длиннее 50 строк сразу заработала, значит либо в ней алгоритм ошибочен, либо сама программа бесполезна.

[creative]

ewert

Например, если это C++ то можно использовать пространства имён, если переменная вне класса. Мой английский примитивен, но несмотря на это я стараюсь даже комментарии писать на английском (соблюдая основные правила грамматики).
Вообще любому программисту нужно всё постепенно переводить в английский язык. В идеале конечно надо владеть им как родным языком и читать книги в оригинале.

[sergey83]

А есть ли рекомендации от какого-нибудь академического института, например, института системного программирования РАН или другой научной организации?

[creative]

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

А есть ли рекомендации от какого-нибудь академического института, например, института системного программирования РАН или другой научной организации?

Рекомендации Дольда Кнута можно считать академическими, так как кроме своей известности он имеет официальный статус в научном сообществе.

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

[logout2d]

Доброго времени суток!
Постараюсь ответить покороче Не отвечая на конкретные вопросы прозвучавшие здесь, я обобщу все один ответ.
Я не профессиональный программист, но считаю себя опытным программером, это у меня хобби, около 14 лет, но на гуру не претендую. Я писал программы от "Хелло ворда" до Игровых движков с графикой, звуком и тд очень сложные (порядка 20-25 тыс. строк), этим я не хвалюсь, но это говорит о том что мой опыт хоть чего то стоит, коим я решил поделиться с вами.
Сразу скажу для примера что мою последнюю программу состоящую из 4 классов и 1000 строк я написал фактически безошибочно и особо не парился с отладкой, сразу все заработало и вообще пишу программы в принципе без косяков, ну если только я сознательно не иду на них из за лени или прочих соображений
Раньше у меня были такие ситуации когда программа усложнялась так, что наверное Вассерман без 0.5 (а то и 2л ) как говорится не разобрался бы! И приходилось тупо удалять все и кодить заново!

От демагогии к делу! Как это у меня получается?
За все время у меня выработалась четкая система правил как нужно программировать, она лично моя, для меня, вы сами решайте как вам делать!
К любой задаче я подхожу так:
Первым делом ее надо максимально осознать! И даже когда проблема ясна я не тороплюсь набивать код! Необходимо собрать максимум информации о проблеме, особенно будет ли программа совершенствоваться или она конечная, сделали раз и на всегда!
Хорошо допустим все аспекты задачи мы обварили!
Существует шутка у программистов что 70% времени они делают программу лежа на диване и лишь 30% набивая код! И это так и есть у нормальных программеров!
Крайне важно хорошо понять решаемую проблему!
Следующим шагом надо понять что мы хотим от программы! Чтобы она частично решала задачу или полностью и нужна ли она вообще!
Ну допустим нужна
Далее я проектирую "каркас" программы, состоящий из логики и интерфейса.
Я как то отошел от всяких блок схем, они только захламляют мозг!
Надо просто и ясно нарисовать абстрактную схему (без всяких правил для блок схем) КАК ВАМ ПОНЯТНО, как будет действовать программа, и на какие части она будет разделена. Будет ли это несколько программ?
Далее под эту абстрактную схему работы программы ваяем интерфейс на бумаге, прямо рисуем основные окна и тд, не надо разрисовывать досканально, главное создать каркас!
Создание каркаса существенно облегчает дальнейшее написание программы и избавляет от кучи иттераций рефакторинга, переделок и тд!
Далее по принципу разделяй и властвуй я пытаюсь разделить программу на самодостаточные модули, куски, функции. Желательно чтобы они были самодостаточны, чтобы их можно было сделать отдельно и проверить их правильность, а потом использовать.
Когда все это сделано, можно себе представить как будет работать будущая программа, погонять примеры ее использование в голове.
И только когда программа существует в таком виртуальном, А ГЛАВНОЕ КОНЦЕПТУАЛЬНО ЗАКОНЧЕННОМ, виде я приступаю к ее реализации!
Помните: программа появляется из ИДЕИ а не из кода, ударов по клаве и часов просиженных за компом!

Теперь по коду:
Важно выполнять принцип повторного использования кода! Писать так чтобы его можно было потом понять или хотя бы было понятно как его использовать.
Необходимо чтобы интерфейс классов был понятным и классы были конструктивно законченными блоками программы.
Я пишу код с четко сформулированным форматом, пользуюсь нотациями именования переменных и конструирования названий функций.
Например текст в конструкциях подразумевающих под блок (например if, for, while и тд) текста я предваряю табуляцией, чтобы этот под блок выделялся из текста программы и сам текст программы тогда приобретает некую иерархичность. Если переменная находится в классе, она должна начинаться с m_ (member) если это float то m_f, если это переменная скорости m_fSpeed. Так же можно добавлять размерность переменной метры в сек допустим m_fSpeed_ms. Таким образом применение таких нотаций позволяет легко читать код и без комментариев, которые всеже желательны в программе хотябы в ключевых точках! Ненадо его сжимать в одну строку код должен быть читабельным.
В наименованиях я так же придерживаюсь правил.
Основным является установка на первое место более важного (глобального), на последнее менее важного. Например возьмем явлоко и банан, они оба фрукты, так и формируем названия m_FruitApple и m_FruitBanan. В данном примере это излишне, но иллюстрирует подход если нужно сформировать названия для сложных по смыслу объектов. В названия не обязательно должны входить существительные, могут и глаголы и тд.
Таким образом когда я пишу код, я не задумываюсь над операторами, как бы назвать переменную, форматом и прочей шелухой, так так у меня четкая система правил написания кода я сразу мысль перевожу в код не задумываясь!
Так же когда я читаю код, он сразу переводится в мысль!
Даже сложные нагромождения с таким подходом становятся понятными и читаемыми!
Я стараюсь не делать очень длинных функций их логику сложно понимать, все стараюсь разбить на части.
Так же важно знать набор типичных конструкций кода, всякие поиски и тд.

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

Данная микро статья не претендует на полноту изложения темы.
Надеюсь хоть кому-то помог

[sergey83]

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

[Maslov]

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

А как быть в той ситуации, когда по мере кодирования необходимо вносить изменения во многих местах программы?

Переписать программу так, чтобы изменения надо было вносить только в одном месте :)

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

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

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

Ну а в Вашем конкретном случае можно осуществлять вывод с помощью

fprintf(out, ...)

а out инициализировать как

FILE *out = stdout; 

для вывода на экран или как

FILE *out = fopen(...)

для вывода в файл.

-- Пн авг 02, 2010 00:01:02 --

creative в сообщении #341159 писал(а):

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

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

[AVM]

внешняя ссылка удалена /Toucan

[Toucan]

AVM, замечание за нарушение следующего пункта Правил форума:

Цитата:

5. Внешние ссылки
...
5.2. Любая внешняя ссылка должна быть снабжена достаточно подробной аннотацией того, куда она ведет и каким образом относится к вопросу. Описание должно быть достаточным для того, чтобы читатели могли принять решение, стоит ли им переходить по данной ссылке.