4 ms·

>Do not use macros. Do not use a typedef to hide a pointer or avoid writing “struct”. Avoid writing complex abstractions. Keep your build system simple and tran

>Do not use macros. Do not use a typedef to hide a pointer or avoid writing “struct”. Avoid writing complex abstractions. Keep your build system simple and transparent. Don’t use stupid hacky crap just because it’s a cool way of solving the problem. Heh, good luck avoiding the use of macros in sufficiently complex projects - sometimes C just can't use some control structures in an elegant manner without using macros or custom abstractions.

mbel 10y ago
Can you provide an example of control structures that cannot be used in elegant manner without macros? I honestly fail to think of any example. However I generally agree, that macros are pretty much unavoidable. Include guards are implemented using macro constants. It is pretty much the only portable way to force inlining (in some cases this might be necessary). Variadic macros are a easier to create that variadic functions (e.g. wrapper around fprintf for logging). And there is also the '_Generic' thing for people, who can use C11.
- fpoling 10y ago
  Another unavoidable use of macros is to convert symbolic names into string literals or to enable warnings for printf wrappers in a portable code. As for include guards one has to look really hard [1] to get a compiler that does not support #pragma once. [1] - https://en.wikipedia.org/wiki/Pragma_once#Portability https://en.wikipedia.org/wiki/Pragma_once#Portability
huhtenberg 10y ago
> Do not use macros. Sir, yes, sir. I will throw away "offsetof" and "container_of" right now, just give me a moment. > Do not use a typedef to hide a pointer or avoid writing “struct” Somewhat agree with the former, but completely disagree with the latter. If there's a single thing that is not right with C is its excessive verbosity in places where none is needed. Not typedef'ing your structs forces you to use extra 7 characters per type mention for no clear benefit. To put it differently - if NOT having "struct" in front of a type name has any effect on readability/maintainability of your code, then there are deeper problems with your coding style that won't be solved by dragging "struct" around.
- ddevault 10y ago
  >Not typedef'ing your structs forces you to use extra 7 characters per type mention for no clear benefit. To put it differently - if NOT having "struct" in front of a type name has any effect on readability/maintainability of your code, then there are deeper problems with your coding style that won't be solved by dragging "struct" around. The benefit is to readability. You should treat structs differently from scalars, and the code should make the distinction apparent. You should not generally, for example, pass structs by value. This is just laziness.
  - huhtenberg 10y ago
    Not sure I follow. > scalars So you would typedef the scalars then? If you don't, then scalars will be the built-in types (which you'd presumably know well) and then all other type names will be typedef'ed structs/unions, still making it trivial to recognize them as such.
    - Sir_Cmpwn 10y ago
      Yes, I think typedefing scalars is fine. Typedefs are useful for abstracting the underlying storage mechanism for a scalar (so you can i.e. change it on different archictures or in a future release without breakage), not for saving yourself 6 characters of typing.
      - eps 10y ago
        Typedefs are useful for creating short-hand names for otherwise long or complicated type definitions. Saving 7 (6 for 'struct' + space) characters is as good use for typedef as any other.
        falcolas 10y ago
        You only have to write each set of seven characters once; yes, typing will require a bit more effort. However, we shouldn't optimize code for the ease of writing, we should be optimizing for the ease of reading. Write once, read many. `struct foo` is a bit more instructive when understanding code than `foo`; at worst, they read the same to someone familiar to the codebase, at best they prevent the need to flip back and forth to the type definitions.
petters 10y ago
Also, typedef make things like arrays of function pointers much easier to read.
- makapuf 10y ago
  It all depends on the level. array of pointers to func to array of structs X , yes. struct X, no.
ziikutv 10y ago
For somethings like setting up boards, typedef is sometimes required too; or at least that is what I was told in my class xD
andrepd 10y ago
I think these are just basic general principles, not unbreakable rules. Keep them in mind but break them when you really have too. Like the quote at the beginning says, avoid doing stupid things, but don't refrain from doing clever things when you have to.

mbel 10y ago

Can you provide an example of control structures that cannot be used in elegant manner without macros? I honestly fail to think of any example. However I generally agree, that macros are pretty much unavoidable. Include guards are implemented using macro constants. It is pretty much the only portable way to force inlining (in some cases this might be necessary). Variadic macros are a easier to create that variadic functions (e.g. wrapper around fprintf for logging). And there is also the '_Generic' thing for people, who can use C11.

fpoling 10y ago
Another unavoidable use of macros is to convert symbolic names into string literals or to enable warnings for printf wrappers in a portable code. As for include guards one has to look really hard [1] to get a compiler that does not support #pragma once. [1] - https://en.wikipedia.org/wiki/Pragma_once#Portability https://en.wikipedia.org/wiki/Pragma_once#Portability

huhtenberg 10y ago

> Do not use macros. Sir, yes, sir. I will throw away "offsetof" and "container_of" right now, just give me a moment. > Do not use a typedef to hide a pointer or avoid writing “struct” Somewhat agree with the former, but completely disagree with the latter. If there's a single thing that is not right with C is its excessive verbosity in places where none is needed. Not typedef'ing your structs forces you to use extra 7 characters per type mention for no clear benefit. To put it differently - if NOT having "struct" in front of a type name has any effect on readability/maintainability of your code, then there are deeper problems with your coding style that won't be solved by dragging "struct" around.

ddevault 10y ago
>Not typedef'ing your structs forces you to use extra 7 characters per type mention for no clear benefit. To put it differently - if NOT having "struct" in front of a type name has any effect on readability/maintainability of your code, then there are deeper problems with your coding style that won't be solved by dragging "struct" around. The benefit is to readability. You should treat structs differently from scalars, and the code should make the distinction apparent. You should not generally, for example, pass structs by value. This is just laziness.
- huhtenberg 10y ago
  Not sure I follow. > scalars So you would typedef the scalars then? If you don't, then scalars will be the built-in types (which you'd presumably know well) and then all other type names will be typedef'ed structs/unions, still making it trivial to recognize them as such.
  - Sir_Cmpwn 10y ago
    Yes, I think typedefing scalars is fine. Typedefs are useful for abstracting the underlying storage mechanism for a scalar (so you can i.e. change it on different archictures or in a future release without breakage), not for saving yourself 6 characters of typing.
    - eps 10y ago
      Typedefs are useful for creating short-hand names for otherwise long or complicated type definitions. Saving 7 (6 for 'struct' + space) characters is as good use for typedef as any other.
      - falcolas 10y ago
        You only have to write each set of seven characters once; yes, typing will require a bit more effort. However, we shouldn't optimize code for the ease of writing, we should be optimizing for the ease of reading. Write once, read many. `struct foo` is a bit more instructive when understanding code than `foo`; at worst, they read the same to someone familiar to the codebase, at best they prevent the need to flip back and forth to the type definitions.

petters 10y ago

Also, typedef make things like arrays of function pointers much easier to read.

makapuf 10y ago
It all depends on the level. array of pointers to func to array of structs X , yes. struct X, no.

ziikutv 10y ago

For somethings like setting up boards, typedef is sometimes required too; or at least that is what I was told in my class xD

andrepd 10y ago

I think these are just basic general principles, not unbreakable rules. Keep them in mind but break them when you really have too. Like the quote at the beginning says, avoid doing stupid things, but don't refrain from doing clever things when you have to.