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

51–60 of 139 posts

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

#51

Post by ReleaseCandidat »

f1shy wrote: post #21
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…

No rule is absolute. So you may have some line longer. Anyway I’m VERY skeptic that hardcoding URLs is a good idea at all.

> Anyway I’m VERY skeptic that hardcoding URLs is a good idea at all.

They are talking about URLs in comments.

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

#52

Post by sdk77 »

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…

There are popular embedded platforms like STM32 that don't have hardware double support, but do have hardware float support. Using double will cause software double support to be linked and slow down your firmware significantly.

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

#53

Post by jeffdaniels27x »

f1shy wrote: post #22
kleiba wrote: post #12

Earlier quoted context omitted.

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…

> 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. The 80 char rule has little to do with old monitors. Has to do with ergonomics, and is why any good edited and typeset book will have between 60 and 80 characters per line.

Then let it be 80 characters from any whitespace on the left-hand side? I find it artificially awkward to have to wrap at a hard margin on the right-hand side. Surely you need to accommodate any indenting you're doing?

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

#54

Post by teddyh »

ack_complete wrote: post #19
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 3…

I think you used the word “panacea” incorrectly. Judging by context, I would guess that the word “band-aid” would better convey your intended meaning.

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

#55

Post by [deleted] »

ack_complete wrote: post #19
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 3…

[deleted]

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

#56

Post by planede »

Y_Y wrote: post #9
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…

* 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 double

Yes, that's the philosophy around the declaration syntax.

The declaration of the pointer ip,

  int *ip;
is intended as a mnemonic; it says that the expression *ip is an int. The syntax of the declaration for a variable mimics the syntax of expressions in which the variable might appear. This reasoning applies to function declarations as well.

K&R C

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

#57

Post by jstimpfle »

lifthrasiir wrote: post #28

While I don't agree every single point (see below), one thing great about this document is that the author tried to really elaborate one's opinion. That makes a good point to start the discussion regardless of my own opinion. Thus I'll contribute back by giving my own judgement for every single item here: Absolute agreement * Always develop and compile with all warnings (and more) on * #include the definition of ever…

> * We can't get tabs right, so use spaces everywhere > [as long as mechanically enforcable, the choice itself is irrelevant]

It's not mechanically enforceable (in practice), that's the point. Forbidding tabs altogether is the most practical and actionable path.

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

#58

Post by sph »

> Always write to a standard, as in -std=c11. Don't write to a dialect, like gnu11. Try to make do without non-standard language extensions: you'll thank yourself later.

Why not? Do people really care about porting their toy project to another compiler? If portability is a goal, avoid extensions, but not all projects need to be portable.

I'm writing an Operating System, and I do not care it if compiles on Clang or MSVC. GCC has been around for decades, it is a safe bet.

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

#59

Post by diath »

sph wrote: post #58

> Always write to a standard, as in -std=c11. Don't write to a dialect, like gnu11. Try to make do without non-standard language extensions: you'll thank yourself later. Why not? Do people really care about porting their toy project to another compiler? If portability is a goal, avoid extensions, but not all projects need to be portable. I'm writing an Operating System, and I do not care it if compiles on Clang or MS…

Personally I do, the Windows builds for my game use a Windows VM with MSVC, the Linux builds use GCC for certain optimizations, and for the dev builds I use Clang for sanitizers. Sure, you mention "a toy project" but he's talking about trying to avoid non-standard extensions in general, which is a fair point.

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

#60

Post by lifthrasiir »

jstimpfle wrote: post #57
lifthrasiir wrote: post #28

While I don't agree every single point (see below), one thing great about this document is that the author tried to really elaborate one's opinion. That makes a good point to start the discussion regardless of my own opinion. Thus I'll contribute back by giving my own judgement for every single item here: Absolute agreement * Always develop and compile with all warnings (and more) on * #include the definition of ever…

> * We can't get tabs right, so use spaces everywhere > [as long as mechanically enforcable, the choice itself is irrelevant] It's not mechanically enforceable (in practice), that's the point. Forbidding tabs altogether is the most practical and actionable path.

I'm not sure what you have in mind, but in my mind the mechanical enforcement really means something like clang-format [1] and that surely works.

[1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html#use...

Post reply on HN