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

My personal C coding style as of late 2023

nullprogram.com

Post reply on HN
Print view View original

201–210 of 466 posts

Re: My personal C coding style as of late 2023

#201

Post by lelanthran »

gdprrrr wrote: post #196
lelanthran wrote: post #173

Earlier quoted context omitted.

> Wouldn’t existing programs just continue working? Only ones which don't have variables named `i8` or `b32` (which is common, but not for booleans). I've seen many projects which used the pattern [a-z][1-9]+ as variables. Those programs with a variable called `i8` won't compile if the standard made a type called `i8`. In particular, the standard reserves entire patterns to itself, so it cannot reserve the pattern of…

Typedefs and variable namens don't live in them same namespace, do they?

> Typedefs and variable namens don't live in them same namespace, do they?

Depends. See this snippet: https://www.godbolt.org/z/5T5jz47q4

Cannot declare a variable called `u8` when there is a typedef of `u8`.

And even when you can declare a variable called (for example) `int`, that effectively "breaks" the program by not being even a tiny bit readable anymore.

Re: My personal C coding style as of late 2023

#202

Post by jstimpfle »

outsomnia wrote: post #140
laserbeam wrote: post #119

Earlier quoted context omitted.

I'm getting an "I don't use const, and here's my view on it" vibe from the author much more than "you shouldn't use const". I'm really not getting any demand that you change your coding style, just someone reflecting on their work and explaining it to others. And... Whether I agree with their choices or not, I find that very cool and informative.

It wasn't clear to me if he's talking about const as a variable declaration qualifier - I never used it - or const in pointer types, which is very useful.

For me it's the other way around -- I use const for global variables because it makes a real difference, the data will be put in a .ro section.

Pointer-to-const on the other hand (as in "const Foo *x") is a bit of a fluff and it spreads like cancer. I agree with the author that const is a waste of time. And it breaks in situations like showcased by strstr().

I use pointer-to-const in function parameter lists though (most of the time it does not actually break like in strstr()): as documentation, and to be compatible with code that zealously attaches const everywhere where there (currently) is no need to mutate.

But overall my use of const is very very little and I generally do not waste my time (anymore) with it. I almost never have to use "const casts" so I suppose I can manage to keep it in check. In C++ it is a bit worse, when implementing interfaces, like const_iterator etc. That requires annotating constness much more religiously, and that can lead to quite a bit of cruft and repetition.

Re: My personal C coding style as of late 2023

#204

Post by layer8 »

_old_dude_ wrote: post #180
flakes wrote: post #156

Earlier quoted context omitted.

Final only protects the variable from being assigned a new reference (similar to a const pointer). It doesn’t protect any of the underlying data held by the object from being changed, unless the entire hierarchy has every field declared final as well. I still use final heavily in all of my Java code, but it doesnt convey the full intent I would like it to.

I remember James Gosling saying, a long time ago, that the whole class should be either mutable or not so you do not need to tag some methods with const. The consequence is that you may define two classes, one non-mutable and one mutable like String/StringBuilder.

It means you have to triplicate each mutable class, because besides the immutable variant you also need the common interface (e.g. CharSequence), in order to pass mutable instances to read-only functions.

Re: My personal C coding style as of late 2023

#206

Post by cryo »

pif wrote: post #182

> No const. I stopped reading there. I wish this guy a happy coding (and non-coding) life, but I hope we never work together.

I'd love to have him in a team. He truly cares exactly how code works and analyzes/fuzzes the hell out of everything.

I don't agree with all stylistic choices in his code, but the level of experience and skills are far above most C developers.

Re: My personal C coding style as of late 2023

#207

Post by fredrb »

fefe23 wrote: post #191

Why would anyone care what the favorite whatever style of some dude on the Internet is? I like petunias! Now what? How does that help anyone?

Sharing preferences and opinions on code ergonomics certainly has value for me, and I bet it has to other people too. This is, after all, a developer's forum.

I'm certain your opinion on petunias and your possible distaste for orchids will be welcomed in a flower-news type orange site. :-)

Re: My personal C coding style as of late 2023

#208

Post by jstimpfle »

rewgs wrote: post #200
lsh123 wrote: post #113

I wrote and still maintain an open source C project for 20+ years. Once a year I get a new guy coming in and telling me I am doing it wrong: you should typedef all data types, you should stop using const, and so on. It stopped being funny after the first couple times.

I'm not a C developer, so I have to ask: why in the world would you not use const?

It's more work. Not only to put all the annotations correctly, but only because it causes some real headaches. It's easy (implicit) to transition from non-const to const 1 pointer level deep. But the other way around -- it's really awkward to "remove" a const.

The strstr() signature is probably the shortest example / explanation why. To implement strstr(), you have to hack the const away to create the return value. Alternatively, create a mutable_strstr() variant that does the exact same thing. This is the kind of boilerplate that we don't want in C (and that C is bad at generating automatically).

Think about it this way: Real const data doesn't exist. It always gets created (written) somewhere, and usually removed later. One way where this works cleanly is where the data is created at compile time, so the data can be "truly" const, and be put in .ro section, and automatically destroyed when the process terminates. But often, we have situations where some part of the code needs to mutate the data that is only consumed as read only by other parts of the code. One man's const data is another man's mutable data.

In C, the support for making this transition work fluently is just very limited (but I think it's not great in most other languages, either).

Re: My personal C coding style as of late 2023

#210

Post by hun3 »

billforsternz wrote: post #115
comex wrote: post #57

Earlier quoted context omitted.

(self-reply) One more thing. > I could use _Bool, but I’d rather stick to a natural word size and stay away from its weird semantics. This is even more subjective, but personally I like _Bool's semantics. They mean that if an expression works in an `if` statement: if (flags & FLAG_ALLOCATED) then you can extract that same expression into a boolean variable: _Bool need_free = flags & FLAG_ALLOCATED; The issue is that…

This is all very good and very, ahem, true. But (and it's a big butt); if (need_free == true) Is such a horrible code smell to me. You have a perfectly good boolean. Why compare it to a second boolean to get a third boolean? if (need_free) or if (!need_free) for the opposite case is so much better. I will admit that in my world this leaves if (need_free == some_other_bool) as something I don't have a particularly com…

Better example:

  #define FLAG_63 (1ULL
In this case,

  if (flags & FLAG_63) pass();
will pass, but

  typedef int BOOL;
  BOOL set = flags & FLAG_63;
  if (set) pass();
won't pass, due to truncation.

Question: Would you argue that a datatype that holds the smallest (1-bit) datum should be as wide as the largest integer type just to handle such cases?

If so, that would be highly inefficient for storage purposes. Note that Win32 has 32-bit BOOL type, but internally NT uses 8-bit BOOLEAN type to store bools in structures.

Post reply on HN