Хорошие практики в написании кода MATLAB? [закрытый]

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

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

Ну, если вы хотите это в непрофессиональных терминах:

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

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

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

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

Два хороших места для начала:

Руководство По Чистому Коду

Код-Полный

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

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

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

--

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

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

Есть много причуд в компьютерном программировании. Их сторонники считают тех, кто не следует моде, непросвещенными и не очень с ней согласными. Текущие основные причуды, кажется, "тест-драйв разработки" и "Проворный". Модой 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;
     }
   }
}

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

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

Взгляните на 97 Вещей, Которые Должен Знать Каждый Программист.
Это бесплатно и содержит много драгоценных камней, как этот:

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

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

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

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

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

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

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

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

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

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

Выше было сделано много хороших замечаний. Я определенно поддерживаю все вышеперечисленное. Я также хотел бы добавить, что орфография и последовательность в кодировании - это то, что вы практикуете (а также В РЕАЛЬНОЙ ЖИЗНИ).

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

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

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

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

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

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

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

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

2. Как делать комментарии:  помещайте комментарии, чтобы прояснить вещи в программе, которые не очевидны

3. Как произвести разложение

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

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

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

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

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

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

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

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

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

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

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

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

Never code while drunk.

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