search

Rushwind13 / JMoria

My from-scratch implementation of a Roguelike game that will be an homage to IMoria
4 stars 4 forks source link

learning about lighting areas, pulled out functions from main dungeon… #46

Closed mschober closed 1 month ago

mschober commented 1 month ago

… FillArea

Interested in feedback on where the line is for smaller functions for procedural sections of code.

Rushwind13 commented 1 month ago

re: functions "vs oop" -- There should be no "bare" functions in the codebase; all functions should be methods of classes. Control visibiliity via public/protected/private -- the public interface for a class should make sense, in the end. I don't know how to maintain visibility while testing -- maybe set a #define ALL_VISIBLE and wrap everything in

ifdef ALL_VISIBLE

public:

else

protected:

endif

that seems painful but I don't know how other C++ programs do full testing.

In any case, certainly each method could be as small and atomic as it needs to be; I approve of pulling shared code into functions for readability and consistency.

I was trying to keep methods as simple as possible (trying not to weave function parameters through 5 layers of calls); until last night, all the Init() methods called by CGame::Init() took no parameters -- I had to add a vDesiredPos so I could control where monsters spawn. That's -- not great, but maybe necessary. This was all a lot cleaner before I started fucking up all the visibility (pub/prot/priv) to test "hidden" functions (as required -- they have bugs too :D )

Rushwind13 commented 1 month ago

.. I figured out how to do it, I always forget about friend classes in C++; this is where they win. I will go see if I can friend up all the tests and get my encapsulation back. https://github.com/google/googletest/blob/main/docs/advanced.md#testing-private-code

Rushwind13 commented 1 month ago

breaking out LightArea was a great add. I pushed this into a different branch