Что считается хорошей практикой для кодирования в ситуациях «реального мира»?

Question

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

• Код отступа в теле условных операторов и циклов
• Избавление от создания новой функции из-за большого блока кода
• Закомментируйте код, используемый для отладки или может быть использован снова в будущем
• Поместите пробелы между операторами и аргументами, например, если (a <= b) func1 (arg1, arg2, arg3) </li>

Я потерял основные отметки, потому что

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

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

Answer 1

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

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

Почти во всех случаях это снижает производительность (по отношению к языкам ассемблера, которые являются лишь слоем абстракции от машинного кода). Даже некоторые вещи, которые считаются хорошей практикой в ​​объектно-ориентированном проектировании, заставляют компьютер выполнять ненужную работу, которая просто снижает производительность. Это может быть что угодно, от ненужных загрузочных хранилищ, промахов кэша (как инструкций, так и данных) из-за паршивого моделирования данных программистами. Геттеры и сеттеры попали на первое место среди регулярных ОО-проектов. И сразу после них программисты, которые не думают о том, что пишут.

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

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

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

Удачи вам!

Answer 2

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

С учетом сказанного ваши исходные правила по-прежнему применимы практически ко всем другим языкам программирования.

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

Answer 3

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

(когда я имею в виду что-то очевидное, я имею в виду другого программиста, который имеет такой же опыт, как и вы, не очевидный для случайного студента-журналиста или что-то в этом роде)

В общем, хорошие практики в любой ситуации:

1. Дайте краткий комментарий, если назначение переменной / регистра не сразу очевидно
2. Избегайте очевидных комментариев (т. Е. Говоря, что счетчик счетчика несколько избыточен)
3. В представленной работе удалите все ненужные комментарии
4. Ограничение длины строки до 80 символов (делает код аккуратным и легким для чтения)

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

Кроме того, вам не нужно инициализировать регистры, потому что они имеют известные значения по умолчанию при запуске. Учителя обычно требуют инициализации на языках более высокого уровня, поскольку в некоторых случаях это требуется, а в некоторых случаях нет, и гораздо проще (и безопаснее) просто инициализировать все. РЕДАКТИРОВАТЬ: я предполагаю, что вы работаете с платой ARM или AVR для этого последнего абзаца. Я думаю, что другие так же, но я не уверен ...

Answer 4

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

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

Answer 5

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

Это становится более странным: иногда подпрограмма будет переходить непосредственно к другой подпрограмме без возврата («хвостовой вызов»); иногда программа помещает адрес в стек, а затем возвращается из подпрограммы (т. е. выполняет инструкцию RET или RTS), не вызывая сначала подпрограмму: это позволяет переходить к большому количеству различных подпрограмм, не выполняя длинную последовательность Сравнение / ветвление операторов. Часто программы сборки имеют дату, чередующуюся с кодом, с инструкциями перехода или перехода, чтобы гарантировать, что данные никогда не выполняются (поскольку для компьютера действительный код операции является просто шестнадцатеричной последовательностью).

Это сложно и часто разочаровывает, но выгода от изучения программирования на ассемблере огромна: вы будете точно понимать, что делает компьютерная программа (и как она это делает) так, как это делают другие. Удачи!