As a broad, sweeping generalization, "don't shrink the file. Don't bother."
Databases are designed to be self-maintaining structures, and they are. Let them! They will recycle space on their own (although they don't shrink the size of the file .. an expensive operation on most filesystems), and they'll maintain their indexes on their own. No, they will never keep the file "as small as it could be," nor the indexes "as optimized as they could be," but they will keep their own house in order. Let them.
"What if after truncation/backup action I shrink the file?
What will happen after this in case of database recovery?"
Nothing will happen. As a matter of fact, Microsoft recommends that you truncate the log prior to shrinking the file.
What happens if you don't shrink files? Large transactions can cause the files to bloat significantly, and while this space may be reused by SQL server for later operations it won't be recovered automatically unless the autoshrink option is set. I'd strongly suspect that these large files (which may be several times the size of the actual data) increase the time required for data access and reduce the amount of space available on disk for other system processes such as disk-cacheing.
But hey, that's not important is it?
Sundial, isn't there a forum for making payrolls that you can join?
You can achieve this by putting your database in what is known as "Simple Recovery Mode". If your database has high insert/delete activity then I would recommend against it. It means that if you backup your database at midnight and then your system crashes at 5 pm, you have lost an entire day's worth of transactions. Do you have a strategy for recreating them?
In a normal recovery mode you backup the transaction log (maybe every hour or so) so that you can at least recover to that point, and unless your system gets really hosed you can also recover un-truncated transactions right up to the point in time that the crash occured.
You can't do this if your database is in simple recovery mode. Simple recovery is normally used for development databases, and not on production systems.