My personal C coding style as of late 2023 • Hacker News Board

Re: My personal C coding style as of late 2023

#241

Post by moodguy » Mon, Oct 09, 2023, 10:25 AM UTC

For my hobby projects i do the following.

I adopted the style of writing all macros in lower case with the prefix "macro_", so i can grep through all macros. So macro_ becomes like a keyword. Same with enum.

I use almost the same naming scheme for i32,f32, etc., but i typedef for example size_t const to usz, and size_t to usz_ (or use macro mut(x) x ## _) . So all shorter type names are const by default. I use a single header of 35 sloc to do that.

I see that this way of coding can be confusing for other people, so i avoid it when writing code that other people have to work with. But for personal code its really enjoyable for me.

Re: My personal C coding style as of late 2023

#242

Post by loondri » Mon, Oct 09, 2023, 10:25 AM UTC

I get that everyone has their own coding style, but ditching established conventions in C for personal aesthetic seems a bit much. Like, using u8 or i32 instead of the standard uint8_t or int32_t might save a few keystrokes, but it could confuse anyone else looking at the code. And the custom string type over null-terminated strings? C's built around those, and deviating from that just feels like making life harder for anyone else who might need to work with your code.

And manually writing out Win32 API prototypes instead of including windows.h might shave off some compile time, but it's like ignoring a well-maintained highway to trek through the woods. Just seems like a lot of these changes are about personal preference rather than sticking to what makes C code easy for everyone to work with.

Re: My personal C coding style as of late 2023

#243

Post by jstimpfle » Mon, Oct 09, 2023, 10:27 AM UTC

mmoll wrote: post #234

jstimpfle wrote: post #208

Earlier quoted context omitted.

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. A…

> Real const data doesn't exist Ever seen a ROM? And the C library‘s hacks around not being able to overload functions (which is the only reason for strstr et al‘s weird signature) wouldn‘t stop me from using const. It can be really useful both for documentation and for correctness. Think memcpy, not strstr.

> Ever seen a ROM?

How does the data get onto the ROM?

But read 2 sentences further, where I had addressed this already.

> Think memcpy, not strstr.

See my other comments, I do think that making const function parameters is generally good for documentation and compatibility. strstr() is only a showcase for the limitations. Typically, const works for function parameters but not data structures.

Re: My personal C coding style as of late 2023

#244

Post by CodeArtisan » Mon, Oct 09, 2023, 10:27 AM UTC

bArray wrote: post #226

> typedef float f32; > typedef double f64; Assuming float is 32 bits and double is 64 bits sounds like a foot-gun. OpenCV defines a float16_t [0], CUDA implements half-precision floats [1], micro-controllers implement whatever they want. C++23 introduces fixed width floating-point types [2], but not aware of any way to enforce this in C. What I would suggest it to have a macro to check data is not lost at compile tim…

gcc has _Float types

    typedef _Float32 f32;
    typedef _Float64 f64;

https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html

Re: My personal C coding style as of late 2023

#245

Post by al_be_back » Mon, Oct 09, 2023, 10:27 AM UTC

>> typedef all structures. I used to shy away from it

it seems this may be more an issue with being shy, than a coding issue :P

in my view, language is a Style, so coding in C is c-style coding.

when i started coding in python (small projects initially), my code cried-out Java Java (typing, packaging, naming, oop), and took nearly as long to write - I laughed my head of when I realized, just because I could doesn't mean I should.

Re: My personal C coding style as of late 2023

#246

Post by fps_doug » Mon, Oct 09, 2023, 10:28 AM UTC

gallier2 wrote: post #219

another2another wrote: post #189

Earlier quoted context omitted.

In that case D should probably start to have an internal conversation about what they're going to call 128 bits then, 'cause its going to become a thing sooner or later. stdint already has that covered though: (u)int128_t

it has defined the type for very long: it's cent and ucent. It hasn't implemented it completely though, but named and defined it is already forever.

So will the 256bit one be dollar or euro?

Re: My personal C coding style as of late 2023

#247

Post by tpush » Mon, Oct 09, 2023, 10:31 AM UTC

Izkata wrote: post #117

f33d5173 wrote: post #70

Earlier quoted context omitted.

The arg is expanded twice but evaluated zero times, since sizeof gives the size of its argument type without executing anything.

countof(foo()) looks like foo() is only called once, but would actually be called twice. That's what GP is talking about, it's evaluated twice after the expansion when the code is actually running, not during the expansion.

Again no, foo isn't called at all since countof() only uses its argument in a sizeof expression.

Re: My personal C coding style as of late 2023

#248

Post by jstimpfle » Mon, Oct 09, 2023, 10:32 AM UTC

gwd wrote: post #235

jstimpfle wrote: post #208

Earlier quoted context omitted.

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. A…

> 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. It seems to me the "hacking" is exactly the side-effect that is wanted. It's like the requirement in Rust to do certain kinds of things in an `unsafe { }` block (or using the `unsafe` package in Go): not that you want the compiler to prevent you from doing thi…

> It seems to me the "hacking" is exactly the side-effect that is wanted.

It is not. It's broken at the surface level. If you passed a pointer that is already const on your side, you get back a non-const pointer back that allows you to write to your const memory.

Re: My personal C coding style as of late 2023

#249

Post by sdk77 » Mon, Oct 09, 2023, 10:34 AM UTC

neilv wrote: post #216

> While I still prefer ALL_CAPS for constants, I’ve adopted lowercase for function-like macros because it’s nicer to read. "ALL_CAPS" in C was not for constants, but for preprocessor macros. It's shouting in all-caps, because it means "Look out! There's a cpp macro expansion here!" Related, please stop using "ALL_CAPS" for constants in other languages. Not only does shouting constants as the most prominent syntax in…

The case of what is a constant, and whether or not it even really is, is not always clear in C. As an embedded developer (almost always on bare metal), variables declared with the const modifier are usually (but not always, it depends on the linker script) placed in read only memory. For those kind of variables (read only ones, they're not really constants as in C++ constexpr) I don't use all caps. But for preprocessor macros, always. Even "#define MY_CONSTANT 10" is a macro, and not a constant or a variable. And it should be treated with caution, because it is dangerous (inexperienced programmers might change it to #define MY_CONST 2 * OTHER_CONSTANT, which opens up a can of worms).

Re: My personal C coding style as of late 2023

#250

Post by orthoxerox » Mon, Oct 09, 2023, 10:42 AM UTC

mianos wrote: post #127

antiquark wrote: post #6

> #define sizeof(x) (size)sizeof(x) Technically, it's illegal to #define over a language keyword.

Considering '#defines' are done in a textual pre-precessing by the C pre-processor, they don't know much at all about the C language. You can define out int, long, struct or anything. I have seen many people redefine 'for' and 'while'. These people often argue that it is an improvement. cpp #define sizeof(x) (size)sizeof(x) sizeof(UU) ^D # 1 " " # 1 " " # 1 " " # 31 " " # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 " "…

> I have seen many people redefine 'for' and 'while'.

    #define while if