On 25/01/2012 13:19, Nick Treleaven wrote:
On 24/01/2012 03:30, Matthew Brush wrote:
I probably don't know 40%+ of Geany's code after casually hacking on it
for well over a year. When reading the code, I have to refer to the
source file for each function called to see what it does, with GTK+ I've
already done this for many cases, and know what it does. When writing
the code, I have to first write it in normal GTK+ and then go through
and make sure I haven't used any functions that are wrapped in the Geany
API/headers and even other static functions in the same file. It sounds
trivial if you are intimate with the source code, but if you aren't it
can make understanding the code you need to understand in order to fix a
bug or add a feature that much harder to follow.
If the function and its parameters are well named this isn't a big problem.
BTW I think you don't need to worry about not using the utility
functions, if the equivalent code is not too bad.
Out of interest, which functions are the most annoying, any in particular?
if an expression is only nested one or two levels deep, it's easier (at
least for me) in many cases to read if the code is inline.
For a (fictional) example:
void some_func(void)
{
GError *err=NULL;
if (!g_some_func(..., &err))
{
printf ("error: %s\n", err->message);
g_error_free (err->message);
}
...
}
is easier for me to read than:
/* misc.h */
#define EZG(...) { ... actual code from above ... }
---- separate files ----
/* some.c */
void some_func(void)
{
EZG(g_some_func, ...);
...
}
Even if it saves you repeating that same 5-6 line idiom a thousand times
throughout the source, unless you wrote both pieces of code, or unless
EZG() is in a well know API like GTK+, then it makes the code harder to
read, IMO, which many more people do many more times than writing it.
When have I ever suggested doing that?
I may have overreacted there, sorry ;-)
I think your EZG macro was a bad example, because:
* it has a bad name (I accept NZV has this problem)
* it would only work for functions like g_some_func - it's not general
enough
Something like this would be better:
#define HANDLE_ERROR(err)\
printf ("error: %s\n", err->message);\
g_error_free (err);
But it would have to be used frequently to be justifiable, and I
wouldn't put it in the plugin API, probably not even in a header. Also
usually the error format string would be more specific - rather than add
another parameter I would say at that point HANDLE_ERROR becomes not
worthwhile.
I realize now that in general we should probably avoid macros.
Nick
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
