C Style: My favorite C programming practices (2014)
1–10 of 139 posts
Re: C Style: My favorite C programming practices (2014)
#2I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well.
One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise".
As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in the single precision while keeping an eye out for precision loss. Then I can either rewrite my math to try to avoid the precision loss, or selectively use double precision just in the parts where its needed. I think that using double precision from the start is a big hammer that's often unneeded. And using single precision buys you double the number of floats moving through your cache and memory bandwidth compared to using double precision.
Re: C Style: My favorite C programming practices (2014)
#3I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well. One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise". As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in…
The one about not using 'switch' and instead using combined logical comparisons is terrible ... quite opinionated, but that is usually the case with these type of style guides.
Re: C Style: My favorite C programming practices (2014)
#4Declare all variables/qualifiers right-to-left.
Read the type for all the below right-to-left, substituting the word "pointer" for "*".
int long long unsigned wibble; // unsigned long long int
double const *long_number; // pointer to a const double
double volatile * const immutable_pointer; // immutable pointer to a volatile double
Re: C Style: My favorite C programming practices (2014)
#5> Write correct, readable, simple and maintainable software, and tune it when you're done, with benchmarks to identify the choke points
If speed is a primary concern, you can't tack it on at the end, it needs to be built in architecturally. Benchmarks applied after meeting goals of read/maintainability are only benchmarking the limits of that approach and focus.
They can't capture the results of trying and benchmarking several different fundamental approaches made at the outset in order to best choose the initial direction. In this case "optimisation" is almost happening first.
Sometimes the fastest approach may not be particularly maintainable, and that may be just fine if that component is not expected to require maintaining, eg, a pure C bare-metal in a bespoke and one-off embedded environment.
Re: C Style: My favorite C programming practices (2014)
#6Declare all variables/qualifiers right-to-left. Read the type for all the below right-to-left, substituting the word "pointer" for "*". int long long unsigned wibble; // unsigned long long int double const *long_number; // pointer to a const double double volatile * const immutable_pointer; // immutable pointer to a volatile double They all read correctly now, when read right-to-left. It's not just "const" you do thi…
What's the author's justification? What's your justification?
> They all read correctly now, when read right-to-left.
... suppose I'm someone who reads from left-to-right, should I flip the order to make it correct for me?
Re: C Style: My favorite C programming practices (2014)
#7Declare all variables/qualifiers right-to-left. Read the type for all the below right-to-left, substituting the word "pointer" for "*". int long long unsigned wibble; // unsigned long long int double const *long_number; // pointer to a const double double volatile * const immutable_pointer; // immutable pointer to a volatile double They all read correctly now, when read right-to-left. It's not just "const" you do thi…
What's the author's justification? What's your justification? > They all read correctly now, when read right-to-left. ... suppose I'm someone who reads from left-to-right, should I flip the order to make it correct for me?
Readability.
C declarations can become unfriendly by being too complex and disordered.
Re: C Style: My favorite C programming practices (2014)
#8Treat 79 characters as a hard limit
Try pasting a long URL into a comment describing a method/problem/solution and you’ll see immediately that it doesn’t fit 77 chars and you cannot wrap it. Then due to your hard limit you’ll invent something like “// see explained.txt:123 for explanation” or maybe “https://shrt.url/f0ob4r” it.
There’s nothing wrong with breaking limits if you do that reasonably, cause most limits have edge cases. It’s (Rule -> Goal X) most of the times, but sometimes it’s (Rule -> Issue). Make it (Solution (breaks Rule) -> Goal X), not (Solution (obeys Rule) -> not (Goal X)).
Re: C Style: My favorite C programming practices (2014)
#9Declare all variables/qualifiers right-to-left. Read the type for all the below right-to-left, substituting the word "pointer" for "*". int long long unsigned wibble; // unsigned long long int double const *long_number; // pointer to a const double double volatile * const immutable_pointer; // immutable pointer to a volatile double They all read correctly now, when read right-to-left. It's not just "const" you do thi…
* doesn't (have to) mean "pointer"!
It works in simple cases, but I find the consistent thing to do is read it as "dereference".
double volatile *(const immutable_pointer);
// immutable_pointer is immutable, when you dereference it you'll get a volatile doubleRe: C Style: My favorite C programming practices (2014)
#10Earlier quoted context omitted.
What's the author's justification? What's your justification? > They all read correctly now, when read right-to-left. ... suppose I'm someone who reads from left-to-right, should I flip the order to make it correct for me?
Readability. C declarations can become unfriendly by being too complex and disordered.
Nothing seems wrong with “volatile double pointer as a constant” or “constant character pointer” either, tbh. The way you presented is equivalent, but non-idiomatic, people would stumble upon it often. To become more readable universally this must have been adopted 50 years ago.