Here is a brief piece I wrote that Jack Ganssle just ran in The Embedded Muse 460.
The context was a previous discussion about enabling compiler warnings.
John Carter's suggestion to use compiler warnings as a
first step toward coding standards is an important one. I tend to
split these up into "coding style for people" and "coding styles for
the compiler." Often we talk about indenting curly braces and tabs vs.
spaces (for people) -- but making sure the compiler isn't confused
about what you mean is also important. For those who've never
contemplated the difference you might find video lectures #4 and #5 here
of interest: http://course.ece.cmu.edu/~ece642/ UPDATE 1/23/2023: thanks to a social media commenter for pointing out that some of the listed warnings are redundant. My revised recommendation that implements the same compiler behavior is: -Werror -Wextra -Wall -Wfloat-equal -Wconversion -Wredundant-decls -Wswitch-default -pedantic Can be omitted because already in -Wall: -Wparentheses -Wunused-variable -Wreturn-type -Wunused-function -Wreturn-type -Wunused-value -Winit-self -Wuninitialized Can be omitted because already in -Wextra: You should also consider enforcing C standard support to avoid gcc-specific features that will be less portable. You can do this by for example adding the flag "-std=c11" or "-std=c++11" as appropriate. If you have a compiler other than GCC, then you will need to consider those proprietary warning flags to achieve a similar outcome. |
No comments:
Post a Comment
Please send me your comments. I read all of them, and I appreciate them. To control spam I manually approve comments before they show up. It might take a while to respond. I appreciate generic "I like this post" comments, but I don't publish non-substantive comments like that.
If you prefer, or want a personal response, you can send e-mail to comments@koopman.us.
If you want a personal response please make sure to include your e-mail reply address. Thanks!