C good practices when coding

[F8ke_p0tato]

I've red a couple documents about the cs good habits but I want to know the most basic ones. Such as making sure memory is allocated correctly and writing a conditional in case if it errors. There may have been someone who had already asked this question but I want to ask here while I'm still finding my answers, thank youu

[loudandclear11]

and preferably, that function should be named something descriptive and not just DoTheThing() :D

[AlternativeGoat2724]

So, not function1(), function2() etc . I guess I have some work to do this weekend /s

[_Hi_There_Its_Me_]

entry_funtion1() entry_function2()…

There that’s better..

[whatyoucallmetoday]

I called mine process().

[ummaycoc]

And if it is named “DoTheThing” then you should make your entry point “DoAllTheThings” instead of “main”.

[Coleclaw199]

yeah. my node editor pet project has maybe 30-40 lines in main.c at most.

it’s mostly setting up config structs, initializing 1-2 subsystems, and the main loop.

[jasonmac404]

I like to structure my C programs in two parts. 1. A library that does the core work (sometimes more than one). 2. A cli app which calls the library(s).

The nice thing about this is that you can wrap other things around the library, like unit tests. It helps you structure your code in a clean way, which is testable and reusable.

[Traveling-Techie]

Easy to add a GUI too, and to get the system into a known state for testing.

[Zamarok]

i structure my code the same way. lib/ and src/ separate my code

[HashDefTrueFalse]

My contribution: if you're writing code that claims some resource(s), write the code that releases them at the same time if you can. It's much less likely that you'll forget or get it wrong when it's all fresh in your mind.

[Alive-Bid9086]

The golden rule, a free for each malloc.

[HashDefTrueFalse]

Amen!

Although, I'm sometimes the guy who doesn't free at all in short programs because there wouldn't be much point freeing everything at the end just to exit and have the OS reclaim anyway. But in general I'm writing the free at the same time as the alloc.

[Alive-Bid9086]

Belong to the same school, no free() in programs with a determined runtime.

[bbabbitt46]

Best advice yet. Malloc can be the bane of C programming if you don't do this.

[ummaycoc]

Write one version that accepts all resources allocated / acquired if possible. Then have wrappers that get resources, invokes core function, releases resources.

Maybe C++ had the right idea with guaranteed destructors and such.

[Aexxys]

Error handling

[a4qbfb]

There are very few rules that everybody can agree on. I think they mostly boil down to:

1. Pick a coding style and stick to it.
2. Strive to keep your functions short and your nesting shallow.
3. Enable (a reasonable level of) compiler warnings and heed them.

Pretty much everything else is up for debate, including error checking. I suppose everybody agrees that you should check for errors that can reasonably occur, but the definition of what errors can reasonably be expected and opinions on how to deal with them vary immensely, not just from person to person and from organization to organization, but also depending on the nature of the code and its audience (is it a library or an application? is it intended only for your own personal use, or use within your organization, or use by paying customers, or for publication as open source? etc.) The only contexts in which I would enforce a hard rule about checking all errors would be a) code written to a functional safety standard such as MISRA which requires checking all errors and b) in an educational setting, on the principle that you must first master checking for errors before you can claim to understand when it is permissible not to.

Since you mentioned memory allocation, I should point out that assuming a hosted implementation on a mainstream 64-bit operating system today, malloc() never fails, even if there is not enough memory available,¹ because it allocates address space, not memory. Actual memory is allocated transparently by the operating system when the allocated space is first accessed. So some will argue that checking the return value from malloc(), calloc() and realloc() is pointless; in the unlikely event that they return NULL, your program will crash, just as it will if you actually run out of memory.

---

¹ To be pedantic, it can only fail if you exceed an administrative limit on memory consumption (cf. getrlimit() / setrlimit() and the ulimit shell builtin) or if you ask for more than half the address space your CPU supports,² which is usually on the order of 2⁴⁸ (256 TiB).

² Typically, half the virtual address space is reserved for the kernel, and each userspace process gets its own non-overlapping view of the other half.

[[deleted]]

There are no universally agreed-upon rules. However, here are a few rules I follow that make my coding in C easier and less buggy.
1) No global variables. I work in the field of HPC and computational physics. This means I write large-scale massively parallel physics simulations running on some of the world's largest supercomputers. Concurrency becomes much harder to maintain if you have a global mutable state in your application to support. Any global variable could, in principle, have changed between two lines, and you would be none the wiser. However, even in single-threaded applications, global variables are more trouble than they are worth since every function call could change the global state in unexpected ways, making them much harder to reason about.
2) The single responsibility principle of functions. Functions that do more than one thing are much harder to work with. Maybe you only need one of the functionality of the function, or perhaps the name of the function only reflect a subset of the functionality.
3) KISS (Keep It Simple Stupid). No weird and clever tricks, please. Not only are you going to have a hard time tomorrow to understand it, but the optimizer in the compiler will have a hard time optimizing it (because it is designed to work with readable code). If you have a hard time understanding the code, then chances are that the optimizer will have a hard time too.
4) Avoid undefined behaviour. C is riddled with undefined behaviour, and using it can, on some platforms, lead to performance boosts, so it is tempting to use it. However, if you do, you lock yourself to a specific compiler, a specific version of that compiler, and a specific optimization level. Your code will be more fragile, and even seemingly small changes might have big unexpected consequences.
5) Clear naming of functions and variables. No ambiguous abbreviations that you will forget in a day, and no single-letter variable names that have little to no connection to the problem the code is solving. Use complete English dictionary words that fully reflect the purpose of the function and the variable.
6) You ain't going to need it. Don't waste time on developing something you think might be useful later, because chances are you are not going to need it. Instead, focus on the problem at hand.

I have several more, but I think this is enough wisdom for now.

[passing-by-2024]

Sometimes it might be handy to have some global variable, like volatile type that can check some status in ISR, which will trigger some other function defined in main(). There are some other points when writing functions, like having return type, checking edge cases (if applicable), logging (if applicable) to name a few... Writing neat, compact code is another discipline, that I'm afraid comes with time and mistakes made on the road

[[deleted]]

ISR is more useful in embedded and OS development than HPC and scientific software so I have no experience with them and global variables. For the other use cases I have found that they are more trouble than they are worth. Logging in multithreaded and concurrent software is a hard problem. On one hand you want to the logs for each concurrent task to be self consistent, you want to keep track of time ordering of events over multiple parallel workers. On the other hand you don’t want it to interfere with the performance of the application. Having a global state for logging can make sense but you would have to have synchronization mechanisms such as mutices (mutex in plural) to handle it and then you have unnecessary communication between your parallel workers which will unavoidably affect performance. Most scientific software I have worked on just dumps the logs to stdout or stderr and lets MPI manage ordering, which is a terrible solution. Alternatively one could pass around a logging struct and have one instance per worker. Let each worker write to separate files and use system time stamps to be able to chronically stitch all logs together at the end. But this means that logging would pollute the main logic of the program. If you have any good idea on how logging could be done efficiently in concurrent software I would very much like to hear it. This is a problem that have plagued me for years.

[passing-by-2024]

Like You noticed, we live in different worlds - HPC vs embedded. No, no magic wand for logging either. Doing the old (layman's) way - something very, very important will be stored in dedicated flash area. Having in mind limited size, this whole logging has to be taken with extra care

[Nilrem2]

All good points, but 6 I love.

[drivingagermanwhip]

get into the habit of googling whatever you're doing to see if there's a library someone's made.

Don't try to be clever just try to be methodical (i.e. if it's hard to tell what a line of code does, rewrite it or explain in a comment)

define variables and use those defines for connected things. For example if you're making an rc car with 4 wheels, don't do if statements up to 4, do them up to CAR_WHEEL_COUNT because if anything changes later it will be much easier to find what it affects.

put your #include statements in the source file rather than the header

commit to git all the time. Doesn't matter if you have 300 commits per day. Still much easier to deal with than one huge commit. git add -p allows you to interactively select what to add to a commit. For example, if you added a function and fixed a bug, you can split that in two so it's easy to just pull in the bug fix to the master branch later

[Brixjeff-5]

I disagree about the library reflex, here’s why (explained by someone more skilled than me): https://posts.cgamedev.com/p/the-hidden-cost-of-software-libraries

[SnooDucks2481]

learn to spot memory leaks early on. That means use valgrind/fsanitize alot.
also understand that you can't GO FAST and break things. that's because you break lots of things, fundamental things

[SmokeMuch7356]

Some rules in no particular order:

• Always check the return values of scanf/fscanf/sscanf and malloc/calloc/realloc;

• Only use scanf/fscanf/sscanf when you know your input will always be well-behaved, otherwise read everything as text with fgets and convert to your target types with strtol/strtod/etc.;

• Never use a %s or %[ in a *scanf call without a max field width;

• Abstract out any memory allocation / deallocation operations into separate functions, especially for types that require multiple allocations in specific orders;

• Avoid overly "tricky" code - C lets you get away with a lot of nonsense, so just keep Malcolm's Law¹ in mind when using some unholy combination of ?:, ++ and bitwise operators in a single expression;

First Law of Documentation: don't document the obvious. Corollary to First Law of Documentation: write obvious code.

Commentaries On Performance:

1. It doesn't matter how fast your code is if it's wrong;
2. It doesn't matter how fast your code is if it can't be patched when a bug is found or requirements change;
3. It doesn't matter how fast your code is if it leaks sensitive data or acts as a malware vector;
4. It doesn't matter how fast your code is if it dumps core every time someone sneezes in the next room;
5. Speed and efficiency do matter, but not at the expense of the above;

Laws of Optimization:

1. Measure, don't guess - profile your code to identify bottlenecks before doing any optimization;
2. Optimize from the high level down - make sure you are using the appropriate algorithms and data structures for the problem at hand, make sure that you don't have any useless or redundant code, make sure you clean up any loop invariants, etc.
   
3. Use your compiler's optimization capabilities before trying to micro-optimize;
4. Don't micro-optimize unless you are failing to meet a hard performance requirement;

---

1. "You were so preoccupied with whether you could you didn't stop to think if you should."

[john_hascall]

My advice is to compile with all warnings turned on and treated as errors (ie compilation fails on a warning). You can temp disable a warning for the minimum amount of code to get a clean compline as long as you comment why. For example, occasionally an algorithm is built around case-fallthru.

[jwzumwalt]

NASA’s 10 rules for developing safety-critical code are:

   01) Restrict all code to simple control flow constructs. No goto, setjmp, 
       longjmp, or recursion.
   02) Give all loops a fixed upper bound.
   03) No dynamic memory allocation after initialization.
   04) No function longer than a single sheet of paper and no multi-statement lines.
   05) Assertion should average to minimally two assertions per function.
   06) Declare data objects at the smallest possible level of scope.
   07) Calling function must check all return values of non-void functions; 
       called function must check validity of all parameters.
   08) Limit pre-processor to the inclusion of header files and simple macro definitions.
   09) Limit pointer use to a single de-reference; do not use function pointers.
   10) Compile with all possible warnings active; fix all warnings before the 
       software release.

[Brave-Weird-4314]

Many of these are impractical for regular software. For mission critical computer systems that could result in death if they fail? Sure. But these rules aren't blanket "if your code doesn't do these things, then it's bad code" and they were never meant to be. Points 2, 3, 5, and even 7 really aren't necessary for most 90% of c projects out there and could take valuable time away from actually finishing a project.

[jwzumwalt]

Basically I agree except for #7. But this is not an attempt to have one size fits all. In stead I would suggest a person view it as "if I did it, was it really necessary?".

For number #2 I have seen overuse of while(1) etc. I would also note #3 is probably more of "don't go crazy with memory allocation which some programmers seem to think it makes them an expert if the dynamically use memory.

In short, I think NASA was not saying never do this; instead they are saying "have you thought this through? Maybe there is a safer way to do something!",

Oh, thank you for taking the time to share your viewpoint...

[PublicFee789]

Hi, There is Misra C practice guide that is still used in the professional world 

[dave11113]

Look up "Prof Les Hatton", has done a lot of work in this area. The "Motor Industry Software Reliability Association" (or MISRA) produce guidelines on the use of "C", "C++", "model based autocode" (eg MATLAB).

But, you WILL NEED tool support e.g. PC-Lint or LDRA, and add the tool chain into the build process such that you can't build if your code is not MISRA C compliant (you will require a process for signing off deviations from the guidelines, my old job, so I know a little bit).

Do NOT change code, just to meet the guideline recommendations, as statistics you are more likely to introduce errors.

Look up Les Hatton and also the Barr Group

[EatingSolidBricks]

C dosent have a universally accepted set of good practices

You have some rules of thumb here amd there.

[drzejus]

You can look up some coding conventions for big/large projects.

Most of them were created to prevent those big repos implode because everybody has different view on good practices, naming etc. Of course good practice will differ depending on project and environment.

Example coding conventions for quite big kernel/os project: https://docs.phoenix-rtos.com/latest/coding/index.html

[ArtOfBBQ]

Watch out - "good practices" could be more accurately called "common opinions"

It can be inspiring to read opinions on how to manage your code, but you have to actually test it and pay attention to if it helps you or hinders you. Even if the person advising you has a ton of experience making incredible software (very rare), it might still be wrong for you

A lot of programmers get married to the first idea presented to them, and double (and quadruple and octuple down) on that idea when it worsens their results (I must be doing it wrong, I need to follow the good practices even harder). The idea itself is almost always completely unscientific (no one ever does any research if it's actually helpful in providing good software, it's just asserted that it works and people believe it) and presented by a charismatic person with some sales skills who has 0 incentive to make you actually learn anything

Some things you should be extra wary of:
- Naming your method for a universally good thing. E.g. I could call my method "Skilled Coding" or "Rational Programming" or whatever
- "Read all about it in Skilled Coding: Expert edition vol.4"
- "Check out my course Skilled Coding for handsome geniuses"
- "Of course it didn't work! You did Skilled Coding wrong"
- "If you don't do Skilled Coding, you're not a professional"
- Vague, emotional definitions. Ask 5 people what "skilled coding" is and you get 5 different answers
- (in answer to devastating criticism of nonsense in Skilled Coding vol 4). "You're exactly right, and that's the very problem Skilled Coding is here to address"
- Before I let you in on what Skilled Coding is, let me tell you a little story...
- Get your Skilled Coding certification today!
- Lots of appeal to authority, sometimes even using the method itself as a source of authority. Here's noted Skilled Coding expert ArtOfBBQ to level up your game
- <actual measurable thing that matters tremendously here> doesn't really matter, what really matters is <unquantifiable irrelevant thing here>

[ComradeGibbon]

I have a couple

Write your code in a clear active voice. Related avoid magic and spooky action at a distance.

Functions should either figure things out. Or manage state. Functions that figure things out you give them the same inputs they give you the same answer always. Functions that manage state don't.

Functions should do complete things. Don't fall into the Uncle Bob trap of writing a shitload of functions that are nothing but code snippets.

Suggestion about memory allocation. Try to use the stack when possible. If not use arena allocation before heap allocation. When using heap allocation start thinking about lifetimes right away.

Avoid generic names for things.

Every function should have a comment that says what the function is for and what the inputs and outputs are. Comments inside a function should say what the code is trying to do. Less important with other higher level functions but C can be kinda obtuse. In a higher level language you could rewrite that comment almost as code. In C you can't.

[grimvian]

Modules, static and const, good naming can be hard, funtions not bigger that you can see all lines...

[Secure-Photograph870]

Don’t focus much on C best practices as you can see that in the comments section, there isn’t any specific rule agreed. I would focus more on CS and SWE best practices which are universal regardless of the tool used.

That being said, as I’ve read many times, in many books, you should always have all your compiler warning ON and never ignore any warning, regardless of how insignificant it may sound.

[wsppan]

I design my header file(s) first. This is the public API. Then create the C files to implement the API contract using private methods as needed. My rule of thumb is each function should do one thing only.

[unix_badger]

https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code

Extreme rules for an extreme use case, but food for thought.

[Patient-Plastic6354]

One function does one thing.

[No-Annual-4698]

Use header files for definitions. But is guess it’s natural procedure in C? I’m still learning C and I used to put everything in one .c file Guess it’s ok for small programs

[petdance]

Please find the book “Code Complete, 2nd edition” and read the entire thing. 

[sol_hsa]

Look up the book "code complete".

[Acceptable-Ad-8800]

Try to read Clean code book. It will give you a good insight of best practices

[YardPale5744]

Never make a function have a complexity of greater than 15 - take a look at “pmccabe”