Page 1 of 1
Formatting rules of the code
Posted: Mon Dec 28, 2009 4:04 pm
by hidnplayr
When you look at the current source code of the kernel, and the programs for KolibriOS, you will easily see the code has been written by different developers and is therefore formatted in different ways.
With this, I mean the use of tabs, spaces, newlines, the placing of comments etc.
Therefore, I suggest to create a set of 'rules' about how to format the code.
(Most opensource projects have these btw)
In this thread, I would like to discuss wheter you think this is nescessary and if so, how the rules should look like.
Re: Formatting rules of the code
Posted: Tue Dec 29, 2009 8:42 am
by Asper
I think that it'll be better to write
mcall instead of
int 0x40 in asm applications.
And asm code easier to read when there are not just horizontal, but also vertical tabulations between different logical blocks of code.
For example, you can write code like this:
Code: Select all
still:
call get_receiver_window_slot_number
mov eax, 10 ; Wait for an event in the queue.
int 0x40
cmp al,1 ; redraw request ?
jz red
cmp al,2 ; key in buffer ?
jz key
cmp al,3 ; button in buffer ?
jz button
jmp still
red:
call draw_window
jmp still
key:
mov eax, 2
int 0x40
call get_control_keys_state
cmp [locks], ax
je @f
.reload:
call reload_ascii_keymap
mov byte [red_type], 1
call draw_window
@@:
jmp still
or like this:
Code: Select all
still:
call get_receiver_window_slot_number
mcall 10 ; Wait for an event in the queue.
cmp al,1 ; redraw request ?
jz red
cmp al,2 ; key in buffer ?
jz key
cmp al,3 ; button in buffer ?
jz button
jmp still
red:
call draw_window
jmp still
key:
mcall 2
call get_control_keys_state
cmp [locks], ax
je @f
.reload:
call reload_ascii_keymap
mov byte [red_type], 1
call draw_window
@@:
jmp still
Re: Formatting rules of the code
Posted: Tue Dec 29, 2009 9:32 am
by mike.dld
I wonder what do those anarchists answered "no" think about
Code formatting is a good question. I generally try keeping it like this (although not always succeeding):
Code: Select all
global_label: // indent: 0; for subprogram names; no other code on this line
mov eax, 5 // indent: 8, second indent: 16; space after comma
movzx eax, word[eax * 5 + 5] // no space after typename; spaces on both sides of arithmetical operations
mov dword[eax], 5 // casting memory location, not the constant operand
movzx eax, [eax + STRUCTNAME.field_name] // don't ever cast if there's no need
.local_label: // indent: 2, name starts with dot; for labels inside subprograms; no other code on this line
@@: add eax, 5 // indent: 4; unnamed labels for short jumps when logic is obvious; code immediately follows the label
This is just a short description.
Comments leave space for discussion here. Since code lines could be long enough, I prefer writing them with large (say, 60-80 chars) indent or writing them on a separate lines with indent 0 before global labels and 8 before all other code (which is, probably, a better way).
Structs/fields, constants and variables naming convention should also be discussed, at least for kernel coding.
Re: Formatting rules of the code
Posted: Tue Dec 29, 2009 9:53 am
by Mario
One of the anarchists believed that the conditions can not be met.
For example Notepad++ (for Windows) and Kate (for Linux) is differently processing for Tab.
Blanks litter a code.
But ... Nobody cares.
P.S. Your rules are so useless as well, as your new design a web site.
Re: Formatting rules of the code
Posted: Tue Dec 29, 2009 1:16 pm
by hidnplayr
Mario wrote:For example Notepad++ (for Windows) and Kate (for Linux) is differently processing for Tab.
Blanks litter a code.
It is an interesting fact you mention there, but why are you being so pessimistic.
I do not believe blanks/tabs are waste, they approve readeability.
There are numerous editors for every platform (even kolibriOS has more then one), and if such an editor screws up your text, and does not have an option to disable this function, i think you should consider starting to use another editor.
I have placed the proposals on the wiki:
http://wiki.kolibrios.org/Formatting_rules_of_the_code
I normally type all constants in uppercase letters with underscores if needed.
I have the bad habbit to use upper- and lowercase letters for regular labels, I think all lowercase would be better (again, with underscores where needed).
This way, you dont have to think which letters you typed in uppercase, and which not.