Кодируем стильно: Ассемблер

[Levsha100]

Здравствуйте!
Хотелось бы узнать ка наиболее правильно оформлять программы на ассемблере!
Как разделять блоки, макросы, выделять циклы и т.д.
Вот как пока оформляю я:

;================================== =====
; Инициализация
Reset:
outinf SPL,low(RAMEND) ; инициализируем стек
outinf SPH,High(RAMEND) ;-//-

;------------------------
;Инициализируем порты
;Все порты- выходы, = 0
; CBI-0 SBI-1
SBI DDRB, DataPin ;
CBI PORTB, DataPin ;

SBI DDRB, ClockPin ;
CBI PORTB, ClockPin ;

SBI DDRB, ResetPin ;
CBI PORTB, ResetPin ;
;================================== =====

[BOBAH13]

По блочно с изобилием комментариев. Иначе - Смерть через пару дней

[Levsha100]

Хотелось бы поконкретней.
Какие комментарии Вы используете?

;------
;+++++
;=====
;*****
;////////
////////
//====
/*     */

Ставите ли после каждой команды ";" (как в ЯВУ)?
Как оформляете блоки, комментарии.
Может есть системы типа Doxywizard для асма?

//А вообще хотелось бы создать цикл тем "Кодируем стильно", где показывается как правильно оформлять код, называть переменные и т.д.

[Ivan_32]

////////
//====
/* */

Такие комментарии есть только в GASM и еще каком то ассемблере, кажется YASM-е.

Если нужно что то прокомментировать делаю так:
;;################
;;## Hello world block ##
;;################

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

fdd_stop:
  mov   dx,3F2h
  mov   al,0
  out   dx,al
nmi_disable:
  in al,70h
  or al,80h
  out 70h,al

Эти две метки совершенно не нужны, но с другой стороны они не так выделяются среди общей массы кода и в тоже время в ней не теряются.

[BOBAH13]

Пример блока

...
xor eax,eax
mov eax,1

; Something is here and very important to udnerstand it
xor eax,eax ; clear eax
mov eax,1 ; move 1 to eax

; Next block
xor eax,eax
mov eax,1

А вообще понимаете, то как "правильно" будет для каждого свое. Я для себя выработал основные пунктики:
1. Использовать только English в наименовании функций, переменных и т.д.
2. Использовать (не сильно сокращать) имена функций, чтобы попытаться вложить весь смысл функции в ее имя, а так же параметры - их именовать так же, например FileName или Path или scan0 и т.п. т.е. сразу можно понять что есть параметр и для чего он нужен, на крайний случай сделать так

/* 
   Make something with your PC

   drive - setup drive of the PC to be formated
*/
bool DriveFormat(char *drive)
{
   return true;
}

т.е. именно DriveFormat, а не FormatDrive. Почему ? Т.к. в теории можно будет сгруппировать осмысленный набор функций например:
DriveFormat
DriveRemove
DriveMount
DriveUnmount и т.п.
А теперь представьте, чтобы было если бы Drive стоял в каждой функции на втором месте

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

Думаю открывать еще тему для этого излишество.

[Levsha100]

А вообще понимаете, то как "правильно" будет для каждого свое.

Да, но все же есть некоторые правила программерского этикета.
Например, на С++ можно написать так

if( a==b ){
code;
code;
code;
}

Или так

if( a==b )
{
code;
code;
code;
}

И это нормально, но если написать так

if(a==b){code;code;code;}

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

[DeKot]

Во вложении пример на asm. Уже давно применяю свои принципы:
1. Много коментариев не бывает.
2. Все имена должны быть осмысленными и понятными любому, кто читает код.
3. Программа разбивается на блоки, опять же на понятно осмысленные.
4. Если работаешь в команде - сначала разработайте командную спецификацию, понятную все членам команды. А уж потом ваяйте код.