Хорошая практика в написании кода MATLAB?

Прочитайте Code Complete, он будет творить чудеса для всего. Он покажет вам, где, как и когда имеет значение. Это в значительной степени Библия разработки программного обеспечения (ИМХО.)

Руководство по стилю программирования MATLAB от Ричарда Джонсона - хороший ресурс.

Хорошо, если вы хотите, чтобы это выполнялось непростыми словами:

Я рекомендую людям писать кратчайшую читаемую программу, которая работает.

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

Этот список может продолжаться долгое время, но некоторые важные вещи:

• Отступ.
• Имена описательных переменных.
• Описательные имена классов/функций.
• Не дублируйте код. Если ему нужно дублирование, вставьте класс/функцию.
• Использовать gettors/settors.
• Показывать только то, что необходимо в ваших объектах.
• Принцип одиночной зависимости.
• Узнайте, как писать хорошие комментарии, а не много комментариев.
• Возьмите гордость за свой код!

Два хороших места для запуска:

Руководство по чистым кодам

Code-Complete

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

-

Написание хорошего исходного кода:

• Прокомментируйте свой код.
• Используйте имена переменных длиной более нескольких букв. Между 5 и 20 - хорошее эмпирическое правило.
• Более короткие строки кода не лучше - используйте пробелы.
• Быть "умным" с вашим кодом - это хороший способ запутать себя или другого человека позже.
• Разложите проблему на свои компоненты и используйте иерархический дизайн для сборки решения.
• Помните, что вам нужно будет изменить свою программу позже.
• Прокомментируйте свой код.

В программировании много причуд. Их сторонники рассматривают тех, кто не следит за причудой, не просвещенной и не очень с ней. Нынешние основные причуды кажутся "Test Driven Development" и "Agile". Причудой в 1990-е годы было "объектно-ориентированное программирование". Изучите полезные основные части идей, которые возникают, но не будьте догматичными и помните, что лучшая программа - это та, которая выполняет работу, которую она должна выполнять.

очень тривиальный пример сверхконденсированного кода с верхней части головы

for(int i=0,j=i; i<10 && j!=100;i++){
     if i==j return i*j; 
     else j*=2;
}}

тогда как это более читаемо:

int j = 0;
for(int i = 0; i < 10; i++)
{
   if i == j 
   {
      return i * j;
   }
   else
   { 
     j *= 2;
     if(j == 100)
     {
        break;
     }
   }
}

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

Опытный программист может и будет читать оба - вышеупомянутое может заставить их сделать паузу на мгновение и рассмотреть, что происходит. Заставляя читателя сесть и посмотреть на код, это не очень хорошая идея. Код должен быть очевиден. Каждая проблема имеет внутреннюю сложность для выражения своего решения. Код не должен быть более сложным, чем сложность решения, если это вообще возможно.

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

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

Практика программирования Роб Пайка и Брайана У. Кернигана также содержит раздел о стиле, который я нашел полезным.

Посмотрите 97 вещей, которые должен знать каждый программист.
Он бесплатный и содержит много драгоценных камней, подобных этому:

Есть одна цитата, которую я считаю особенно полезно для всего программного обеспечения разработчикам знать и поддерживать их сердца:

Красота стиля, гармонии и изящества и хороший ритм зависит от простоты. - Платон

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

Есть ряд вещей, которые мы стремимся в нашем коде:

• читабельность
• ремонтопригодность
• Скорость разработки
• Неуловимое качество красоты

Платон говорит нам, что фактором для всех этих качеств является простота.

Небольшое дополнение к замечательным ответам уже здесь относительно Matlab:

• Избегайте длинных сценариев, вместо этого пишите функции (подпрограммы) в отдельные файлы. Это сделает код более читаемым и упростит оптимизацию.

• Используйте встроенные функции Matlab. То есть узнайте о многих функциях, которые предлагает Matlab, вместо того, чтобы изобретать колесо.

• Используйте секционирование кода и любую другую структуру кода, предлагаемую самой новой версией Matlab.

• Узнайте, как тестировать ваш код с помощью timeit и profile. Вы обнаружите, что иногда для циклов это лучшее решение.

Тесты устройств
Python и matlab - это динамические языки. По мере роста вашей базы кода вы будете вынуждены реорганизовать свой код. В отличие от статически типизированных языков, компилятор не будет обнаруживать "разбитые" части в вашем проекте. Используя unit test рамки, такие как xUnit, не только компенсируют недостающие проверки компилятора, они позволяют рефакторинг с постоянной проверкой для всех частей вашего проекта.

Контроль источника
Отслеживайте исходный код с помощью системы управления версиями, например svn, git или любой другой производный. Вы сможете вернуться в свою историю кода, создать ветки или создать теги для развернутых/выпущенных версий.

Отслеживание ошибок
Используйте систему отслеживания ошибок, если это возможно, связанную с вашей системой управления версиями, чтобы оставаться на вершине ваших проблем. Возможно, вы не сможете или не можете сразу исправить проблемы.

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

Все выше упомянутые
Чистые темы, связанные с кодированием, такие как использование руководства по стилю, а не дублирование кода,..., уже упоминалось.

Вы можете посмотреть онлайн-курс Стэнфорда: Методология программирования CS106A. Инструктор дал несколько действительно хороших инструкций для написания исходного кода.

Некоторые из них следующие:

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

• Как делать комментарии: добавьте комментарии, чтобы прояснить ситуацию в программе, которые не очевидны.

• Как сделать разложение

  • Один метод решает одну проблему.
  • Каждый метод имеет код приблизительно 1 ~ 15 строк
  • Дайте методам хорошие имена
  • Написать комментарий для кода

Лично я обнаружил, что я больше узнал о стиле программирования, работая через SICP, который представляет собой текст MIT Intro to Comp SCI (я занимаюсь примерно четвертью пути). Чем любая другая книга. При этом, если вы собираетесь работать на Python, руководство по стилю Google - отличное место для начала.

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

Довольно многое здесь сказано и что-то еще. На мой взгляд, лучший сайт, касающийся того, что вы ищете (особенно дзэн частей python - это весело и верно)

http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html

Обсуждает как PEP-20, так и PEP-8, некоторые пасхальные яйца (забавные вещи) и т.д.

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

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

Кроме того, не отставайте от согласованности с точки зрения именования переменных и функций. Существует много протоколов, но пока вы согласны в том, что вы делаете, другие, с которыми вы работаете, смогут лучше читать ваш код и быть благодарными за это.

Руководство по стилю Python всегда является хорошей отправной точкой!

Европейские стандарты для написания и документирования сменного кода Fortran 90 были в моих закладках, как и навсегда. Кроме того, здесь был поток, так как вы заинтересованы в MATLAB, при организации кода MATLAB.

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

Лучший совет, который я получил, когда задал этот вопрос, был следующим:

Never code while drunk.