Please do not forget non-English installations. This example will not work with them and the environment variables %ProgramFiles% should be used because on non-English systems there may not be a path "C:\Program Files". Whether the MS-SQL environment will evaluate these environment variables is a different matter, and one that I have not tested.
Other than that, am I the only one that wonders why there is a seeming need from Microsoft for their default database location being in precisely the wrong place? Especially considering Microsoft's own rules and guidelines on file locations? The "Program Files" directory is strictly for program files and not for data files. Data and code should never be mixed. Many, many years of pain were suffered with hapless application developers that assumed that all users had local administation to a system and "Program Files" was an acceptable place to write things to. It wasn't, it never was, and caused no end of issues when later Windows operating systems started to have security retro-fitted to them.
I also find it strange that a database transaction log file needs to be identified both by file extension and by name. Maybe I suffer from a bit of OCD on this front but where possible I always name them the same file component but with different extensions. For multi-file databases this scheme does not work, but then none of the MS-SQL databases that I manage have needed multiple files and I suspect that getting to the database scale where they may be required is going to require rather more consideration than just database file naming conventions.
Interesting, and useful, cautionary point about the process only working on database (re)start.