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

31–40 of 139 posts

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

#31

Post by jonathanstrange »

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.

There is a reason why books have only between 45 to 75 characters per line. It greatly enhances readability.

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

#32

Post by vbezhenar »

robxorb wrote: post #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 benchmarki…

I don't know if this embedded development still alive. I'm writing firmware for nRF BLE chip which is supposed to run from battery and their SDK uses operating system. Absolutely monstrous chips with enormous RAM and Flash. Makes zero sense to optimize for anything, as long as device sleeps well.

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

#33

Post by jackiesshirt »

>Prefer compound literals to superfluous variables

I used to agree with this but I have moved away from compound literals entirely except for global statics/const definitions.

Having a variable and explicit:

  foo.x = whatever;
  foo.y = something_else;
Leads to better debug experience imo, can set breakpoints and single step each assignment and have a name to put a watch on.

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

#34

Post by vbezhenar »

marhee wrote: post #18

> developers have a hope of being able to determine which #includes can be removed and which can't Can’t a modern compiler do that already? Didn’t google but seems an obvious compiler feature at the very least behind a warning flag.

Clang-tidy (linter) can do that. IMO it's a good idea to integrate this tool to any C project. I'm using gcc for embedded projects and clang-tidy works just fine as a separate tool.

https://clang.llvm.org/extra/clang-tidy/checks/misc/include-...

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

#35

Post by lifthrasiir »

vbezhenar wrote: post #29
lifthrasiir wrote: post #14

Earlier quoted context omitted.

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!

My opinion is that line width depends on identifier naming style. For example Java often prefers long explicitly verbose names for class, fields, methods, variables. Another approach is to use short names as much as possible. `mkdir` instead of `create_directory`, `i` instead of `person_index` and so on. I think that max line length greatly depends on the chosen identifier naming style. So it makes sense to use 100 o…

And you risk a collision for global identifiers, which cannot be reorganized in C. If some library had the same thought and defined `mkdir` first, your code can't define `mkdir` even as a private symbol. So you have to prefix everything and that contributes to the identifier length. In comparison, Go has a much better (but personally not yet satisfactory) module system and can have a lower limit.

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

#36

Post by flohofwoe »

jackiesshirt wrote: post #33

>Prefer compound literals to superfluous variables I used to agree with this but I have moved away from compound literals entirely except for global statics/const definitions. Having a variable and explicit: foo.x = whatever; foo.y = something_else; Leads to better debug experience imo, can set breakpoints and single step each assignment and have a name to put a watch on.

Hmm, what's the point of single-stepping over a simple data assignment though? And when the initialization involves function calls, the debugger will step into those anyway.

One advantage of initialization via compound literals is that you can make the target immutable, and you won't accidentially get any uninitialized junk in unlisted struct members, e.g.:

const vec3 vec = { .x = 1.0, .y = 2.0 };

...vec.z will be default-initialized to zero, and vec doesn't need to be mutable.

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

#37

Post by jjgreen »

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.

Exactly this. Open a novel and count the characters on a line; around 80 is readable as 500 years of typographic practice has determined. Two or three levels of indentation and that bumps the page width up a bit, still less than 100.

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

#38

Post by flohofwoe »

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.

The rule is a bit silly sure, but OTH I typically have multiple editors tabs open side by side (I don't restrict myself to a hard 80 char line width though, but I have vertical rulers set at 80 and 120 characters in the editor as visual guidance).

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

#39

Post by ykonstant »

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 is a fair point, but a book is 60 - 80 characters of dense prose line after line in thick paragraphs; it is not clear how this translates to lines of code.

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

#40

Post by robxorb »

vbezhenar wrote: post #32
robxorb wrote: post #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 benchmarki…

I don't know if this embedded development still alive. I'm writing firmware for nRF BLE chip which is supposed to run from battery and their SDK uses operating system. Absolutely monstrous chips with enormous RAM and Flash. Makes zero sense to optimize for anything, as long as device sleeps well.

Probably right in the broader sense, but there are still niches. Eg, for one: space deployments, where sufficiently hardened parts may lag decades behind SOTA and the environ can require a careful balance of energy/heat against run-time.
Post reply on HN