Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Style: My favorite C programming practices (2014)

github.com

Post reply on HN
Print view View original

11–20 of 139 posts

Re: C Style: My favorite C programming practices (2014)

#11

Post by Someone »

mrkeen wrote: post #6
liblfds-temp wrote: post #4

Declare 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?

> What's the author's justification? What's your justification?

I’m neither of them, but chances are that’s because you can’t make them left-to-right all the time.

  double const *foo; // foo is a pointer to a const double
  double *const foo; // foo is a const pointer to a double
compile and do what the comment says; these do not compile:

  * const double foo; // a pointer to a const double named “foo”
  foo * const double; // foo is a pointer to a const double

Re: C Style: My favorite C programming practices (2014)

#12

Post by kleiba »

wruza wrote: post #8

Treat 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 h…

Agree. This 80 character limit stems from a time where terminals could only display comparatively few characters in a line, a limit we haven't had in decades as screen resolutions grew.

Another argument for shorters lines is that it is much harder for us to read any text when lines get too long. There's a reason why we read and write documents in portrait mode, not landscape.

But in sum, I don't think there's a need for creating a hard limit at the 80 character mark. Most code is not indented more than three or four times anyways, and most if not all languages allow you to insert newlines to make long expressions wrap. However, if you occasionally do need to go longer, I think that's completely fine and certainly better than having to bend around an arcane character limit.

Re: C Style: My favorite C programming practices (2014)

#13

Post by aulin »

amszmidt wrote: post #3
a_e_k wrote: post #2

I 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.

it's like they purposely add some controversial rule just for engagement

Re: C Style: My favorite C programming practices (2014)

#14

Post by lifthrasiir »

wruza wrote: post #8

Treat 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 h…

And at the very least, "80-characters-per-line is a de-facto standard for viewing code" has been long wrong. As the post even mentions, 100 and 120 columns have been another popular choices and thus we don't really have any de-facto standard about them!

Re: C Style: My favorite C programming practices (2014)

#16

Post by lifthrasiir »

a_e_k wrote: post #2

I 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…

I think the fact that graphics care a lot more about efficiency over marginal accuracy qualifies for a specific reason. Besides from that and a few select areas like ML, almost any reason to use `float` by default vanishes.

Re: C Style: My favorite C programming practices (2014)

#17

Post by ezconnect »

amszmidt wrote: post #3
a_e_k wrote: post #2

I 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.

He even uses 'switch' on his code.

Re: C Style: My favorite C programming practices (2014)

#19

Post by ack_complete »

a_e_k wrote: post #2

I 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…

I'm torn both ways on the double issue. On the one hand, doubles are much more widely supported these days, and will save you from some common scenarios. Timestamps are a particular one, where a float will often degrade on a time scale that you care about, and doubles not. A double will also hold any int value without loss (on mainstream platforms), and has enough precision to allow staying in world coordinates for 3D geometry without introducing depth buffer problems.

OTOH, double precision is often just a panacea. If you don't know the precision requirements of your algorithm, how do you know that double precision will work either? Some types of errors will compound without anti-drifting protection in ways that are exponential, where the extra mantissa bits from a double will only get you a constant factor of additional time.

There are also current platforms where double will land you in very significant performance problems, not just a minor hit. GPUs are a particularly fun one -- there are currently popular GPUs where double precision math runs at 1/32 the rate of single precision.

Re: C Style: My favorite C programming practices (2014)

#20

Post by spc476 »

Someone wrote: post #11
mrkeen wrote: post #6

Earlier 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?

> What's the author's justification? What's your justification? I’m neither of them, but chances are that’s because you can’t make them left-to-right all the time. double const *foo; // foo is a pointer to a const double double *const foo; // foo is a const pointer to a double compile and do what the comment says; these do not compile: * const double foo; // a pointer to a const double named “foo” foo * const double;…

I use the "right-to-left" style myself. To me, the qualifier (in this case, const), applies to the item to the right. This could be confusing:

    const char *const ptr;
The first const applies to the char, but the second one to the pointer itself. Being consistent:

    char const *const ptr;
The first const applies to the item to its left---char. The second const applies to the item to its left---the pointer. To recap:

    char *ptr1; // modifiable pointer to modifiable data
    char const *ptr2; // modifiable pointer to const data
    char *const ptr3; // const pointer to modifiable data
    char const *const ptr4; // const pointer to const data
Post reply on HN