If you are fixing/adding something, keep style from rest of the code. Make indentations by tab characters, not space. Make spaces after commas or semicolons. If you have other style, but your patches will be good and/or necessary don't be suprise if Your code will be changed.
Add yourself to copyrights at the beginning of the file. If you don't do it I found that you relinquish your code. Of course sended code must be on the same licence as the rest of the code. If not don't waste your time and don't send it to us.
Keep conventions. If all structure's variables have names
like foobar_count
, don't add
foocount
, or nfoo
.
Don't change api without reason. Even if you want to do it, consult with other developers.
If you are making some bigger part of the code/module/file
designed to some function, try to call functions and vars
in way that can be understandable by other developers.
Example: function connected with list are beginning with
list_*
, userlist functions
userlist_*
, configuration is something
like config_*
.
For memory allocation use
xmalloc()
,
xcalloc()
,
xrealloc()
and
xstrdup()
. You don't have to check
returned value. If there will be no memory, these functions
will handle soft program close. Look after freeing buffors,
if they are not needed anymore.
Instead of strncpy()
and
strncat()
use
strlcpy()
and
strlcat()
, which takes as a parametr
full buffer size. You don't have to worry about how much
memory is left, if zero character will go, etc. Both
functions always return number of
characters, which were saved to the buffer.
If you don't know anything about memory allocation and string support in C, better find something else to do. Even if code is correct, but it is disordered it will be refused.
Podsyłając patche, twórz je poleceniem diff -u. diff bez parametrów generuje patche, które nie zawierają żadnego kontekstu i ciężko je dołączyć do źródła, gdy zmieniła się wcześniej chociaż jedna linijka. Patche najlepiej generować względem najświeższej wersji, ale nie jest to wymagane, jeśli w międzyczasie nie było poważnych zmian w kodzie.
Jeśli poprawka jest niewielka (jedna, dwie linijki), nie trać swojego, ani mojego czasu, tylko po prostu wklej oryginał i poprawioną wersję do treści listu.
Poniższe linijki dopisane do ~/.vimrc ułatwiają wychwytywanie znaków niedrukowalnych pozostawionych na końcach linii poprzez zmianę ich koloru:
highlight WhitespaceEOL ctermbg=red guibg=red match WhitespaceEOL /\s\+$/
Wszelkie komentarze powinny być w języku angielskim.
Wszystkie formatki i wszystko co zostaje wyświetlane na ekranie ma być w języku angielskim.
Po zmianie jakiejkolwiek formatki należy w katalogu po/ wywołać make update-po i ewentualnie poprawić pliki *.po
Everyone can send patches, if they are respecting conventions. It is about saving our project from disorder after one month. Of course every change will be checked and if there is something wrong author will be rebuked.
API documentation is avaiable on project homepage: http://www.ekg2.org/en/doxygen/