Почему загадочные короткие идентификаторы все еще так распространены в низкоуровневом программировании?

64

Раньше были очень веские причины для краткости названий инструкций / регистров. Эти причины больше не применяются, но короткие загадочные имена все еще очень распространены в низкоуровневом программировании.

Почему это? Это просто потому, что старые привычки трудно сломать, или есть более веские причины?

Например:

  • Atmel ATMEGA32U2 (2010?): TIFR1(Вместо TimerCounter1InterruptFlag), ICR1H(вместо InputCapture1High), DDRB(вместо DataDirectionPortB) и т. Д.
  • Набор команд .NET CLR (2002): bge.s(вместо branch-if-greater-or-equal.short) и т. Д.

Не проще ли работать с длинными, не зашифрованными именами?


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

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

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

Роман Старков
источник
82
Ответ: Чтобы вы почувствовали, что вы программируете на языке низкого уровня.
Томас Эдинг
5
Загадочный относительный. JSRв три раза длиннее, чем код операции, который он представляет ( $20на 6502), и значительно проще для понимания с первого взгляда.
Blrfl
4
Я немного разочарован, потому что правильный ответ есть, но он определенно не принят. С принципиальными схемами и такими прерываниями обычно присваивают имена линиям, с которыми они связаны, а на принципиальной схеме вы не хотите многословно, это не является хорошей практикой или практикой. Во-вторых, если вам не нравятся ответы, это не значит, что они не верны.
Джефф Лангемайер
4
@gnat: попробовать set Accumulator32 to BaseIndex32? Простое расширение традиционных аббревиатур - не единственный способ сделать что-то более читабельным.
Тимви
1
«если ваш основной аргумент касается физического пространства на бумажной диаграмме», то нет, речь идет о том факте, что хорошее именование учитывает не только ясность названия, но и другие вещи (я привел некоторые в своем ответе диаграммы, в том числе нарисованные на доска - это только одна из этих вещей), и это уточнение является относительной вещью (знакомство имеет тенденцию помогать ясности, какой бы выбор ни был, например).
AProgrammer

Ответы:

106

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

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

Таблица TIFR1 из таблицы

Кроме того, такие вещи, как схемы, схемы выводов и шелкографии на печатных платах, часто очень ограничены в пространстве.

Карл Билефельдт
источник
7
Кроме того, этот ответ на самом деле не касается чисто программной стороны, например, CLR, JVM, x86 и т. Д. :)
Timwi
12
@romkyns: немного более очевидно, почему они использовали эти короткие имена, когда вы на самом деле читали эти таблицы. Таблицы данных по имеющемуся у меня микроконтроллеру составляют около 500 страниц, даже при использовании кратких названий . Ширина таблиц будет охватывать несколько страниц / экранов, если мы будем использовать более длинные имена, что делает их очень неудобными для использования в качестве ссылки.
In silico
27
@romkyns: более длинные имена одинаково доступны для поиска, но они «не родные». Если вы прислушиваетесь к инженерам по встраиванию, они на самом деле говорят: «Тиффер ноль», а не «флаг прерывания нуля таймера». Я сомневаюсь, что веб-разработчики также расширяют HTTP, HTML или JSON в именах своих методов.
TMN
6
@KarlBielefeldt э-э, что? :) Очевидно, я не найду его в текущей таблице данных, потому что вместо этого они использовали короткое имя. Это не поддерживает утверждение, что короткие имена более доступны для поиска при малейшем ...
Роман Старков
5
Это не просто таблицы данных, которые ограничены в пространстве, это схемы. Все эти логические компоненты имеют выводы, которые необходимо подключить к другим компонентам. «TimerCounter1InteruptFlag.clear» не помещается поверх крошечного проводного представления почти так же, как «TCIF.C»
AShelly
60

Закон Ципфа

Посмотрев на этот текст, вы сами увидите, что длина слова и частота употребления, как правило, обратно пропорциональны. Слова, которые используются очень часто, как it, a, but, youи andочень короткие, в то время как слова, которые используются реже нравится observe, comprehensionи verbosityбольше. Эта наблюдаемая связь между частотой и длиной называется законом Ципфа .

Количество команд в наборе команд для данного микропроцессора обычно исчисляется десятками или сотнями. Например, кажется, что набор команд Atmel AVR содержит около сотни различных инструкций (я не считал), но многие из них являются вариациями на общую тему и имеют очень похожую мнемонику. Например, инструкции умножения включают в себя MUL, MULS, MULSU, FMUL, FMULS и FMULSU. Вам не нужно долго просматривать список инструкций, прежде чем вы получите общее представление о том, что инструкции, начинающиеся с «BR», являются ветвями, инструкции, начинающиеся с «LD», являются нагрузками и т. Д. То же самое относится и к переменным: даже сложные процессоры предоставляют ограниченное количество мест для хранения значений: регистры условий, регистры общего назначения и т. д.

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

Кроме того, наборы команд для разных процессоров часто используют одинаковые имена для похожих операций. Большинство наборов команд включают операции для ADD, MUL, SUB, LD, ST, BR, NOP, и если они не используют эти точные имена, они обычно используют имена, которые очень близки. Как только вы изучите мнемонику для одного набора команд, адаптация к наборам команд для других устройств не займет много времени. Так имена , которые могут показаться «загадочными» к вам о том, как знакомые , как такие слова , как and, orи notдля программистов, специалисты в данной области техники программирования низкого уровня. Я думаю, что большинство людей, которые работают на уровне сборки, скажут вам, что обучение чтению кода не является одной из самых больших проблем в низкоуровневом программировании.

Калеб
источник
2
спасибо Калеб! Для меня этот превосходный ответ спас вопрос, который каким-то образом сумел собрать четыре оценочных суждения в одном названии: «загадочный», «короткий», «неподвижный», «такой общий»
комнат
1
Спасибо, @gnat, за ваш комментарий и ваш щедрый бонус.
Калеб
37

В общем

Качество именования - это не только наличие описательных имен, оно также должно учитывать другие аспекты, и это приводит к рекомендациям, таким как:

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

Обратите внимание, что эти рекомендации противоречивы.

Инструкция по мнемонике

Как программист на ассемблере, использование short-branch-if-greater-or-equalfor bge.sдает мне то же впечатление, что и когда я вижу, как программист Algol SUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSвместо вычислительной геометрии dx := p2.x - p1.x. Я просто не могу согласиться с тем, что первые из них более читабельны в контексте, о котором я забочусь.

Зарегистрировать имена

Вы выбираете официальное название из документации. Документация выбирает имя из дизайна. В дизайне используется множество графических форматов, в которых длинные имена не подходят, и команда разработчиков будет жить с этими именами месяцами, если не годами. По обеим причинам они не будут использовать «Флаг прерывания счетчика первого таймера», они будут сокращать его как в своей схеме, так и при разговоре. Они знают это и используют систематические сокращения, TIFR1чтобы избежать путаницы. Здесь TIFR1важно отметить, что это не случайное сокращение, а результат схемы именования.

AProgrammer
источник
4
Действительно TIFR1ли лучшая схема именования, чем InterruptFlag1если бы, или IptFlag1если вы действительно должны быть короткими?
Тимви
4
@Timwi, InterruptFlagи IptFlagлучше, чем так IFже, как EnumerableInterfaceи ItfcEnumerableлучше, чем IEnumerable.
AProgrammer
@AProgrammer: я считаю ваш ответ и ваш комментарий лучшим, и я бы пометил его как принятый, если бы мог. Те, кто считает, что только физические ограничения диктуют короткие имена, ошибаются. Эта дискуссия будет вам интересна: 37signals.com/svn/posts/…
alpav
5
@alpav Вы понимаете, что ваша ссылка утверждает противоположное тому, что говорит этот ответ? Во всяком случае, это полностью поддерживает InterruptFlag1по причинам лучшей ясности.
Роман Старков
24

Помимо причин «старых привычек», код Legacy, написанный 30 лет назад и до сих пор используемый, очень распространен. Несмотря на то, что думают некоторые менее опытные люди, рефакторинг этих систем, чтобы они выглядели красиво, стоил очень дорого за небольшую выгоду и не был коммерчески выгодным.

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

Насколько bge.sэто похоже на ассемблер - тем немногим, кому нужно это знать, более длинные имена менее читабельны. Если вы не можете заставить себя bge.sзадуматься и думаете, что branch-if-greater-or-equal.shortэто что- то изменит - вы просто играете с CLR и не знаете этого.

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

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

mattnz
источник
Если я понял аргумент, который вы используете для защиты "bge.s", TIFR1он более читабелен для тех, кто должен это знать, чем TimerCounter1InterruptFlag, правильно?
Роман Старков
2
@romkyns: Абсолютно - в этом случае меньше значит больше .... В отличие от CNTR, который может означать «Счетчик», «Контроль», «Не удается проследить маршрут» и т. д., T1FR1 Точно определенное значение.
Mattnz
«Если вы не можете обойтись с bge.s и думаете, что branch-if-большее-или-equal.short будет иметь значение - вы просто играете с CLR и не знаете этого». Я не знаю об этом. Я хорошо понимаю сборку x86, но каждый раз, когда я пишу цикл, я должен посмотреть, что означают все j?инструкции . Наличие более явно названной инструкции определенно помогло бы мне. Но, возможно, я скорее исключение, чем правило. У меня проблемы с запоминанием мелких деталей.
Коди Грэй,
11

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

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

Так почему загадочные короткие идентификаторы так распространены в низкоуровневом программировании?

  • Потому что многие из них достаточно распространены в соответствующей области, чтобы гарантировать очень короткое имя. Это ухудшает кривую обучения, но является ценным компромиссом, учитывая частоту использования.
  • Потому что обычно есть небольшой набор исправляемых возможностей (программист не может добавить в набор).
  • Потому что читабельность - это вопрос привычки и практики. branch-if-greater-than-or-equal.shortявляется изначально более читаемым , чем bge.s, но с некоторой практикой ситуация становится обратной.
  • Потому что их часто приходится печатать полностью вручную, потому что языки низкого уровня часто не поставляются с мощными IDE, которые имеют хорошее автозаполнение, или / c не является надежным.
  • Потому что иногда желательно упаковать много информации в идентификатор, а читаемое имя будет недопустимо длинным даже по стандартам высокого уровня.
  • Потому что именно так исторически выглядели среды низкого уровня. Нарушение привычки требует сознательных усилий, рискует раздражать тех, кому нравятся старые способы, и должно быть оправдано как стоящее. Придерживаться установленного способа является «по умолчанию».
  • Потому что многие из них происходят из других источников, таких как схемы и таблицы данных. На них, в свою очередь, влияют космические ограничения.
  • Потому что люди, отвечающие за присвоение имен, никогда не задумывались о читабельности, или не осознают, что создают проблемы, или ленивы.
  • Потому что в некоторых случаях имена стали частью протокола для обмена данными, например, использование ассемблера в качестве промежуточного представления некоторыми компиляторами.
  • Потому что этот стиль мгновенно узнаваем как низкоуровневый и, следовательно, выглядит круто для гиков.

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

Роман Старков
источник
10

Я собираюсь бросить свою шляпу в этот беспорядок.

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

Некоторые, однако, служат определенной цели. Конечно, BranchGreaterThan был бы намного более читабельным, чем BGT , но сейчас существует соглашение, это инструкция, и, как таковая, она приобрела некоторую популярность за последние 30 лет использования в качестве стандарта. Почему они начали с этого, возможно, какой-то произвольный предел ширины символов для инструкций, переменных и тому подобного; почему они держат это, это стандарт. Этот стандарт такой же, как использование int в качестве идентификатора, было бы более легко использовать Integer во всех случаях, но это необходимо для тех, кто программирует более нескольких недель ... нет. Почему? Потому что это стандартная практика.

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

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

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

Джефф Лангемайер
источник
1
Я чувствую, что «мы будем использовать загадочные имена, потому что это то, что заставляет низкоуровневое программирование чувствовать себя таковым», и «мы будем использовать загадочные имена, потому что это соглашение для низкоуровневого программирования» , в значительной степени то же самое, поэтому +1 от меня, и я буду думать о том, чтобы принять это как менее подстрекательский вариант того, который я принял изначально .
Роман Старков
6
+1 для справки химиков, поскольку она дает хорошую аналогию для различных областей программирования.
4
+1 Я также никогда не понимал, почему люди используют короткие, загадочные имена, такие как «вода», если есть гораздо более читаемый «DiHydrogenOxyde»
Инго
6

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

Если новый разработчик придет в команду, ему придется прочитать таблицы данных (как объясняет @KarlBielefeldt), чтобы им было удобно с ними.

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

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

Alex
источник
5

Резюме

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

Причины загадочных имен:

  1. Низкоуровневые инструкции строго типизированы
  2. Нужно упаковать много информации о типе в название инструкции низкого уровня
  3. Исторически, односимвольные коды использовались для упаковки информации о типе.

Решения и их недостатки:

  1. Существуют современные низкоуровневые схемы именования, которые более последовательны, чем исторические.
    • LLVM
  2. Однако необходимость упаковки большого количества информации о типах все еще существует.
    • Таким образом, загадочные сокращения все еще можно найти повсюду.
  3. Улучшенная читаемость между строками поможет начинающему программисту низкого уровня быстрее освоить язык, но не поможет с пониманием больших частей низкоуровневого кода.

Полный ответ

(A) Более длинные имена возможны. Например, имена встроенных в C ++ SSE2 в среднем составляют 12 символов по сравнению с 7 символами в мнемонике сборки. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) Затем возникает вопрос: сколько времени / некриптику нужно получить из низкоуровневых инструкций?

(С) Теперь мы проанализируем состав таких схем именования. Ниже приведены две схемы именования для одной и той же инструкции низкого уровня:

  • Схема именования № 1: CVTSI2SD
  • Схема именования № 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

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

(C.2) Каждая инструкция низкого уровня должна кодировать много информации о типе в свое имя. Примеры информации:

  • Архитектура Семья
  • операция
  • Аргументы (входы) и выходы
  • Типы (целое число со знаком, целое число без знака, число с плавающей запятой)
  • Точность (битовая ширина)

(C.3) Если каждая часть информации прописана, программа будет более многословной.

(C.4) Схемы кодирования типов, используемые различными поставщиками, имеют давние исторические корни. Например, в наборе команд x86:

  • B означает байт (8 бит)
  • W означает слово (16 бит)
  • D означает слово «двойное слово» (32-разрядное)
  • Q означает слово "quad-word" (64-разрядное)
  • DQ означает dqword «двойное четверное слово» (128 бит)

Эти исторические ссылки не имели никакого современного значения вообще, но все еще остаются вокруг. Более последовательная схема поместила бы значение ширины в бит (8, 16, 32, 64, 128) в имя.

Напротив, LLVM является правильным шагом в направлении последовательности в низкоуровневых инструкциях: http://llvm.org/docs/LangRef.html#functions

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

rwong
источник
1
Улучшенная читаемость между строками обязательно окажет некоторое влияние на понимание всего, но одно только наименование не может сделать его тривиальным, конечно.
Роман Старков
3
Кроме того, что-то не по теме, но CVTSI2SDне несет больше информации, чем ConvertDword2Doubleили ConvInt32ToFloat64, но последние, хотя и дольше, мгновенно узнаваемы, тогда как первые должны быть расшифрованы ...
Роман Старков
2

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

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

SK-логика
источник
Если вам нужно сэкономить место, просто скопируйте его! ... Если вам не нужны служебные данные, используйте вместо этого двоичный формат! Если вы используете текст, вы стремитесь к читабельности - тогда почему бы не пройти весь путь и сделать его правильно читаемым?
Роман Старков
2
@romkyns, сжимая текстовый протокол связи между двумя локальными процессами? Это что-то новое. Двоичные протоколы гораздо менее надежны. Это unix-способ - текстовые протоколы существуют для периодической читабельности. Они достаточно читабельны.
SK-logic
Правильно. Ваша предпосылка заключается в том, что я читаю и пишу имена этих регистров или инструкции CIL достаточно мало, чтобы накладные расходы имели значение. Но подумай об этом; они используются так же часто, как любой нечетный метод или имя переменной в любом другом языке программирования во время программирования . Это так редко, что лишние несколько байтов имеют значение?
Роман Старков
1
Я уважаю ваше право по-разному понимать, какими длинными должны быть имена, но действительно ли вы называете методы и локальные объекты в ваших компиляторах такими загадочными вещами TIFR, или они обычно содержат полные слова?
Роман Старков
1
Я не вижу разницы, которая имеет отношение к удобочитаемому и короткому компромиссу. Разумеется, я вижу их разными, точно так же, как переменные отличаются от функций, которые отличаются от типов. Я просто не понимаю , почему опкоды и зарегистрировать имена выигрывают от чрезвычайно короткие до точки необходимости обратитесь к документации на каждый вновь встречаются один , прежде чем вы любой ключ , как к тому , что он делает. Пока что ваш единственный аргумент - эффективное хранение, если я не ошибаюсь. Вы действительно это имеете в виду? ... Или у вас есть другие причины?
Роман Старков
1

В основном это идиоматично. Как говорит @TMN в других местах, так же, как вы не пишете import JavaScriptObjectNotationили import HypertextTransferProtocolLibraryна Python, вы не пишете Timer1LowerHalf = 0xFFFFна C. Это выглядит одинаково нелепо в контексте. Каждый, кто должен знать, уже знает.

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

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

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

Теперь единственная существующая IDE, которая будет анализировать это, является собственной IDE HiTech ( HiTide ). В любом другом редакторе вам придется каждый раз печатать его вручную, из памяти. Это очень быстро стареет.

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

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

detly
источник
2
Все ваши аргументы имеют смысл. Я полностью понимаю все эти моменты. Однако разве вы не думаете, что то же самое относится и к высокоуровневому коду? Вы также должны увидеть таблицу местных жителей в функции C #. Контекст субъективен и File.ReadAllBytesможет показаться смехотворно долгим для того, кто привык fread. Итак ... почему код высокого и низкого уровня различается ?
Роман Старков
@romkyns - я понимаю вашу точку зрения, но я не думаю, что мы на самом деле не относимся к высокоуровневому коду совсем по- другому. Аббревиатуры хороши во многих контекстах высокого уровня, мы просто не осознаем этого, потому что мы более привыкли к аббревиатуре или любой схеме, которая идет с ней. Когда я на самом деле пишу функции или создаю переменные в низкоуровневом коде, я использую красивые описательные имена. Но когда я ссылаюсь на регистр, я рад, что могу взглянуть на кучу букв и цифр и быстро подумать: «T = таймер, IF = флаг прерывания, 1 = первый регистр». Это почти как органическая химия в этом отношении: P
детально
@romkyns - Кроме того , в чисто практическом смысле, я думаю , что разница между таблицей регистров IDE и разработки приложений некоторого микропроцессора в C # это: таблица регистров ÜP может выглядеть следующим образом : Timer1InterruptFlag, Timer2InterruptFlag, ..., Timer9InterruptFlag, IOPortAToggleMask, IOPortBToggleMask, и т. д. x100. На языке более высокого уровня вы будете использовать переменные, которые отличаются гораздо больше ... или вы будете использовать больше структуры. Timer1InterruptFlagна 75% нежелательный шум по сравнению с T1IF. Я не думаю, что вы создадите огромный список переменных в C #, которые почти не отличаются.
детально
1
@romkyns - То , что вы не могли бы знать , является тот факт , что уже наблюдается сдвиг в сторону то , что вы описываете. Последние компиляторы Microchip поставляются с библиотеками, которые являются гораздо более многословными и описательными, чем просто регистры, например. UARTEnable(UART1, BITS_8, PARITY_N, STOP_1, BAUD_115200), Но они все еще невероятно неуклюжи, и в них много косвенности и неэффективности. Я стараюсь использовать их там, где это возможно, но большую часть времени я оборачиваю манипуляции с регистрами в своих собственных функциях и вызываю их из логики более высокого уровня.
детально
@detly: компилятор CCS имел такие методы, и некоторые другие процессоры делают это. Я вообще не люблю их. Спецификации регистра достаточно для написания кода, который использует регистры, и достаточно, чтобы кто-то мог читать код, который использует регистры, чтобы увидеть, что делают эти регистры. Если акт записи значения N в аппаратный прескаляр устанавливает период N + 1 (довольно часто), то надлежащее значение set_prescalar(TMR4,13);ИМХО намного менее ясно, чем было бы TMR4->PSREG=12;. Даже если взглянуть на руководство по компилятору, чтобы узнать, что делает первый код, ему, вероятно, все равно придется ...
суперкат
1

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

  1. Научная база программиста.
  2. Навыки программирования программиста.
  3. Среда программиста.

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


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

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

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

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