[Geany-devel] encoding combo boxes bug - utility functions

[Nick Treleaven]

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