cURL / Mailing Lists / curl-library / Single Mail

curl-library

cleaning

From: Daniel Stenberg <daniel_at_haxx.se>
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.html
Received on 2011-04-06