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

Чому це? Це просто тому, що старі звички важко порушити, чи є кращі причини?

Наприклад:

• Atmel ATMEGA32U2 (2010?): TIFR1(Замість TimerCounter1InterruptFlag), ICR1H(замість InputCapture1High), DDRB(замість DataDirectionPortB) тощо.
• Набір інструкцій .NET CLR (2002): bge.s(замість branch-if-greater-or-equal.short) тощо.

Чи не довші, некриптичні імена легше працювати?

Відповідаючи та голосуючи, будь ласка, врахуйте наступне. Багато запропонованих тут можливих пояснень однаковою мірою стосуються програмування на високому рівні, але все-таки консенсус загалом полягає у використанні некриптичних назв, що складаються зі слова або двох (виключені загальнозрозумілі абревіатури).

Крім того, якщо ваш головний аргумент стосується фізичного простору на паперовій схемі , будь ласка, врахуйте, що це абсолютно не стосується мови складання або CIL, плюс я буду вдячний, якщо ви покажете мені діаграму, де підходять кратні імена, але читабельні, що діаграму погіршують . З особистого досвіду напівпровідникової компанії Fabless, читабельні назви чудово підходять, і це призводить до отримання більш читабельних діаграм.

Що є основним, що відрізняється від програмування на низькому рівні, на відміну від мов високого рівня, що робить незаконні криптовалютні імена бажаними в програмуванні низького рівня, але не на високому рівні?

Причина, по якій програмне забезпечення використовує ці імена, полягає в тому, що в таблицях даних використовуються ці імена. Оскільки код на цьому рівні дуже важко зрозуміти без таблиці, так само імена змінних, які ви не можете шукати, є вкрай корисними.

Звідси виникає питання, чому в таблицях даних використовуються короткі імена. Це, мабуть, тому, що вам часто потрібно подавати імена в таких таблицях, де у вас немає місця для ідентифікаторів 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для 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це не випадкова абревіатура, це результат схеми іменування.

Окрім «старих звичок», поширений код Legacy, який був написаний 30 років тому і досі використовується. Незважаючи на те, що думають деякі менш досвідчені люди, рефакторинг цих систем, таким чином вони виглядають гарними, коштує дуже дорого за невеликий прибуток і не є комерційно життєздатним.

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

Наскільки bge.sце схоже на асемблер - тим мало хто, кому потрібно знати, довші назви менш читабельні. Якщо ви не можете змусити вас обійтися bge.sі думаєте, що branch-if-greater-or-equal.shortзміниться - ви просто граєте з CLR і не знаєте цього.

Інша причина того, що ви побачите короткі назви змінних, пов'язана з широким поширенням скорочень у домені, на яке орієнтується програмне забезпечення.

У підсумку - очікуються короткі скорочені назви змінних, які відображають зовнішній вплив, такий як галузеві норми та аркуші технічних даних. Короткі скорочені імена змінних, які є внутрішніми для програмного забезпечення, як правило, менш бажані.

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

Тож ось короткий опис відповідей, які розміщують тут інші. Я публікую це як CW і мій намір зрештою відзначити його прийнятим. Будь ласка, відредагуйте, якщо я щось пропустив. Я намагався переформулювати кожну ідею, щоб викласти її стисло, але чітко.

То чому чомусь загальновідомі короткі ідентифікатори настільки поширені в програмуванні низького рівня?

• Оскільки багато з них досить поширені у відповідному домені, щоб гарантувати дуже коротку назву. Це погіршує криву навчання, але є корисним компромісом, враховуючи частоту використання.
• Оскільки зазвичай є невеликий набір можливостей, який фіксується (програміст не може додати до набору).
• Тому що читабельність - це питання звички та практики. branch-if-greater-than-or-equal.shortє спочатку більш читабельним , ніж bge.s, але з деякою практикою ситуація стає зворотним.
• Тому що їх часто доводиться вводити повністю вручну, оскільки мови низького рівня часто не мають потужних IDE, які мають гарне автодоповнення, або ж / c не є надійним.
• Тому що іноді бажано запакувати багато інформації в ідентифікатор, і читабельна назва неприйнятно довга навіть за високими стандартами.
• Тому що так виглядали історичні середовища низького рівня. Порушення звички вимагає усвідомлених зусиль, ризикує роздратувати тих, хто любив старі способи, і його потрібно виправдати як належне. Дотримуватися встановленого способу - це "за замовчуванням".
• Тому що багато з них походять з інших місць, наприклад, схеми та таблиці даних. На них, у свою чергу, впливають космічні обмеження.
• Тому що люди, відповідальні за називання речей, ніколи навіть не вважали читабельністю, або не розуміють, що вони створюють проблему, або лінуються.
• Тому що в деяких випадках імена стають частиною протоколу обміну даними, наприклад, використання мови збирання в якості проміжного представлення деякими компіляторами.
• Тому що цей стиль миттєво розпізнається як низькорівневий і, таким чином, виглядає прикольно до вундуків.

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

Я буду кидати шапку в цей безлад.

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

Деякі, однак, служать цілі. Звичайно, BranchGreaterThan було б набагато легше читати, ніж BGT , але зараз там є умова , це інструкція, і як така вона отримала деяку тягу за останні 30 років використання в якості стандарту. Чому вони почали саме з цього, ймовірно, довільної межі ширини символів для інструкцій, змінних тощо? чому вони його зберігають, це стандарт. Цей стандарт такий же, як використання int в якості ідентифікатора, Integer було б більш розбірливим у всіх випадках, але чи потрібно це тому, хто програмує більше декількох тижнів ... ні. Чому? Тому що це стандартна практика.

По-друге, як я вже сказав у своєму коментарі, багато переривань називаються INTG1 та іншими криптовалютними іменами, вони також служать цілі. У діаграмах схеми НЕ добре умовляти називати ваші рядки, і таке багатослів’я це захаращує діаграму і шкодить розбірливості. Вся багатослівність обробляється в документації. Оскільки всі діаграми проводки / схеми мають ці короткі назви ліній переривання, самі переривання також отримують те саме ім'я, що і для збереження послідовності вбудованого конструктора від схеми аж до коду для його програмування.

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

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

Однією з причин вони користуються критичні короткі ідентифікатори - це тому, що вони не є критичними для розробників. Ви повинні усвідомити, що вони працюють з цим щодня, і ці імена справді є доменними іменами. Тож вони напам'ять знають, що саме означає TIFR1.

Якщо до команди прийде новий розробник, йому доведеться читати таблиці (як пояснив @KarlBielefeldt), щоб їм було зручно.

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

Я б сказав, що вони роблять це в основному через шкідливі звички, які існували, коли компілятори не виконували автоматично все, що ви вводили.

Підсумок

Ініціалізм - поширене явище у багатьох технічних та нетехнічних колах. Як таке воно не обмежується програмуванням низького рівня. Для загального обговорення дивіться статтю Вікіпедії про абревіатуру . Моя відповідь специфічна для програмування низького рівня.

Причини криптовалют:

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) Далі питання переходить до: Як довго / не криптовалюта потрібно отримувати інструкції низького рівня?

(C) Тепер ми аналізуємо склад таких схем іменування. Нижче наведено дві схеми іменування для тієї ж інструкції низького рівня:

• Схема іменування №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 означає qword "чотири слово" (64-розрядне)
• DQ означає dqword "подвійне чотири слово" (128-бітове)

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

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

(D) Незалежно від схеми іменування інструкцій, програми низького рівня вже є багатослівними і важко зрозумітими, оскільки вони зосереджені на детальних хвилинах виконання. Зміна схеми іменування інструкцій покращить читабельність на рівні "рядок", але не усуне труднощів із розумінням операцій великого фрагмента коду.

Люди читають і пишуть складання лише зрідка, і більшість часу це лише протокол зв'язку. Тобто він найчастіше використовується як проміжне серіалізоване текстове представлення між компілятором і асемблером. Чим більш детальним є це уявлення, тим більше непотрібних витрат у цьому протоколі.

У випадку з кодами та іменами регістрів довгі імена фактично шкодять читабельності. Короткі мнемоніки краще для протоколу зв'язку (між компілятором і збіркою), а мова збирання - це протокол зв'язку більшу частину часу. Короткі мнемоніки краще для програмістів, оскільки код компілятора легше читати.

Переважно це ідіоматично. Як говорить @TMN в іншому місці, так само, як ви не пишете import JavaScriptObjectNotationабо import HypertextTransferProtocolLibraryв Python, ви не пишете Timer1LowerHalf = 0xFFFFв C. Це виглядає так само смішно в контексті. Кожен, хто повинен це вже знати, знає.

Опір змінам може виникнути частково від того, що деякі постачальники компіляторів С для вбудованих систем відхиляються від мовного стандарту та синтаксису для того, щоб реалізувати функції, більш корисні для вбудованого програмування. Це означає, що ви не завжди можете використовувати функцію автозаповнення улюбленого IDE або текстового редактора під час написання коду низького рівня, оскільки ці налаштування заважають їх здатності аналізувати код. Звідси корисність коротких імен регістрів, макросів і констант.

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

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

Зараз єдиний існуючий IDE, який буде аналізувати це власний IDE HiTech ( HiTide ). У будь-якому іншому редакторі вам доведеться кожного разу вводити його вручну, з пам’яті. Це дуже швидко старіє.

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

Вони можуть здатися дурними дрібницями, але чи не кожна конвенція про кодування призначена для зменшення напруги очей, зменшення зайвого набору тексту або вирішення будь-яких мільйонів інших маленьких скарг?

Я здивований, що про лінь ніхто не згадав і що інші науки не обговорюються. Моя щоденна робота як програміста показує мені, що умовами іменування будь-яких змінних в програмі впливають три різні аспекти:

1. Наукове підґрунтя програміста.
2. Навички програмування програміста.
3. Середовище програміста.

Думаю, що обговорювати програмування низького або високого рівня не даремно. Зрештою, це завжди можна прив’язати до трьох попередніх аспектів.

Пояснення першого аспекту: Багато "програмістів" - це не програмісти в першу чергу. Це математики, фізики, біологи або навіть психологи чи економісти, але багато з них не є комп'ютерними науковцями. Більшість із них мають власні доменні ключові слова та абревіатури, які ви можете побачити в їх назвах "конвенції". Вони часто перебувають у пастці у своїй галузі та використовують ті відомі абревіатури, не замислюючись про читанність чи кодування посібників.

Пояснення другого аспекту: Оскільки більшість програмістів не є комп'ютерними фахівцями, їх навички програмування обмежені. Ось чому вони часто не переймаються умовами кодування, але більше про конкретні доменні конвенції, як зазначено в якості першого аспекту. Крім того, якщо у вас немає навичок програміста, ви не маєте розуміння умов кодування. Я думаю, що більшість з них не бачить нагальної потреби писати зрозумілий код. Це як вогонь і забудь.

Пояснення третього аспекту: навряд чи можна гальмувати умовами вашого оточення, які можуть бути старим кодом, який ви повинні підтримувати, стандартами кодування вашої компанії (керують економістами, які не займаються кодуванням) або доменом, до якого ви належите. Якщо хтось почав використовувати криптовалютні імена, і вам доведеться підтримувати його або його код, ви навряд чи зміните криптовалютні імена. Якщо у вашій компанії немає стандартів кодування, я думаю, що майже кожен програміст напише свій стандарт. І останнє, якщо вас оточують користувачі домену, ви не почнете писати іншу мову, ніж вони використовують.