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

Matthew Brush mbrush at xxxxx
Thu Jan 26 02:06:01 UTC 2012


On 01/25/2012 08:01 AM, Nick Treleaven wrote:
> 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.
>

Good to know :)

> Out of interest, which functions are the most annoying, any in particular?
>

It's mostly the little ones in utils/ui_utils[1] that wrap common C/GTK+ 
stuff, like the last two I whined about lately, or as we discussed a 
while back, single use static functions that some people find harder to 
read compared to putting that code into the function that uses it.

>>> 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 ;-)
>

Not at all, it was a bad example indeed, I just wanted some code to show 
where the code is obscured by being in another function and file, that's 
the only purpose of the example.

> I think your EZG macro was a bad example, because:

Yeah, it was just a quick example off the top of my head, I truly 
shouldn't have put a macro in the example, since a function would've 
shown what I meant without being absurd.

> * it has a bad name (I accept NZV has this problem)

Heh, that's why I chose that name :)

Cheers,
Matthew Brush

[1] Just at a very quick scan through utils.c, things like 
utils_slist_remove_next(), utils_is_uri(), utils_string_replace(), 
utils_spawn_async()*, utils_build_path(), utils_make_filename(), and so on.

* might be needed for win32 or something (shouldn't though)?




More information about the Devel mailing list