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

221–230 of 466 posts

Re: My personal C coding style as of late 2023

#221

Post by gallier2 »

WalterBright wrote: post #164
guidoism wrote: post #97

Earlier quoted context omitted.

I agree. A lot of languages have settled on those same names or something similar. We don’t live in a world with a single word size anymore so carrying bit length in the name is critical, and so is keeping identifier names short. His trade off is exactly the one I would make.

> carrying bit length in the name is critical I beg to disagree. In D: byte - 8 bits short - 16 bits int - 32 bits long - 64 bits absolutely nobody is confused about this.

and

    ubyte - 8 bits
    ushort - 16 bits
    uint - 32 bits
    ulong - 64 bits
    ucent - 128 bits
    
    float - 32 bits
    double - 64 bits
    real - maximum precision hardware allows (80 bits on x87).

Re: My personal C coding style as of late 2023

#222

Post by outsomnia »

jstimpfle wrote: post #202
outsomnia wrote: post #140

Earlier quoted context omitted.

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…

You're right, I also mark array definitions as const to control the section they go in, I was thinking about things like const int a = 5; ... anything I want a simple const var for is done with #define for me.

const is indeed viral when eg, used in apis, but it's a strong indication at a glance for api users what they can expect to happen to the memory the pointer points to, whether it's just for input or is modified... and the virality is only a pain (it can be a pain) if you didn't use it from the start so all the things it might call are already kitted out with it.

Re: My personal C coding style as of late 2023

#223

Post by taylorius »

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

Java has many great qualities, but concision is not one of them.

Re: My personal C coding style as of late 2023

#224

Post by jraph »

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…

Interesting take, but good luck with this fight against all caps (snake case) constants, at this point it's almost a consensus, a shared culture element, a deeply ingrained habit that the vast majority of developers have and recognize.

Changing this would be a huge undertake I'd be afraid of engaging, if I cared that much.

Re: My personal C coding style as of late 2023

#225

Post by jstimpfle »

outsomnia wrote: post #222
jstimpfle wrote: post #202

Earlier quoted context omitted.

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…

You're right, I also mark array definitions as const to control the section they go in, I was thinking about things like const int a = 5; ... anything I want a simple const var for is done with #define for me. const is indeed viral when eg, used in apis, but it's a strong indication at a glance for api users what they can expect to happen to the memory the pointer points to, whether it's just for input or is modified…

const makes sense and rarely causes problems when used in function parameter lists.

However, when used for members in datastructures, it's more often than not problematic.

Re: My personal C coding style as of late 2023

#226

Post by bArray »

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

Generally I agree with others, it might be better to leave some of these things as default for readability, even if it is not concise.

[0] https://docs.opencv.org/4.x/df/dc9/classcv_1_1float16__t.htm...

[1] https://docs.nvidia.com/cuda/cuda-math-api/group__CUDA__MATH...

[2] https://en.cppreference.com/w/cpp/types/floating-point

Re: My personal C coding style as of late 2023

#227

Post by avgcorrection »

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…

Thanks for bringing this up. There is no reason for modern languages that have proper constants (not preprocessor macros which happen to sometimes be used for them) to use this tedious style.

Constants are so innocent and useful. Why indirectly discourage their use by making their usage an eye-bleed?

Re: My personal C coding style as of late 2023

#229

Post by eviks »

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…

Indeed, these are less readable and harder to type for no benefit

Re: My personal C coding style as of late 2023

#230

Post by nxobject »

trealira wrote: post #93
eddd-ddde wrote: post #23

Earlier quoted context omitted.

i never thought about that, saving bytes even in symbols

Yeah, old C compilers would only look at the first 6 characters of a name, and the rest were insignificant. That's how you get nanrs like "strcpy" and "malloc" instead of something like "string_copy" or "mem_allocate" (I still think "memory_allocate" would be long enough to be annoying to type).

IIRC this mirrored the behavior of MACRO-11, DEC's first-class PDP-11 assembler.
Post reply on HN