curl-library
cleaning
Date: Wed, 6 Apr 2011 09:03:06 +0200 (CEST)
Hi friends,
Recently I've taken upon myself to do a little cleaning in the code and I
thought I'd share with you the general principle behind it. I'm not at all
finished by any means but I'm attacking a little here and there and polish up
a little piece at a time.
I have three primary goals with the cleaning up:
1 - Reduce #if and #ifdef use in code, and push them as far as possible to
header files. Functions not present in a particular build get #defined
etc. This increases readability and also makes it easier to change code
and write new code that uses these functions.
In some cases it does alter behavior, as now for example trying to use a
proxy in a proxy-disabled build will actually return an error while
previously the proxy option would just be ignored.
2 - Make sure the generic protocol-agnostic code gets more protocol-unaware.
It is much better that we check for features set in the protocol handler
struct (without knowing which protocol it is) or to call functions
provided in the protocol handler struct to reduce checks for specific
protocols. This makes readers of the code not having to understand _why_
the code checks for a protocol as instead we check for the particular
feature of the protocol that makes it special.
3 - Move protocol-specific code into their protocol-specific source files.
It reduces #ifdefs for when the protocol is disabled or unavailable and
it also makes it easier to find the particular functions when you're
trying to figure out how libcurl deals with particular protocols.
All in all, the result should make it possible to put each .c file into one of
these three categories:
A - Core transfer functionality. Functions and code that deal with transfers
and the public API independently from which exact protocol it is. (url.c,
connect.c, transfer.c, sendf.c, hostip.c, multi.c, easy.c etc).
Protocol-specific code should not exist in these files.
B - Protocol or feature specific code. Provide functions for something
specific. May be disabled/enabled in builds. (http.c, socks.c, ftp.c,
dict.c, ssluse.c, gtls.c, openldap.c, cyassl.c, ....)
C - Helper functions. Some of the protocols are so similar they have a bunch
of functions used for multiple protocols and lots of core code need helper
functions for all sorts of things. (hash.c mprintf.c getenv.c wildcard.c
warnless.c timeval.c strdup.c strequal.c llist.c ...)
I'm contemplating changing the source structure or naming to reflect the
nature of each source file, but I'm not sure it's needed.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2011-04-06