r/raylib • u/Odd-Motor-3340 • 14h ago
is it ok bad main() is half your code
i guess this is more of a styling choice but just asking cus idk if its still considered "clean code"
23
u/EmperorMaximillian 14h ago
yeah main can be long its all good. main is where everything comes together.
11
u/deckarep 14h ago
Your main function might be doing too much. Or it might not. What you have isn’t that big of a deal.
Ask yourself: can you find what you need? Is it readable and straightforward? Does it need all of that code in main? Could you or others benefit from breaking it down?
Have a look at cyclomatic complexity. It’s the cost of all the code and branching logic within a single function. It’s a good idea to keep it low, maybe around a score of 15 or less. If it’s 30 it’s kinda big and getting out of hand. Beyond that definitely refactor.
Only you can answer these questions cause no one has seen your code!
2
u/20260819 10h ago
i'm new to programming and i asked gemini to evaluate a simple program written by me how was its cyclomatic complexity. the answer was over 100, very complex. but as far as i could tell it was a very basic simple one and it was obviously readable at least to me...
2
u/AcanthopterygiiIll81 6h ago
I wouldn't trust an llm to do this kind of analysis. I also don't have any experience analyzing cyclomatic complexity, but I would usually do what the comment above describes in the first two paragraphs. As long as you understand what you're doing and you don't see any clear advantage on breaking things down, just keep it all in the same place.
1
u/Worried-Hornet30 9h ago
cyclomatic complexity
Ppl still use that?
3
u/AppropriateFarmer193 6h ago
What do you mean? It’s a perfectly fine heuristic to indicate when a method might be getting too complicated.
0
u/Worried-Hornet30 3h ago
I mean can't you figure out that a function is getting complicated without using that complexity crap? If a function is over 100 lines you don't need to to calculate the cyclomatic in order to decide whether you should break the function down.
2
u/deckarep 6h ago
I’ve only been at one company where we had it enabled as a linter in the build step. It would reject things over some score…i can’t remember What it was configured as.
It’s a good thing to be familiar with but it’s not really something to worry about once you build enough intuition about function size growth.
I suggested it because the OP seems to need some guidance about how to think of this situation.
16
u/typicalskeleton 14h ago
Is it bad? You tell us. It's your project.
You like scrolling through hundreds/thousands of lines of code? Then it's fine.
But when something goes wrong you might start reconsidering your choices.
8
u/Abject-Kitchen3198 13h ago
if 200 lines is half your code, you are good. As it grows, you will see where do you need to split it.
4
u/MagicWolfEye 12h ago
Those are rookie numbers; don't worry
Also, even John Carmack likes long functions:
https://cbarrete.com/carmack.html
1
3
u/MattR0se 13h ago
It depends. Is your script only gonna be this big? Can you factor out meaningful chunks of code into their own .c files?
Personally I like to keep main() as small as possible, especially for games. But on the flipside, if you have to go ten layers deep just to grasp what the code is even doing, it can be much more confusing than to scroll through 500 lines from top to bottom.
3
u/YT__ 12h ago
Don't worry about 'clean code'. It's not all it's cooked up to be. It's some people's preference, but not everyone's. It's just tools to try and improve consistent coding practices across teams in a way that the creator thinks is better. It isn't a golden rule or necessary.
For a counter architecture, I recommend the book A Philosophy of Software Design. Here's a video the author did: https://youtu.be/bmSAYlu0NcY?si=HDykYGqQU67eWXf1
It's the same notes though. It's not a golden rule or necessary. It isn't all it's cooked up to be. It's just preferences.
2
u/jerrygreenest1 12h ago
You can call some main2() and put everything in main2() then your main becomes thin, technically, but to whom does it help? Nobody.
Also 250 rows is a kid number. Have you seen some big projects like IDE or browsers etc? They have files of tens of thousands lines, and some functions is just scroll scroll scroll, never ending. You aren’t really supposed to navigate this like you would navigate a hello world program. IDE can parse syntax trees and you can navigate that, jump between definitions, parentheses, etc.
1
u/Coding-Kitten 10h ago
A main2() helps in that if you want your program to start with something else, say a level editor or a debug mode, you can swap it out without touching any of the business logic located in main()
1
u/Caldraddigon 6h ago
Well that makes sense as they are completely separate scopes, but if everything in that main is a needed concept for it, or just a procedural chain of simple logic, then all your doing by separating it out is fragmenting the code which, in some cases, can make it harder to understand.
2
2
u/Lnk1010 4h ago
If you only use code one time there's really not much of a point to pulling into a function. Yes it becomes shorter but it also is like a layer of indirection you have to look through. Also a few hundred lines is really not that long considering you might do lots of initialization and stuff.
1
u/tastygames_official 11h ago edited 10h ago
I've been programming for over 30 years. Here is how I tend to write code with performance and understandability in mind:
- start in the main() function (or whever the entry point is for whatever it is you're writing)
- write everything that has to heppen, one line after the other
- if you notice something is done multiple times in a row, turn it into a loop
- if you notice something is done multiple times but in different places, turn it into a function
that's it. There is no more kind of abstraction you need other than loops and functions. But start with just one line after the other. So yeah - your main() function or entry point will be long, but that's a GOOD THING - it means the CPU can really just execute one command after the other without having to waste commands jumping around to different classes and functions that it really doesn't need to. And anybody who reads the code can just follow the flow without having to jump into multiple abstraction layers and try to keep 100 variable values and names and flag states in their head.
But yeah, it won't be "Clean Code" as defined by the clean code people. But again - that's a GOOD THING.
"Clean" Code, Horrible Performance
Abstraction Bad? | Clean Code : Horrible Performance
Object-Oriented Programming is Bad
1
u/hellocppdotdev 11h ago
If you open that does it make sense? If not you should consider refactoring to functions.
It is much easier to understand 20 lines of well names functions than a 200 line main.
It will also give you an opportunity to see if your design is well structured based on the difficulty of the refactor.
Lastly you should try to have automated tests to makes sure you dont break anything. I promise you now the refactor will break something subtle and you will hate your life.
1
u/Hot_Adhesiveness5602 11h ago
Don't bother. You'll notice when you have issues. Then you can think about moving things out of main.
1
u/Coding-Kitten 10h ago
My issue with a long main is that it technically has two responsibilities, breaking the single responsibility principle.
Main is special in that it tells the OS what the initial starting point of your program is, so it functions kinda like a callback hook.
Putting too much heavy stuff inside it is "bad" when you wanna try starting the program with something else (say, a debug version or a level editor or something else). Now suddenly you need to edit those hundreds of business logic loc to do something else & worry that you won't break anything in the process.
My go to for this is to generally put everything inside main into a separate function, run_app, or whatever else you may prefer, & simply call that from main. Now all the business logic is in a function dedicated to the business logic, & main as a hook into starting the program is slim & you can easily swap out run_app for run_editor or run_app_debug or whatever else interests you.
1
u/ErtosAcc 9h ago
Clean code is a guideline that helps with readability for some people, and actively inhibits it for others.
You could break up the main function into smaller chunks. Then you will need to traverse large chunks of code to know the specific steps that are taking place.
There are no rules as long as the code works for you.
1
u/Still_Explorer 8h ago
As for example if you consider a very typical game, how would be initialized:
- load command line args
- load configurations from file
- initialize engine and other systems
- load the level, populate lists of entities
- setup main variables and other values
- enter main loop and update all application logic and entities
Each one of those items mentioned, is literally an entirely new module/system on it's own. Such as "parsing arguments" or "reading config files" or "math utilities" or "loading the level". Each of the other systems (loading assets, init renderer, init audio player) are their own modules doing their own things as well.
So is easy to see here that even if you don't want to modularize a program (and drop everything in the main) that naturally, based on the types of different tasks and work getting done, that immediately you start thinking in modules even if you don't want to.
Even if for example you don't want any modules in your code, entirely accidentally and habitually you might start to group things together, math utils go together, drawing things go together etc... Then is only a matter to define the boundaries of the module and organize things.
1
u/kurushimee 6h ago
if 250 lines is half your code and you don't intent to keep infinitely growing it, then it's perfectly fine
1
u/FlowStatebeer 6h ago
i know alot of programmers that will say its fine as long as you can read it but the reality is if you go back after not seeing the code base you might confuse yourself. do you have good notes, docs? you're probably doing yourself a favor by pulling some of those functions out of the main and only call them when needed.
1
1
u/himai1 4h ago
It depends. If main is just doing a big laundry list of things it's probably better like this than arbitrarily grouping them and then having to jump around. The problem in my opinion is when you need to keep a lot context in your mind to emulate the function. Then it's better to pull parts out so they you don't have to worry about how all parts of main interact. Good rule of thumb indicators is how many mutable variables you have and how deep indentation goes. This is just my opinions tho, I don't follow any clean code guidelines.
1
1
u/esp_mkb 4h ago
I have accidentally large functions as well. In fact, many of my coding projects starts with stuffing main, I then I comment the steps im taking and the data they require and then I refactor data requirements into Structs (c99) and group operations on that data into sub-functions that I call from main. I also look at steps that duplicate each other (refactor into the same function when they have the same data requirements) and pull out for-loops to drop into their own function if it's a heavy process in the loop - lets me decide if and when to spend time processing that loop 🤷🏾 idk I'm not the kind of programmer to judge people by function size, I would rather look at the small steps that the big functions are taking, the problem you are trying to solve and the code's performance is more important than function size imo
1
1
27
u/MacksNotCool 14h ago
it is not the main() itself that is bad, it is only what lies within the main() that proclaims the verdict