Раньше были очень веские причины для краткости названий инструкций / регистров. Эти причины больше не применяются, но короткие загадочные имена все еще очень распространены в низкоуровневом программировании.
Почему это? Это просто потому, что старые привычки трудно сломать, или есть более веские причины?
Например:
- Atmel ATMEGA32U2 (2010?):
TIFR1
(ВместоTimerCounter1InterruptFlag
),ICR1H
(вместоInputCapture1High
),DDRB
(вместоDataDirectionPortB
) и т. Д. - Набор команд .NET CLR (2002):
bge.s
(вместоbranch-if-greater-or-equal.short
) и т. Д.
Не проще ли работать с длинными, не зашифрованными именами?
При ответе и голосовании учтите следующее. Многие из возможных объяснений, предложенных здесь, в равной степени применимы к высокоуровневому программированию, и, тем не менее, консенсус в целом заключается в использовании нешифрованных имен, состоящих из одного или двух слов (за исключением общепринятых сокращений).
Кроме того, если ваш основной аргумент касается физического пространства на бумажной диаграмме , учтите, что это абсолютно не относится к языку ассемблера или CIL, плюс я был бы признателен, если бы вы показали мне диаграмму, где краткие имена подходят, но читаемые из них ухудшают диаграмму , Исходя из личного опыта в компании Fabless Semiconductor, легко читаемые имена подходят и приводят к более читаемым диаграммам.
В чем заключается основная особенность низкоуровневого программирования в отличие от языков высокого уровня, который делает краткие загадочные имена желательными в низкоуровневом, но не высокоуровневом программировании?
источник
JSR
в три раза длиннее, чем код операции, который он представляет ($20
на 6502), и значительно проще для понимания с первого взгляда.set Accumulator32 to BaseIndex32
? Простое расширение традиционных аббревиатур - не единственный способ сделать что-то более читабельным.Ответы:
Причина, по которой программное обеспечение использует эти имена, заключается в том, что таблицы данных используют эти имена. Так как код на этом уровне очень трудно понять без таблицы в любом случае, создание имен переменных, которые вы не можете искать, крайне бесполезно.
Это поднимает вопрос о том, почему таблицы используют короткие имена. Вероятно, это потому, что вам часто нужно представлять имена в таких таблицах, где у вас нет места для 25-символьных идентификаторов:
Кроме того, такие вещи, как схемы, схемы выводов и шелкографии на печатных платах, часто очень ограничены в пространстве.
источник
Закон Ципфа
Посмотрев на этот текст, вы сами увидите, что длина слова и частота употребления, как правило, обратно пропорциональны. Слова, которые используются очень часто, как
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
для программистов, специалисты в данной области техники программирования низкого уровня. Я думаю, что большинство людей, которые работают на уровне сборки, скажут вам, что обучение чтению кода не является одной из самых больших проблем в низкоуровневом программировании.источник
В общем
Качество именования - это не только наличие описательных имен, оно также должно учитывать другие аспекты, и это приводит к рекомендациям, таким как:
Обратите внимание, что эти рекомендации противоречивы.
Инструкция по мнемонике
Как программист на ассемблере, использование
short-branch-if-greater-or-equal
forbge.s
дает мне то же впечатление, что и когда я вижу, как программист AlgolSUBSTRACT 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
важно отметить, что это не случайное сокращение, а результат схемы именования.источник
TIFR1
ли лучшая схема именования, чемInterruptFlag1
если бы, илиIptFlag1
если вы действительно должны быть короткими?InterruptFlag
иIptFlag
лучше, чем такIF
же, какEnumerableInterface
иItfcEnumerable
лучше, чемIEnumerable
.InterruptFlag1
по причинам лучшей ясности.Помимо причин «старых привычек», код Legacy, написанный 30 лет назад и до сих пор используемый, очень распространен. Несмотря на то, что думают некоторые менее опытные люди, рефакторинг этих систем, чтобы они выглядели красиво, стоил очень дорого за небольшую выгоду и не был коммерчески выгодным.
Встраиваемые системы, близкие к аппаратному обеспечению и имеющие доступ к регистрам, имеют тенденцию использовать те же или похожие метки, которые используются в технических паспортах оборудования, по очень веским причинам. Если регистр называется XYZZY1 в листах технических данных, то имеет смысл, что переменная, представляющая его, скорее всего, XYZZY1, или если у программиста был хороший день, RegXYZZY1.
Насколько
bge.s
это похоже на ассемблер - тем немногим, кому нужно это знать, более длинные имена менее читабельны. Если вы не можете заставить себяbge.s
задуматься и думаете, чтоbranch-if-greater-or-equal.short
это что- то изменит - вы просто играете с CLR и не знаете этого.Другая причина, по которой вы увидите короткие имена переменных, связана с тем, что мы широко используем аббревиатуры в домене, на который нацелено программное обеспечение.
В итоге - ожидаются короткие сокращенные имена переменных, отражающие внешнее влияние, такие как отраслевые нормы и технические характеристики оборудования. Короткие сокращенные имена переменных, которые являются внутренними для программного обеспечения, обычно менее желательны.
источник
TIFR1
он более читабелен для тех, кто должен это знать, чемTimerCounter1InterruptFlag
, правильно?j?
инструкции . Наличие более явно названной инструкции определенно помогло бы мне. Но, возможно, я скорее исключение, чем правило. У меня проблемы с запоминанием мелких деталей.Здесь так много разных идей. Я не могу принять ни один из существующих ответов в качестве ответа: во-первых, вероятно, этому способствует множество факторов, и, во-вторых, я не могу знать, какой из них является наиболее значимым.
Итак, вот краткое изложение ответов, опубликованных другими здесь. Я публикую это как CW, и я намерен в конечном итоге отметить это как принятое. Пожалуйста, отредактируйте, если я что-то пропустил. Я пытался перефразировать каждую идею, чтобы выразить ее кратко, но четко.
Так почему загадочные короткие идентификаторы так распространены в низкоуровневом программировании?
branch-if-greater-than-or-equal.short
является изначально более читаемым , чемbge.s
, но с некоторой практикой ситуация становится обратной.Я лично чувствую, что некоторые из них на самом деле не способствуют тому, почему недавно разработанная система выбрала этот стиль именования, но я чувствовал, что было бы неправильно отфильтровывать некоторые идеи в ответах такого типа.
источник
Я собираюсь бросить свою шляпу в этот беспорядок.
Соглашения и стандарты кодирования высокого уровня не совпадают со стандартами и практиками кодирования низкого уровня. К сожалению, большинство из них являются пережитками устаревшего кода и старых мыслительных процессов.
Некоторые, однако, служат определенной цели. Конечно, BranchGreaterThan был бы намного более читабельным, чем BGT , но сейчас существует соглашение, это инструкция, и, как таковая, она приобрела некоторую популярность за последние 30 лет использования в качестве стандарта. Почему они начали с этого, возможно, какой-то произвольный предел ширины символов для инструкций, переменных и тому подобного; почему они держат это, это стандарт. Этот стандарт такой же, как использование int в качестве идентификатора, было бы более легко использовать Integer во всех случаях, но это необходимо для тех, кто программирует более нескольких недель ... нет. Почему? Потому что это стандартная практика.
Во-вторых, как я сказал в своем комментарии, многие из прерываний называются INTG1 и другими загадочными именами, они также служат цели. На схемах не принято называть ваши линии, и такое словесное искажение мешает диаграмме и ухудшает разборчивость. Все подробности обрабатываются в документации. И поскольку все схемы соединений / схем имеют эти короткие имена для линий прерываний, сами прерывания также получают то же имя, что и для согласованности встроенного конструктора от принципиальной схемы до кода для его программирования.
Дизайнер имеет некоторый контроль над этим, но, как и любой другой язык / поле, существуют соглашения, которые следуют от оборудования к оборудованию, и поэтому должны оставаться одинаковыми для каждого языка ассемблера. Я могу посмотреть на фрагмент сборки и получить суть кода, даже не используя этот набор инструкций, потому что они придерживаются соглашения, LDA или некоторого отношения к нему, вероятно, загрузка регистра MV , вероятно, перемещает что-то откуда-то в в другом месте речь идет не о том, что вы считаете хорошим, или о практике высокого уровня, это язык сам по себе, и, как таковой, имеет свои собственные стандарты и означает, что вы, как дизайнер, должны следовать, зачастую они не так произвольны, как они кажутся.
Я оставлю вас с этим: просить встроенное сообщество использовать подробные практики высокого уровня - это все равно, что просить химиков всегда выписывать химические соединения. Химик пишет их кратко для себя, и любой другой в области поймет это, но новичку может потребоваться некоторое время, чтобы приспособиться.
источник
Одна из причин, по которой они используют загадочные короткие идентификаторы, заключается в том, что они не загадочны для разработчиков. Вы должны понимать, что они работают с ним каждый день, и эти имена действительно являются доменными именами. Таким образом, они знают наизусть, что именно означает TIFR1.
Если новый разработчик придет в команду, ему придется прочитать таблицы данных (как объясняет @KarlBielefeldt), чтобы им было удобно с ними.
Я полагаю, что в вашем вопросе использовался плохой пример, потому что действительно в таких исходных кодах вы обычно видите много ненужных идентификаторов склепа для не относящихся к домену вещей.
Я бы сказал, что в основном они делают это из-за вредных привычек, которые существовали, когда компиляторы не выполняли автоматически все, что вы вводите.
источник
Резюме
Инициализм является распространенным явлением во многих технических и нетехнических кругах. Как таковая, она не ограничивается программированием низкого уровня. Для общего обсуждения см. Статью в Википедии об аббревиатуре . Мой ответ относится только к низкоуровневому программированию.
Причины загадочных имен:
Решения и их недостатки:
Полный ответ
(A) Более длинные имена возможны. Например, имена встроенных в C ++ SSE2 в среднем составляют 12 символов по сравнению с 7 символами в мнемонике сборки. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx
(B) Затем возникает вопрос: сколько времени / некриптику нужно получить из низкоуровневых инструкций?
(С) Теперь мы проанализируем состав таких схем именования. Ниже приведены две схемы именования для одной и той же инструкции низкого уровня:
CVTSI2SD
__m128d _mm_cvtsi32_sd (__m128d a, int b);
(C.1) Низкоуровневые инструкции всегда строго напечатаны. Не может быть неоднозначности, вывода типа, автоматического преобразования типа или перегрузки (повторное использование имени команды для обозначения аналогичных, но не эквивалентных операций).
(C.2) Каждая инструкция низкого уровня должна кодировать много информации о типе в свое имя. Примеры информации:
(C.3) Если каждая часть информации прописана, программа будет более многословной.
(C.4) Схемы кодирования типов, используемые различными поставщиками, имеют давние исторические корни. Например, в наборе команд x86:
Эти исторические ссылки не имели никакого современного значения вообще, но все еще остаются вокруг. Более последовательная схема поместила бы значение ширины в бит (8, 16, 32, 64, 128) в имя.
Напротив, LLVM является правильным шагом в направлении последовательности в низкоуровневых инструкциях: http://llvm.org/docs/LangRef.html#functions
(D) Независимо от схемы именования команд, низкоуровневые программы уже многословны и их трудно понять, поскольку они фокусируются на мельчайших деталях исполнения. Изменение схемы именования команд улучшит читабельность на уровне строки к строке, но не устранит трудности понимания операций большого фрагмента кода.
источник
CVTSI2SD
не несет больше информации, чемConvertDword2Double
илиConvInt32ToFloat64
, но последние, хотя и дольше, мгновенно узнаваемы, тогда как первые должны быть расшифрованы ...Люди читают и пишут сборку только изредка, и большую часть времени это просто протокол связи. То есть чаще всего используется как промежуточное сериализованное текстовое представление между компилятором и ассемблером. Чем более многословно это представление, тем больше ненужных служебных данных в этом протоколе.
В случае кодов операций и имен регистров длинные имена фактически вредят читабельности. Короткая мнемоника лучше подходит для протокола связи (между компилятором и ассемблером), а язык ассемблера в большинстве случаев является протоколом связи. Короткая мнемоника лучше для программистов, так как код компилятора легче читать.
источник
TIFR
, или они обычно содержат полные слова?В основном это идиоматично. Как говорит @TMN в других местах, так же, как вы не пишете
import JavaScriptObjectNotation
илиimport HypertextTransferProtocolLibrary
на Python, вы не пишетеTimer1LowerHalf = 0xFFFF
на C. Это выглядит одинаково нелепо в контексте. Каждый, кто должен знать, уже знает.Сопротивление изменениям может возникать, в частности, из-за того, что некоторые поставщики компиляторов C для встроенных систем отклоняются от языкового стандарта и синтаксиса для реализации функций, более полезных для встроенного программирования. Это означает, что вы не всегда можете использовать функцию автозаполнения вашей любимой IDE или текстового редактора при написании низкоуровневого кода, потому что эти настройки лишают их возможности анализировать код. Отсюда полезность коротких имен регистров, макросов и констант.
Например, компилятор C HiTech включал специальный синтаксис для переменных, которые должны были иметь заданную пользователем позицию в памяти. Вы можете заявить:
Теперь единственная существующая IDE, которая будет анализировать это, является собственной IDE HiTech ( HiTide ). В любом другом редакторе вам придется каждый раз печатать его вручную, из памяти. Это очень быстро стареет.
Также есть тот факт, что при использовании инструментов разработки для проверки регистров у вас часто будет отображаться таблица с несколькими столбцами (имя регистра, значение в шестнадцатеричном формате, значение в двоичном формате, последнее значение в шестнадцатеричном формате и т. Д.). Длинные имена означают, что вы должны расширить столбец имени до 13 символов, чтобы увидеть разницу между двумя регистрами, и сыграть «найдите разницу» между десятками строк повторяющихся слов.
Это может звучать как глупые маленькие придирки, но разве каждое соглашение о кодировании не направлено на то, чтобы уменьшить нагрузку на глаза, уменьшить излишнее печатание или решить одну из миллиона других маленьких жалоб?
источник
File.ReadAllBytes
может показаться смехотворно долгим для того, кто привыкfread
. Итак ... почему код высокого и низкого уровня различается ?Timer1InterruptFlag
,Timer2InterruptFlag
, ...,Timer9InterruptFlag
,IOPortAToggleMask
,IOPortBToggleMask
, и т. д. x100. На языке более высокого уровня вы будете использовать переменные, которые отличаются гораздо больше ... или вы будете использовать больше структуры.Timer1InterruptFlag
на 75% нежелательный шум по сравнению сT1IF
. Я не думаю, что вы создадите огромный список переменных в C #, которые почти не отличаются.UARTEnable(UART1, BITS_8, PARITY_N, STOP_1, BAUD_115200)
, Но они все еще невероятно неуклюжи, и в них много косвенности и неэффективности. Я стараюсь использовать их там, где это возможно, но большую часть времени я оборачиваю манипуляции с регистрами в своих собственных функциях и вызываю их из логики более высокого уровня.set_prescalar(TMR4,13);
ИМХО намного менее ясно, чем было быTMR4->PSREG=12;
. Даже если взглянуть на руководство по компилятору, чтобы узнать, что делает первый код, ему, вероятно, все равно придется ...Я удивлен, что никто не упомянул лень и что другие науки не обсуждаются. Моя ежедневная работа программистом показывает мне, что на соглашения о присвоении имен для любых переменных в программе влияют три различных аспекта:
Я думаю, что бесполезно обсуждать программирование низкого или высокого уровня. В самом конце это всегда можно связать с первыми тремя аспектами.
Объяснение первого аспекта. Многие «программисты» не являются программистами. Это математики, физики, биологи или даже психологи или экономисты, но многие из них не являются компьютерными учеными. У большинства из них есть собственные ключевые слова и сокращения, относящиеся к домену, которые вы можете увидеть в их именных «соглашениях». Они часто оказываются в ловушке в своей области и используют эти известные сокращения, не задумываясь о читаемости или руководствах по кодированию.
Объяснение второго аспекта: поскольку большинство программистов не являются программистами, их навыки программирования ограничены. Вот почему они часто не заботятся о соглашениях по кодированию, но больше о соглашениях по конкретным областям, как указано в первом аспекте. Также, если вы не обладаете навыками программиста, у вас нет понимания соглашений о кодировании. Я думаю, что большинство из них не видит острой необходимости писать понятный код. Это как огонь и забыть.
Объяснение третьего аспекта. Маловероятно, что будут нарушены соглашения вашей среды, которыми может быть старый код, который вы должны поддерживать, стандарты кодирования вашей компании (управляемые экономистами, которые не заботятся о кодировании) или домен, к которому вы принадлежите. Если кто-то начал использовать загадочные имена, и вы должны поддержать его или его код, вы вряд ли измените загадочные имена. Если в вашей компании нет стандартов кодирования, я уверен, что почти каждый программист напишет свой собственный стандарт. И последнее, если вы окружены пользователями домена, вы не начнете писать другой язык, чем они используют.
источник