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)?
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
