this is _not_ meant to stop you from coding, but meant to structure the coding a bit. Bluefish isn't very well structured at the moment, and I'm trying to improve this a bit.
happy coding!
Olivier Sessink
http://bluefish.openoffice.nl/
just be lazy and use
indent -kr -ts4 *.c *.hThis is the Kernighan & Ritchie coding style, with tabsize 4
Do not use C++ style comments but use plain C /* and */. gcc does things right, but other C compilers might complain about it.
use void name_cb() for a callback that can be used global, like the callback to start a dialog (can be something else then a void)
use static void name_lcb() for a local callback, like the OK click in a dialog (can also be something else then a void)
try to have the name explaining what the function does, e.g. doc_do_replace() would do a replace in a specific doc etc.
always declare those functions static that need not be visible outside the current file static. Reason: Avoid polluting the global namespace. static functions will be linked only within the same fle. All procedures that are used in other files (public) should be in the .h file declared.
All variables that are used in other files (public) should be in the .h with an extern before it. But try to avoid global variables. Most of the time you can avoid them by creating a typedef struct.
Don't put any extern bla() in the top of a .c file, use #include otherfile.h in there instead. So if you change a function you only have to change that particular .h file. In other words: Declare global functions in the .h file but nowhere else.
if you include header files like
#include <string.h>please add a comment why this header is needed, like
#include <string.h> /* strlen() */
If you are writing a new .c file, write a .h file for it too and include the .h file in the .c file. Use include guards in all .h files like in bluefish.h
#ifdef __BLUEFISH_H #define __BLUEFISH_H ... all the declarations here ... #endif
Reason: allow the compiler to check consistency between the .c and the .h
Antti-Juhani Kaijanaho wrote:
Olivier wrote:
Using bash (fill in your own username):
CVSROOT=:pserver:USERNAME@cvs1.openave.net:/home/cvsroot/bluefish1 export CVSROOT cvs login cvs checkout bluefishthis will download the most current bluefish development version. If you did this before you can run
cvs update -dPto update your local files with new changes. To send files:
cvs commitwill send your new changes to the CVS repository. Please always update directly before you do a commit, to check if other people are working on the same source!
Antti-Juhani wrote:
cvs checkout
cvs checkout -r branch_name
This three-stage release plan, modeled after the Debian release cycle, allows for unstable developments in parallel with release preparation.
To create a branch:
cvs tag -b name_of_branchNote that the tree where you did the cvs tag is still the trunk, not the branch. You need then to check out a new copy from the branch:
cd somewhere_else cvs checkout -r name_of_branchCommitting to this working copy commits to the branch, and the trunk is left untouched. Other people can access the branch by doing the same
cvs checkout -r.When you want to merge your changes to the trunk, do
cvs update -j name_of_branchin the old tree (the trunk). Fix any conflicts and commit.
Roland Steinbach (roland@ratisbona.com)wrote:
if you would start lets say the greek translation (gr) you would have
to:
Things to do when releasing:
... I gotta finish this