Is it a good practice?

In some file i put:

#define SET_TIMER(lambda, time, loop) \
do \
	FTimerHandle time_handler;\
	FTimerDelegate timer_lambda;\
	GetWorld()->GetTimerManager().SetTimer(time_handler, timer_lambda, time, loop); \

And every time i just use:


I would avoid macros if it’s not really necessary and instead use helper classes or functions, but macros have its place. If it can’t be recreated easily in a helper function or helper class, macros can be appropriate to use. With more experience those calls will become easier to make. Ask yourself the question “Is this good enough for my needs?” Knowledge about the application and its future will help you make better calls here, also if something wasn’t good enough you can always go back and fix it then instead of spending hours now (overengineering) unless you know this will likely be an issue in the future.

In your particular example I think the code is hard to read and not self explaining. Therefore would I probably not recommend to use it, especially if you know that someone else will be working in the project or if maintenance of the application will be done by someone else. If its a test example however, I think its good enough for now. More pro and cons with macros can easily be found with google =).

Edit: Can add that the reason I don’t like macros in code generally is that they aren’t typesafe and first checked when compiling. They can contribute to making the code harder to read (= increases the likelihood for more mistakes and slows down development speed). If you are worried about performance, inline function can often do the job just as good but don’t care too much about code optimizations, that’s the compilers job. Algorithms and data structures is much more likely to affect the performance, that’s your job =)

I see, thanks :slight_smile: