Home » Posts tagged "Refactoring"

Ploter refactoring

Some days ago I mentioned on twitter that I feel trapped inside infinite refactoring loop. I see various places that I’m not satisfied with in my code, and it keeps me from adding new features. Yesterday I finally added one, simple algorithm to check how refactoring simplified code structure… well… it’s not that bad. But I decided to work some more on ploter class. It have some nasty magic numbers and very messy draw function (you can see it here). Read more

Yellow – Red – Blue Refactor

When refactoring really small projects I start with pen & paper and wrote down all classes, variables and methods. Read more

One thing at one time.

I decided to do more often, but shorter sessions. It suits these short free time gaps I have lately.
These last sessions were another Refactoring ones with aim of extracting functions, so one could do only one thing, instead of all purpose procedures like DeleteSpritesAndFonts(), or two purpose DrawScene().

Soo little changes list:

-> Cutted PrepareSpritesAndFonts() and DeleteSpritesAndFonts() to four functions:
PrepareSprites, PrepareFonts, DeleteSprites, DeleteFonts.
Now all that’s inside PrepareSpritesAndFonts is:

bool Game::PrepareSpritesAndFonts()

	if( PrepareSprites())
		bool ret = PrepareFonts();
		return ret;
		return false;

I think it looks better this way. Now it’s easy to tell what’s really inside, and extracting DeleteSprites() helped to delete redundant cleaning after failing with preparing fonts.

-> Also I properly named arguments in headers, so that intelisense can help what’s the meaning of what variable passed to methods (yeah, the fact I haven’t done it at the begining sucks).

-> Bid farewell to victory, running and pause variables, and welcome our new datatype GameState enum! Now with all new Defeat state.
Although it was a little confusing to replace them at first, because of

   // Loop with redrawing and listening to keyboard events

loop, that created a little confusion. If I’d replace ‘running’ with a condition like (gameState != Victory && gameState != Defeat) it’d be confusing. Why game should run in paused state, but should not in Victory, nor Defeat?
After putting some thoughts I decided to make while a simple infinite loop with breaks after goint into Victory or Defeat. I bet it’s still far from perfection but I like it. For now.

-> Extracted “DrawPause()” from DrawScene – it was unnecessary to check all the time whether game is running and then if it’s paused.

-> Probably it’s a bit obvious, but al_flip_display() can be called only once. It’s unnecessary to do something like that:

	if (gameState == GameState::Running)
	else if (gameState == GameState::Pause) 

with ending all procedures with al_flip_display. It’s enough to call it at the end of Draw calling function.

-> Slight renaming. Variable Hp is now known as Lives, and pong is now a pongSprite.

As always you can find changes in repository.


Someone might think that three day week is a thing easily done, but sometimes everything just happens at the same time. One university project after another and carring out duties. I’m really glad it’s over for now, but I fear that I won’t have time in may to perform a long coding sessions.

For now I simply standarized language used in naming classes and variables. Until today it was (as you could see) little messed up with english names (classes, most of function names and variables), with polish (mainly translation of english names).

And so changes for today’s short session:
-> A Game class object name changed from gra (polish for ‘game’) to App.
-> List of brick objects name changed from kafelki (polish for ’tiles’) to Bricks.

Also I reviewed most of code, and got a basic idea what should I change to improve quality of the code.

Hope to code it soon (:
Also those (rather slightly) changes are in repository.