C for large projects

I'll keep the quick code with refactoring in mind for my next project.
any C specific tips on breaking a problem up?

I can give a few:

1. The larger a function gets, break it out
If a function is getting excessively big (there's no hard limit on the maximum LOC) then its likely something needs to be factored out into its own function. Of course, if the function is more complex then the maximum LOC of code is bigger. Use your discretion when you need to refactor.

2. Collections go under structs and classes

Got some data that are closed related/dependent? Put into their struct / class.

3. Keep everything simple at first. Don't overthink too much when you're completing the initial task.

How much refactoring do you do to clean up the messes you've made while initially building it?

Depends on how much quick code you decided to do on each module/part/phase of the program.

Generally speaking, like how much time should you spend on refactoring vs moving on to write new code? 20/80? 5/95?

If you plan shit ahead on pen and paper you avoid most spaghetti.

Not really sure. For bigger projects like a game there are going to be multiple modules and all of those modules have to be cohesively tied together. For example, I'm making a game I already have the tile map up on the screen. First, I had a 2D array hold the map. Then, I created a struct to tile this array with some meta data like its width and height. Later, I created a struct called Tile that then held the color and the type of the Tile. The type being the terrain. Is it grass, stone, water, etc. Now I'm creating the code for parsing a map from a file into a TileMap instance. Also, since my code for moving the player is inside the same function as my tile map render function, I'll factor that out. Once that is all done, I can be ready to start refactoring for the tile map code and hopefully make it clean and effective.

I ask because I have a friend who said their team does refactoring sprints every few months, which sounds like a really good idea on the face of it. Meanwhile, the companies I've worked at (admittedly not the greatest in the tech world) are afraid of the word refactoring, so much so one of my managers told me to never use that word around the client.

Just wondering how it is for other developers and whether or not refactoring should be planned for when it comes to organizing your own large scale project.

refactoring is a meme, i mean just stop and think about the word for a second. re-factoring. what? it's a meme paradigm word for making code better without changing any functionality, which is of course impossible. Externally you might see the same thing, but thats OOP crap. Its the internal that matters, doesn't matter how you "interface" with it if the logic behind it is garbage. Thats why you should plan things on paper first. If you have a clear idea of the various parts of your program beforehand you can implement each part. Patching them together is just combining each "part" into a bigger one for a specific use case.

>handmadehero.org/watch
remember john romero (or was it carmack) used to rewrite the game engine for doom et al very frequently. i'm not sure if he rewrote it from scratch every time, but i do think that he made significant changes as it evolved, so that he was never painted into a corner

blargh! ignore the greentext link. fucking Jow Forums, copying clipboard buffer into comment automagically.

Hrm, solid point. But can't you make the argument that there might be some structural complexities you can't anticipate until you actually try to implement it? Like I agree with the underlying sentiment, "measure twice, cut once", but realistically, I'm not sure it's possible to foresee every thing that can go wrong.

I will take the paper thing to heart. It's not the first time I've heard that comment.

John Carmack wrote the game engines, bought a nitro-boosted Ferrari, and went on to work on Armadillo Aerospace, which was literally designing and building rockets, then operated as the CTO at Oculus.
John Romero was the douchebag assclown that decided to start skipping work to pretend to be a rockstar and was fired, only to go on making the infamous Daikatana piece of shit game under his Ion Storm company which was run deliberately by gaming enthusiasts instead of professional developers. After that company imploded under the weight of its own incompetence and teenage drama, he went on to make a bunch of shitty mobile games that nobody played and then married a woman who was barely older than his oldest son. Romero also has a googly eye.
Please learn the difference.

Attached: ee1a79ec-d240-456a-8312-3a00e7684edf_John_Romero.png (597x428, 737K)

its not "perfect" no, especially if you are using libraries which have weird requirements or interfaces or abstractions or encapsulations whatever the fuck meme word you want to use, as these can easily throw off some your planning. If you are, it's generally a good idea to try and write your code as if the required methods or structure already exists, then worry about it later.

As an example say you are making a simple 2D platformer.

you want background/level/stage.
you want sprites.
you want sound/music.
you want a titlescreen
you want a stage select screen.
you want a victory screen.
you want a menu to save/quit/load/restart/options whatever.
you want a hud with powerups and healthbar whatever.

What do you need for the titlescreen?

Some way to do input and check if newgame was selected.
Some way to play music.
Some way to display a background image.
Some way to display animation/palette effect etc.

What do you need for the stage screen?
--same shit, but now detect what stage was selected
also need a way to change screens

What do you need for the stage itself?
--same shit, but now control the player sprite
detect collision with background
detect collision with other sprites
play sound effect on collsion
etc.

data structures will emerge naturally with planning, knowing what you need
and the algorithms you need will tailor themselves to your data structures,
how this data should be used/changed.
and how to composite it together will emerge naturally when you look at what parts exist in the primary domains / bulk of your program, in this case the screens.

C over C++ all the way user, the effort pays off. The language is aged well enough where you can search around for any small component you don't wanna write yourself, yet the STL is very sanely small.

Attached: rddmw9lga3y11.png (742x767, 685K)