Bluefish code style
This documents described the conventions to use when coding in the Bluefish project. Please suggest improvements or additions. I'm not a that good C programmer myself ;-)
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.linuxbox.com/
Indenting and formating style
just be lazy and use
indent -kr -ts4 -l140 *.c *.h
This is the Kernighan & Ritchie coding style, with tabsize 3 and linelenght 140
Naming
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)
Declaring procedures
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 in a file should be in the top section declared, all procedures that are used in other files as well should be in the .h file.
Global variables should be in the .h with an extern as well.
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.
New files
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 #ifdef __BLUEFISH_H
#define __BLUEFISH_H
... all the declarations here ...
#endif
Reason: allow the compiler to check consistency between the .c and the .h
Which files
This is currently the worst structured:
- bluefish.c - start and exit, and some very general functions
- callbacks.c - all kind of callbacks for file handling, project opening
- cap.c - caps or non caps HTML
- coloursel.c - colorselection, this is kind of an own widget
- commandline.c - parse commandline
- configure.c - configuration dialog
- gtk_easy.c - easy GTK shortcuts to reduce repeating code
- highlight.c -the synta highlighting code
- html.c - dialogs and callbacks
- html2.c - dialogs and callbacks
- images.c - image and thumbnail dialogs
- init.c - parse rcfile to load options
- interface.c - the GUI itself, and the document
- network.c - load from web code, a dead link check can be added here as well
- ref_dialog.c - the reference dialog
- rpopup.c - right click menu and parsing of the HTML into a GList
- snr.c - search and replace, cut, copy and paste
- stringlist.c - stringlist (GList with strings) handling functionality inc. GUI
- toolbars.c - the toolbars including the menu and custom menu (and the buggy custom menu editor)
- undo.c - undo/redo
- wizards.c -wizards
Patches
Antti-Juhani Kaijanaho wrote:
- I keep two code trees of bluefish, one untouched (an official pre
unpacked) and one where I do my work. For every unrelated change
I make a new tree for my changes.
- Before making a patch, run "make patchclean" (or whatever; on
projects following the GNU standards that would be "make maintainer-clean")
on both trees. "make distclean" should do as well, shouldn't it?
- When I want to make a patch, I cd to the parent dir of the two
trees. I then run "diff -Naur official-pre-tree my-changed-tree | bzip2 -9c
> patchbla.diff.bz2" (where official-pre-tree and my-changed-tree are
the two code trees.