Shrinking should not be done on a regular basis.
Sometimes transaction logs (.LDF) grow because there were massive deletes and the database recovery mode was not set to bulk-logged. Sometimes regular transaction log backups fail and the transaction log grows abnormally as a result. In these cases it is ok to use shrink. But only shrink to a reasonable level. Use the size of your transaction log backups to guide you if you don’t have a baseline of what your transaction log file should be.
Also, when massive deletes are run against a database, the free space in a data (.MDF) file increases. Here again it is ok to use shrink judiciously.
If transaction logs and data files are growing because the application workload demands growth, you must plan on accommodating that growth. You need to store less data (by purging or archiving for example) or get more storage. There is no way around this. If you shrink files that fit this description, SQL is just going to grow them again so you are fighting a losing battle.
Regular shrinking causes internal, external and index fragmentation. In addition, every time the database needs to grow files, there is a big performance hit and the request that pushed the database over the edge must wait for the growth operation to finish.
Use shrink carefully.