Re: [dev] Learn C

From: <sylvain.bertrand_AT_gmail.com>
Date: Sun, 24 Mar 2019 13:33:30 +0000

On Sun, Mar 24, 2019 at 10:28:35AM +0100, Thuban wrote:
> Hi,
> I want to learn C. I mean, sane C.
> What i read before was based on big IDE such as codeblocks. So, I don't
> know how to write Makefiles from scratch. (just an example).
> As an example, I found gobyexample [1] great. But it's go.
> Any reading advice?


Don't bother with makefiles yet, just use plain simple shell scripts.
sane C = simple C.

C has already a syntax way too rich and flexible. Most of the
linux coding guidelines is nice.

* do not use enum (hard rule)
* do not use typedef (hard rule)
* declare your variables at the beginning of a block (c99 allows declarations a
  bit everywhere, bad). personnally I try to keep my variables declared first, then
  the variables with assignment, because it's actually code (presume C
  initializers are code).
* organise your code to _kind of_
   * avoid more than 3 depth levels in a function
   * avoid too many variables in a function
   * keep roughly 80 columns code in order to have several readable columns on
     a "standard screen".
* goto is appropriate in some cases
* I personnaly add a macro #define loop for(;;) and use only 1 loop
  statement (hard rule)
* try to stick to lower case identifiers
* use sized types: u8 u16 i64 float32 etc... you can use the C
  preprocessor to fix that, but in some case, as a good tradeof (for instance in
  "object oriented C code"), add a suffix to your type (u8_t, struct my_class_t), then
  for instance you can nest structs, struct base_type_t base_type.
* try to avoid as much as possible dependencies: Keep in mind the "technical
  cost" of your code, an optimizing compiler toolchain is extremely expensive
  (and all are turning into c++ garbage)
* to help you "calibrate", read the "unix philosophies" out there (cf wikipedia).
* complex code is not cool and does not make you smart: "The notion of
  'intricate and beautiful complexities' is almost an oxymoron" (cf all c++
   code and similar)
* as a tradeof to avoid becoming a strong type extremist: view primitive
  variables as CPU hardware registers, so be carefull with your type casting.
* always presume you will have to write a C preprocessor and compiler
* keep your canonical SDK idiotic and simple
* monkey patching is extremely bad (aka "corporate code")

I certainly forget a ton of things, and tradeofs have to be done case by
case. Nothing is set in stone. We all do mistakes.

Keep in mind that we are all different, then we will draw "lines" not in the
same way, but there is an absolute value which is true for all: the "technical
cost" of your code and your deps (SDKs included).

-- 
Sylvain
Received on Sun Mar 24 2019 - 14:33:30 CET

This archive was generated by hypermail 2.3.0 : Tue Mar 26 2019 - 19:24:08 CET