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

Principles for C programming

drewdevault.com

Post reply on HN
Print view View original

131–140 of 149 posts

Re: Principles for C programming

#131

Post by wruza »

hackits wrote: post #116
fredmorcos wrote: post #40

Earlier quoted context omitted.

> even within enterprise apps. The epitomes of today's software. I really like how you used "even".

Worked on a number of different projects clearly from a maintence perspective. From C,C++ mostly around VBS2/VBS3 (Operation Flashpoint) and VSS Simulation systems. Moved on from C/C++ simulation market when the money wasn't really in it unless you're the sales people or upper management. Kind of drives it home when you bike into work and all management are driving BMW ect.. This was a startup that I took a major pay…

One of the main reasons why I visit HN is real life experience & philosophy stories like that. Thanks!

Re: Principles for C programming

#132

Post by jankedeen »

1. The only reason to use C these days _is_ performance and portability. Write the code to your level of expertise or use a different language to cater to the 'du jour' audience.

2. This was advice straight of Der lindens Deep C secrets back in the mid 90s. It wasn't always true then and it isn't always true now. I often use macros and don't find them a problem to understand in others code.

3. Give me a break. Except when you don't need to allocate and manage memory which is almost every time you write a tool that does one thing well. This is not a good general principle.

4. This is the way it works for me. Do it. Nope.

5. Ok, some of this is common sense writing portable code. 'GNU is a blight on this earth': "..now we see the violence inherent in the system.."

6. Yes, finally a good point but not about C per-se. 7. Ok, but this is not about C per-se. 8. Hrrmmm. A culture of blame is what produces restrictive rules like these.

This article is fodder for the Rust and other anti-c devotees here to glom onto and point out all the problems with the author and his language as the ultimate straw man. To me it sounds like this person wasn't writing C in the 90s.

Re: Principles for C programming

#133

Post by huhtenberg »

torrent-of-ions wrote: post #82
ddevault wrote: post #39

Earlier quoted context omitted.

>Not typedef'ing your structs forces you to use extra 7 characters per type mention for no clear benefit. To put it differently - if NOT having "struct" in front of a type name has any effect on readability/maintainability of your code, then there are deeper problems with your coding style that won't be solved by dragging "struct" around. The benefit is to readability. You should treat structs differently from scalar…

Surely a simple naming convention such as a capital letter for compound types is sufficient?

Or something as basic as

    foo_s
    bar_u
    baz_e
for structs, unions and enums respectively. Perhaps even splurge on xyz_f for function pointers... though that's getting recklessly close to the Hungarian notation :)

Re: Principles for C programming

#135

Post by fish2000 »

Do not use magic. — Strongly agree.

Do not use macros. — Absolutely I agree: I involuntarily grimace whenever I look at and/or things like Boost MPL, or the wartier corners of the Python C-API’s underbelly, etc. I only use macros as straight-up batched ⌘-C-⌘-V:

    #define DECLARE_IT(type, value) extern const type{ value }
    DECLARE_IT(int, 0);
    DECLARE_IT(int, 1);
    DECLARE_IT(float, 0.0f); // etc
    #undef DECLARE_IT
Do not use typedefs to hide pointers […] — I cannot stand it when people do this. That asterisk is as syntactically valuable to you, the programmer, as it is essential to your program’s function. If the standard library can slap asterisks on file and directory handles than so can you (and by “you” I specifically include whoever wrote the `gzip` API among other things).

[…] or to avoid writing “struct” — Huh, actually I feel the opposite, I think all those “struct” identifiers are clutterific, much like excessive “typename” id’s in C++ template declarations. But so aside from the points where I totally disagree with the author, I absolutely feel the same way 100%.

Re: Principles for C programming

#136

Post by mfukar »

ckastner wrote: post #109
mfukar wrote: post #94

Earlier quoted context omitted.

And since we can follow that thought process, we are smart enough to infer the meaning of the advice given ("do not assume") in the proper context, can we not? It's obvious to me we both can, so why the hell are you wasting our time with useless pedantry?

Why are you inferring meaning when the article's author used two paragraphs and numerous examples to illustrate his point unambiguously? The article is clearly heavy on the absolutes (eg: "Under no circumstances should you ever use"), and the grandparent comment critized this, and provided a good counterexample. But you, ironically, chose to assume what the author meant by "do not assume".

OK, now I know you're trolling.

Re: Principles for C programming

#138

Post by ddevault »

duck2 wrote: post #112
Sir_Cmpwn wrote: post #45

Earlier quoted context omitted.

Yes, I think typedefing scalars is fine. Typedefs are useful for abstracting the underlying storage mechanism for a scalar (so you can i.e. change it on different archictures or in a future release without breakage), not for saving yourself 6 characters of typing.

You can just use stdint types. Or is it really better to typedef a CUTE_INT?

That's not what I'm talking about. CUTE_INT is stupid, but maybe mylib_error makes sense. It depends on context.

Re: Principles for C programming

#139

Post by EpicEng »

ddevault wrote: post #39
huhtenberg wrote: post #31

Earlier quoted context omitted.

> Do not use macros. Sir, yes, sir. I will throw away "offsetof" and "container_of" right now, just give me a moment. > Do not use a typedef to hide a pointer or avoid writing “struct” Somewhat agree with the former, but completely disagree with the latter. If there's a single thing that is not right with C is its excessive verbosity in places where none is needed. Not typedef'ing your structs forces you to use extra…

>Not typedef'ing your structs forces you to use extra 7 characters per type mention for no clear benefit. To put it differently - if NOT having "struct" in front of a type name has any effect on readability/maintainability of your code, then there are deeper problems with your coding style that won't be solved by dragging "struct" around. The benefit is to readability. You should treat structs differently from scalar…

I have been writing C for more than a decade and have never been confused about whether or not a type was a strict or a scalar. This is a nonsense hypothetical.

Re: Principles for C programming

#140

Post by camgunz »

Sir_Cmpwn wrote: post #72
camgunz wrote: post #63

I'll wade in a little. > Don't use macros. > Don't use the inline keyword > Never put code into a header I disagree with these. It's often critical to avoid a function call in hot paths, and if you don't use macros or inline you have to resort to copy/paste, which is error-prone and hampers maintainability. It's also the case that C is a rather inflexible language. Macros can be extraordinarily helpful in reducing bo…

>I disagree with these. It's often critical to avoid a function call in hot paths, and if you don't use macros or inline you have to resort to copy/paste, which is error-prone and hampers maintainability. This advice is to be taken with a grain of salt, as with all programming advice. If you have a hot path, you should do whatever is necessary to meet the requirements, including macros or inline functions. The caviat…

I'm not a mocking expert, but of all the solutions I've seen -Wl,--wrap=[blah] feels like the most straightforward, yeah. I also like how it's in your build system and you don't write a bunch of twisted code or auto-gen'd headers and redirects. It's appealing enough to make me wonder if there's an obvious reason people don't use it.

I'll put aerc on my list of projects to watch. I'm swamped with overly-ambitious hobby projects but sometimes I need a breath of fresh air :)

Post reply on HN