Написание устойчивого и “современного” кода Фортрана

Fortran 90/95/2003 спроектирован таким образом, чтобы можно было писать модульный код, если он хочет, путем добавления модулей, частных / общедоступных, определяемых пользователем типов и т. Д. Fortran 2003 вводит дополнительные объектно-ориентированные функции. Нет смысла подключаться к C для добавления malloc, когда Fortran 90 имеет "allocate" для прямого динамического выделения массивов Fortran более безопасным способом. Размещение ваших процедур (функций и подпрограмм) в модулях, а затем «использование» модулей приведет к проверке интерфейсов. Можно использовать многие параметры отладки / проверки компиляторов, такие как проверка границ индекса.

Отличная книга, чтобы узнать об этих и других особенностях: «Объяснение Fortran 95/2003» Меткалфа, Рида и Коэна. Определенно лучше изучить лучшие возможности современного Фортрана, чем продолжать писать FORTRAN 77 - при необходимости напишите стандарты / руководство по кодированию.

Я предлагаю OP отказаться от мнения, что Фортран - это что-то неприятное в высокопроизводительных научных вычислениях, и с энтузиазмом погрузится в него. Если OP сохранит этот довольно пренебрежительный настрой, то вся его карьера программиста на Фортране будет нелегкой. И действительно, вы не можете сделать с Фортраном ничего такого, чего нельзя было бы сделать с C ++, так что зачем беспокоиться, если вы действительно этого не хотите?

В списке маркеров OP нет ничего такого, что многие из нас, кто работал с Фортраном в течение последних 30 лет не работал (с тех пор, как компиляторы Fortran 90 стали широко доступны, но некоторые из них были и раньше). Да, есть ученые-вычислители и инженеры-программисты, которые разбираются в указателях, знают, что многие (заблуждающиеся) люди начинают считать с 0 и что глобальные переменные - ПЛОХО.

Как и @MSB, я бы порекомендовал книгу Меткалфа и др. как источник информации о возможностях и особенностях современного Фортрана. И, как и @MSB, я удивляюсь идее использования C или C ++ для обертывания библиотек, для которых есть либо эквиваленты Fortran, либо более совершенные подходы. Совместимость стандарта 2003 с функциями C, реализованными в Intel Fortran, упрощает прямой вызов библиотек C.

Я бы не согласился с OP, что модульный код - это самоцель. Я предлагаю следующие цели: правильный, проверяемый и проверяемый, надежный и надежный код. Модульность - это один из способов поддержки достижения этих целей, но это тактика, а не конечная точка.Если бы я думал, что мы можем писать хорошие (в вышеупомянутом смысле) программы, содержащие 10 ^ 6 строк кода без модульности, я бы не стал беспокоиться о модульности.

Хорошо, теперь несколько конкретных советов по добавлению к тому, что OP уже намеревается делать или что ему было сказано:

• используйте KIND в объявлениях переменных, чтобы обеспечить требуемую точность; не оставляйте это на усмотрение параметров компилятора или предположений о том, что этот компилятор может делать с этим процессором;
• используйте операции с массивами везде, где это возможно, а не явные циклы; это помогает сделать код более безопасным - иногда за счет производительности, но вам нужно проверять это в каждом конкретном случае;
• напишите функции PURE;
• не зависят от препроцессоров или других не -Fortran подходит к правильности кода (и т. Д.), Напишите свои утверждения и предварительные условия (т. Д.) На Фортране; препроцессоры (и т. д.) не выживут до тех пор, пока хорошо написанные программы Fortran будут серьезным препятствием для переносимости сейчас и в будущем;
• если у вас есть доступ к Intel Fortran, получите доступ к Intel MKL (и IPP ) и использовать эти библиотеки вместо того, чтобы писать свой собственный код;
• планируют использовать OpenMP и MPI для распараллеливания, они оба очень хорошо подходят для Фортрана; о, и планируйте как можно скорее перейти к параллельному программированию, это намного интереснее, чем последовательное программирование;
• этот набор стандартов кодирования Fortran - хорошее начало, но, вероятно, не более того; 1-е издание Code Complete содержало гораздо больше о программировании на Фортране (77), чем текущее издание, но большинство его советов можно применить на любом языке, на котором вы пишете.

И, наконец, в наши дни я думаю, что программы и программисты на Фортране лучше осведомлены об идеях функционального программирования, чем идеях объектно-ориентированного программирования.

Я очень тороплюсь, поэтому простите меня, если я оформлю этот ответ в виде контрольных точек вместо разумных предложений.

• попробуйте придерживаться стандарта (Fortran - стандартизированный язык, и, придерживаясь стандартных возможностей языка и избегая расширений, специфичных для конкретного производителя, вы получите переносимую между платформами программу, для которой, вы можете быть уверены, компилятор не создаст проблем). Я не знаю, где я скачал свою копию, но я уверен, что вы можете скачать последнюю редакцию (будьте осторожны; многие возможности fortran 2008 или 2003, если на то пошло, все еще не реализованы в правильном компиляторе, хотя многие почти реализованы в настоящее время... Cray - один из них) со страницы J3
• Для всех вопросов, касающихся вышеупомянутого, я сердечно рекомендую comp.lang.fortran usenet-группу - там не только есть очень знающие люди (например, мистер Ричард Мейн ... вероятно, будет готов ответить на любые вопросы о соответствии стандартам, которые вы можете задать, с большим количеством деталей, если попросите вежливо ... то же самое касается и многих других), но там также есть люди, которые работали над крупномасштабными проблемами и наверняка знают и готовы дать совет по вашей теме
• Книги - в дополнение ко всем уже упомянутым (книга Меткалфа, Рида и Коэна также имеет мою рекомендацию, также "Fortran 2003 handbook" Мэна и других ...), попробуйте найти себе копию книги Стивена Дж. Чепмена "Fortran 95/2003 для ученых и инженеров" ...
• также, не знаю, сталкивались ли вы с этой книгой "Object oriented programming via Fortran 90/95"

Некоторые комментарии к вашему тексту:

(Все это может показаться "очевидными" современными предположениями программирования, но в мире фортрана, большинство из которых являются большими изменениями в типичном рабочем процессе программиста)

Даже в мире современного фортрана, некоторые из этих предположений сомнительны. ... помните, программисты на фортране - это не программисты (я повторяю это в сжатой форме; я уже столько раз писал об этом на этом форуме), а инженеры, ученые и так далее. Для них (нас?) код - это не цель, а просто инструмент... для профессиональных программистов код - это все, у них нет ничего "вне его"... поэтому они так дорожат им. Для нас, инженеров, это всего лишь средство получения желаемого результата... исходя из этого, хотя хорошие практики программирования окупаются впоследствии, не стоит настаивать на них там, где в них нет очевидной необходимости".

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

Кто-то однажды сказал, и вы не поверите, насколько это правда:
"Нет ничего более постоянного, чем временное решение".

Какие-нибудь хорошие URL, советы, справочники/книги по этому вопросу?

Учитывая несколько вышеперечисленных.

Также, пока писал этот ответ, я увидел, что High Perf. Mark опубликовал очень хороший ответ, с которым я в основном согласен... он немного подробнее описывает соблюдение стандартов.

Также, моя рекомендация - определенно разместить этот вопрос на comp.lang.fortran ... Я полагаю, что там можно получить гораздо более качественные ответы, чем здесь (я полагаю, что на всем stackoverflow не более 20 или около того программистов на фортране).

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