Principles for C programming
I&#x27;ll wade in a little.<p>&gt; Don&#x27;t use macros.<p>&gt; Don&#x27;t use the inline keyword<p>&gt; Never put code into a header<p>I disagree with these.  It&#x27;s often critical to avoid a function call in hot paths, and if you don&#x27;t use macros or inline you have to resort to copy&#x2F;paste, which is error-prone and hampers maintainability.<p>It&#x27;s also the case that C is a rather inflexible language.  Macros can be extraordinarily helpful in reducing boilerplate: in unit testing, for example.  I won&#x27;t argue that macro definitions are the easiest things to read (usually they&#x27;re OK but they can get pretty arcane), but I do think something that cuts a file down from 8,000 lines to 1,000 is at least worth considering.<p>Macros can also help you maintain type safety.  Colin Perciva demonstrated this a little with his elasticarray, but khash is another example of using macros to dynamically create type safe data structures.  It can also help the compiler optimize your code.<p>&gt; Don&#x27;t use fixed-size buffers<p>Everything is a fixed-size buffer until you change its size.  If you malloc a buffer of 1024 bytes and read 1025 bytes of user input into it, you overflowed anyway.  The principle ought to be &quot;check your bounds&quot;, which applies whether your buffer is stack&#x2F;heap.<p>&gt; Do not use a typedef to hide a pointer or avoid writing “struct”.<p>I&#x27;m with you on pointer hiding (looking at you FreeType), but &quot;struct&quot; is just far too verbose.  You don&#x27;t accidentally pass things by value because the compiler will tell you you&#x27;re passing the wrong type.  You won&#x27;t think it&#x27;s actually a scalar because you have a grand total of 3 scalars in C (bool&#x2F;int&#x2F;float), and if you don&#x27;t know the types you&#x27;re working with in your functions you should probably look them up.<p>You probably don&#x27;t think this is a big issue because you don&#x27;t adhere to 80 columns in your code (I looked @ your GitHub briefly), but let me tell you you run out of space real quick, and &quot;struct&quot; is practically meaningless.<p>I found a good example:<p><pre><code>  static void set_background(struct wl_client *client, struct wl_resource *resource,
  		struct wl_resource *_output, struct wl_resource *surface) {
</code></pre>
vs.<p><pre><code>  static void set_background(wl_client *client, wl_resource *resource,
                                                wl_resource *_output,
                                                wl_resource *surface) {
</code></pre>
These are obviously not ints, it&#x27;s a lot easier to read, and it fits in terminals.  &quot;struct&quot; is honestly just noise.<p>&gt; GNU is a blight on this Earth<p>Come on now.  I hate GNU indentation as much as any reasonable person, but I don&#x27;t think we need to go this far.<p>---<p>Unrelated: aerc looks great!  I&#x27;ve been thinking about moving off gmail and moving more of my life back into the terminal (I used to be all mutt and IRC and now I&#x27;m gmail and hangouts :&#x2F; ), and I really like aerc&#x27;s well-organized code.  Nice work.