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

111–120 of 139 posts

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

#111

Post by xigoi »

LeoNatan25 wrote: post #66
xipix wrote: post #42

Earlier quoted context omitted.

A proportional font really helps ergonomics too.

This is probably a snarky reply, but here is the serious answer: proportional fonts, with appropriate kerning, is a lot more legible than monospaced font. There is a reason why the press moved into that direction once it was technically feasible. But the same people that bring books as an example why 80 character line length should be enforced would gag at the notion of using proportional fonts for development. It ju…

Code uses much more punctuation than prose, and punctuation is hard to discern in a proportional font.

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

#112

Post by eschneider »

ragnese wrote: post #108
eschneider wrote: post #50

Earlier quoted context omitted.

Well, yes. Architect for performance, try not to do anything "dumb", but save micro-optimizations for after performance measurement.

The problem with all of these rules of thumb is that they're vague to the point of being vacuously true. Of course we all agree that "premature optimization is the root of all evil" as Knuth once said, but the saying itself is basically a tautology: if something is "premature", that already means it's wrong to do it. I'll be more impressed when I see specific advice about what kinds of "optimizations" are premature.…

Ok, a bit more detail then. :)

Architecting for performance means picking your data structures, data flow, and algorithms with some thought towards efficiency for the application you have in mind. Details will vary a lot depending on context. But as many folks have said, this sort of thing can't be done after the fact.

As for "doing something dumb", I've often seem fellow engineers do things like repeatedly insert into sorted data structures in a loop instead of just inserting into an unsorted structure and then sorting after the inserts. If you think about it for just a minute, it should be obvious why that's not smart (for most cases.) Stuff like that.

What do I mean by "micro-optimizations"? Taking a clearly written function and spending a lot of time making it as efficient _as_possible_ (possibly at the expense of clarity) without first doing some performance analysis to see if it matters.

Nobody's saying to pick suboptimal solutions at all.

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

#113

Post by a1369209993 »

teddyh wrote: post #54
ack_complete wrote: post #19

Earlier quoted context omitted.

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.

IIUC, they're using the word itself correctly, but they mean "double precision is often used with the intent of it being a panacea".

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

#114

Post by yoochan »

"We can't get tabs right, so use spaces everywhere"

I'm more like: Always use tabs, never use space. Code doesn't need to be "aligned" it's not some ASCIIart masterpiece...

One tab means one indentation level and if your taste is to have tabs of pi chars wide, nice! But it won't mess my code

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

#115

Post by kleiba »

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.

It has to do with both and that's why my comment mentions both.

But then again, of course there is a reason why terminals (or punchcards) were made that way - presumably because of reading / writing ergonomics (besides technical reasons).

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

#116

Post by kllrnohj »

nanolith wrote: post #75
LeoNatan25 wrote: post #24

> 80-characters-per-line is a de-facto standard for viewing code. Readers of your code who rely on that standard, and have their terminal or editor sized to 80 characters wide, can fit more on the screen by placing windows side-by-side. This is one of the silliest practices to still be enforced or even considered in 2024. “Readers” should get a modern IDE/text editor and/or modern hardware.

On my 4K monitor, I use 4-5 vertical splits and 2-3 horizontal splits. The 80 column rule makes each of these splits readable, and allows me to see the full context of a chunk of kernel code or firmware at once. It has nothing to do with "modern" hardware or "modern" IDEs. It has everything to do with fitting the most amount of relevant information that I can on the screen at once, in context, and properly formatted…

> Even FAANG companies like Google follow this rule.

Google also uses 100

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

#117

Post by nanolith »

kllrnohj wrote: post #116
nanolith wrote: post #75

Earlier quoted context omitted.

On my 4K monitor, I use 4-5 vertical splits and 2-3 horizontal splits. The 80 column rule makes each of these splits readable, and allows me to see the full context of a chunk of kernel code or firmware at once. It has nothing to do with "modern" hardware or "modern" IDEs. It has everything to do with fitting the most amount of relevant information that I can on the screen at once, in context, and properly formatted…

> Even FAANG companies like Google follow this rule. Google also uses 100

Most of their monorepo code I came across used 80 columns. But, I can't speak for all of it. Google has a LOT of code.

Either way, if Google and other companies can do what they do in 80 columns, I think it's a fair constraint. What we get out of this constraint is the ability to put a lot of context on the screen.

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

#118

Post by jayd16 »

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.

This rules readme isn't even less than 80 characters per line. You're saying we all had trouble reading it?

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

#119

Post by jstimpfle »

lifthrasiir wrote: post #60
jstimpfle wrote: post #57

Earlier quoted context omitted.

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

Have you actually tried? Personally I have evaluated and then abandonded clang-format (for reasons including but not limited to the interplay between macros and indentation), and most tool's support for tab-indentation + space-alignments is flaky to non-existent. I wouldn't want to constrain my setup to one that integrates clang-format just for a needlessly complicated requirement when I could just abandon tabs altogether.

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

#120

Post by atiedebee »

projektfu wrote: post #85
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 issue for me is that unlabeled constants are doubles and they can cause promotion where you don't expect it, leading to double arithmetic and rounding instead of single arithmetic. Minor issue, but hidden behavior.

What's even more annoying is that the *printf functions take in double which forces you to cast all of the floats you pass in when using -Wdouble-promotion
Post reply on HN