smtp: use the upload buffer size for scratch buffer malloc
[platform/upstream/curl.git] / docs / CODE_STYLE.md
index 73a4d94..ba5f710 100644 (file)
@@ -1,4 +1,4 @@
-# cURL C code style
+# curl C code style
 
 Source code that has a common style is easier to read than code that uses
 different styles in different places. It helps making the code feel like one
@@ -9,8 +9,8 @@ style is more important than individual contributors having their own personal
 tastes satisfied.
 
 Our C code has a few style rules. Most of them are verified and upheld by the
-lib/checksrc.pl script. Invoked with `make checksrc` or even by default by the
-build system when built after `./configure --enable-debug` has been used.
+`lib/checksrc.pl` script. Invoked with `make checksrc` or even by default by
+the build system when built after `./configure --enable-debug` has been used.
 
 It is normally not a problem for anyone to follow the guidelines, as you just
 need to copy the style already used in the source code and there are no
@@ -28,7 +28,8 @@ other places of the code, just that the names should be logical,
 understandable and be named according to what they're used for. File-local
 functions should be made static. We like lower case names.
 
-See the INTERNALS document on how we name non-exported library-global symbols.
+See the [INTERNALS](INTERNALS.md) document on how we name non-exported
+library-global symbols.
 
 ## Indenting
 
@@ -50,7 +51,7 @@ introduced in the C standard until C99. We use only `/*` and `*/` comments:
 
 ## Long lines
 
-Source code in curl may never be wider than 80 columns and there are two
+Source code in curl may never be wider than 79 columns and there are two
 reasons for maintaining this even in the modern era of very large and high
 resolution screens:
 
@@ -72,8 +73,12 @@ the initial keyword. Like this:
       /* clearly a youngster */
     }
 
-When we write functions however, the opening brace should be in the first
-column of the first line:
+You may omit the braces if they would contain only a one-line statement:
+
+    if(!x)
+      continue;
+
+For functions the opening brace should be on a separate line:
 
     int main(int argc, char **argv)
     {
@@ -162,6 +167,53 @@ Examples:
     complement = ~bits;
     empty = (!*string) ? TRUE : FALSE;
 
+## Column alignment
+
+Some statements cannot be completed on a single line because the line would
+be too long, the statement too hard to read, or due to other style guidelines
+above. In such a case the statement will span multiple lines.
+
+If a continuation line is part of an expression or sub-expression then you
+should align on the appropriate column so that it's easy to tell what part of
+the statement it is. Operators should not start continuation lines. In other
+cases follow the 2-space indent guideline. Here are some examples from libcurl:
+
+~~~c
+    if(Curl_pipeline_wanted(handle->multi, CURLPIPE_HTTP1) &&
+       (handle->set.httpversion != CURL_HTTP_VERSION_1_0) &&
+       (handle->set.httpreq == HTTPREQ_GET ||
+        handle->set.httpreq == HTTPREQ_HEAD))
+      /* didn't ask for HTTP/1.0 and a GET or HEAD */
+      return TRUE;
+~~~
+
+~~~c
+  case CURLOPT_KEEP_SENDING_ON_ERROR:
+    data->set.http_keep_sending_on_error = (0 != va_arg(param, long)) ?
+                                           TRUE : FALSE;
+    break;
+~~~
+
+~~~c
+    data->set.http_disable_hostname_check_before_authentication =
+      (0 != va_arg(param, long)) ? TRUE : FALSE;
+~~~
+
+~~~c
+  if(option) {
+    result = parse_login_details(option, strlen(option),
+                                 (userp ? &user : NULL),
+                                 (passwdp ? &passwd : NULL),
+                                 NULL);
+  }
+~~~
+
+~~~c
+        DEBUGF(infof(data, "Curl_pp_readresp_ %d bytes of trailing "
+                     "server response left\n",
+                     (int)clipamount));
+~~~
+
 ## Platform dependent code
 
 Use `#ifdef HAVE_FEATURE` to do conditional code. We avoid checking for