drum_computer:
Here's my question: what's the best practice to put that code away? 
I mean I know I can just make another .h and call it something like "project_funcs" but my intuition tells me a) nobody does that b) dev community has faced this problem trillion times and there is a solution for that.
maximize coherence and minimize coupling. a file should contain all the functions for some aspect of the project. since there are often dependencies on other code, coupling to that other code should be minimized.
i often include pcRead.cpp/h in all my projects. it supports single letter commands thru the serial interface. the code is in the .cpp file and the function prototypes are in the .h file included in other files using those functions. pcRead gets customized for each project.
for this project it got expanded to have several modes: i/o, commands and configuration. by passing it a Serial argument, it can be used both thru the serial monitor and a bluetooth serial interface on a phone
as a further example, i'm working on a wifi model railroad throttle. or this project, i decided to declare all my variables in a separate file, vars.cpp with vars.h providing "extern" references for the variables that used in various other files. (if you declare all your variables in a .h file, including that .h in more than one other file will cause errors due to multiple definitions of a variable). vars.cpp also defines a table of variables that are stored.
file.cpp/h contains routines for storing and retrieving a specific set of variables from eeprom (spiffs). it works based solely on the var table in vars.cpp. as new variables need to be stored, the var table gets expanded but files.cpp doesn't need to get modified. pcRead also supports changing variables using the var table. (var table is an example of coupling)
there's also a web interface. that code is in server.cpp/h. miscellaneous functions are in utils.cpp/h
code to model locomotive behavior is currently divided into brakes.cpp/h, rollRes.cpp/h (bearing resistance tables) and physics.cpp/h. physics implements newtons equations combining tractive effort, braking, grade and rolling resistance to determine acceleration from the mass of the train and the train speed.
this approach keeps files sizes relatively small, making them easier to edit. specific files have code for specific aspects of the project, physics is not interspersed with the web server code. brakes are separate from rolling resistance tables and interpolation functions.
60 utils.cpp
75 file.cpp
82 rollRes.cpp
93 brakes.cpp
120 vars.cpp
153 physics.cpp
238 server.cpp
438 Koala3.ino
482 pcRead.cpp
i think examples are the best way to see how to organize code. I learned a lot from chap. 8, Program Development in the Unix Programming Environment where a small but non-trivial interpreter is developed in stages.