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.
then that's a significant benefit in avoiding temporary variables or nested expressions, which are harder to read. As I said, if the function is obvious, there's no harm.
You don't really avoid temp vars, you just put them in another file. And
Eh? You have *one* copy of the temp var, not e.g. 10.
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?