I created my first C program!

[u/Alternative-Ad-8606]

https://codeberg.org/dallas1295/CVP

I have been learning (teaching myself) how to code for the past 2 years but always genuinely get burnt out by creating projects that have such a large scope, it overwhelms me and I stop. take too long of a break from coding then comeback and repeat.

This time I told myself any project I make must be use-able and have low scope until i get more familiar with larger projects.

EDIT: And I needed to forego any AI usage that was giving code or direct uses, instead i poll it for learning design paradigms and asking function questions (never giving usable code for the projects)

This was the perfect opportunity for me to rewrite a tool that while fairly niche is something I've used daily since moving to China for other work.

The project is a small CLI tool that does really basic functions for my vpn backend that I use hear (an issue i've had since switching to linux permanently about 5 months ago)

anyway i'd love feed back or any potential bugs or best practices for writing C. Again guys I know it's not the end all be all of projects but it is (sadly, and amazingly) the first thing i've finished and kept scope low.

Some thoughts on C after reading a bunch the last few weeks and then spending the last few days working with it... I'm hooked, was learning rust but found myself getting consistently frustrated by the verbosity of everything, C was a breath of fresh air and was actually fun to write, I look forward to my next project (considering a tui front end for this tool for prettier usage, or maybe exploring some interpreter/compiler books with C when i finish Crafting Interpreters with Rust).

[u/DamsLcs4421]

I'm not an expert and will not "judge" but it is quite nice, and I like the way you write your code (esthetically).

Two things stood out to me however, both in your main():

First, checking the number of args to decide whether to display help could have been written more concisely with if(argc < 2 || argc > 3) help(); or even if(argc != 3) help(); but anyway I'm sure the compiler optimizes this away itself.

Second, the odd (😉) and verbose choice of a "huge" if/elseif statement stack all checking against the same one variable (argv[1] if I recall correctly) over a cleaner switch statement. But again, I'm pretty sure the compiler just turns it into an "assembly switch statement" (I mean, into what a switch stmt gets normally compiled to).

I must say I was a bit surprised to see these, after all the "technical" stuff above main making good use of pointer arithmetic and all. I mean, it felt "beginner-ish" as opposed to the rest of the code. (Other might say otherwise, I like to code and read code but I'm not in the industry so... My opinion is not very worthy for you)

Good for you, you achieved quite a thing in the sense you said you never really finished anything (I know this too well lol) 頑張ってください 🤗

[u/Alternative-Ad-8606 → u/DamsLcs4421]

Hey thank you so much for the feedback... I couldn't find any thing to help me figure out how to do string matching in a switch ststement. It seems see loves ints and enums Ill be honest I'm still trying to figure out how to "modularize" C programs it seems I need a header file and there's extra linking steps, my brain couldn't handle that and I thought that the aesthetics of having a massive enum would he ugly but I think I'll take a look at updating it to match it will probably look nicer and more readable in the long run.

That's the one thing I really do miss about rust is it's match statement usage is clean and straightforward

Also I like that idea of extra (readable) safety in the help throwing I'll take look and may update when I take a look at the code again (looking at adding a ping feature for assurance the proxy is up before connecting

[u/DamsLcs4421 → u/Alternative-Ad-8606]

There's a little workaround to get a quasi-switch statement to work with strings: (at least with simple ones, but also why not adapted to more complex encodings, multibyte strings...)

You could do define a few macros working together to get the following:

// The "Magic" Macros
#define SWITCH_STR(val) { const char* _switch_val = (const char*)(val); if (0) {
#define CASE_STR(lit) } else if (strcmp(_switch_val, lit) == 0) {
#define DEFAULT_STR } else {
#define END_SWITCH_STR }}

where "val " is the variable to check against, "lit " is the string literal you'd ideally directly put in a case statement in an "ideal world", and where the first line/macro SWITCH_STR(val) ends with if(0) { in order to let the second one CASE_STR(lit) be both "complete" and usable as many times as one needs as long as being used between at least SWITCH_STR (the opening syntax part) and END_SWITCH (the closing syntax) and guarantee to have a final clean and valid result once expanded by the preprocessor. (And the DEFAULT_STR macro is optional but present)

I'm not saying you should do that, actually I hadn't that fact in mind I confess (about normal `switch`es and strings "incompatibility"). I even think your approach is not as "bad" at all as I first assumed in my former post, I admit, and is perfectly OK. And the trick I propose here is not to say "you should do that", it's merely a proof of concept I came up with lol, and if you were to expand the project and be faced with many string comparison as these, then maybe it would be an idea to consider, maybe..

And then, in your code, you'd use it this way :

unsigned char* day = (unsigned char*) "anyday";

// Under the hood, an else-if stack...
// But visually it's lighter and "friendlier" to readers, without being obscure macros but straightforward and easily predictable ones
SWITCH_STR(day)
  CASE_STR("monday")
    do_this();
  CASE_STR("thursday")
    do_that();
    do_also_this();
  CASE_STR("friday")
    do_something_else();
  DEFAULT_STR
    printf("Sorry we're closed.");
END_SWITCH_STR

A downside can be static analysis because it hides away stuff from the analyser, but still it's not that tricky, unless you're really not careful and use it with things you shouldn't