File header rule improvement

[jesus-mg-ios]

We can improve it, by adding a way to insert variables and, using the created {created.year} optionally not from the file, but from the git.

If someone could instruct me on how to add the functionality (Where I can see this) I would try to add it.

(

SwiftFormat/Sources/Rules.swift

Line 4331 in 4bf4751

case var .replace(string):

)

Proposal:

Variables passed from the command line and added in .swiftformat as ${{variableName}}, the others can be {created.date.git} and {created.date.git.year} {modified.date.git} {modified.date.git.year}

[nicklockwood]

This functionality is already landed in the develop branch, it will be included in the next release

[jesus-mg-ios]

Fantastic!
@nicklockwood Could you let me know which was the PR?

[nicklockwood]

@jesus-mg-ios #1507

[nicklockwood]

@jesus-mg-ios I realize now that this only partly addresses your request. What is the use case for the custom variables you mention? Couldn't you just hard-code the values in your header template?

[jesus-mg-ios]

For example, if you want to create a check method to review files periodically, you could add the date the file was modified (from git) and/or reviewed. Or maybe you want to add a variable Module name, eg, imagine that you have 2 modules with different files, in each module you have the file header with the module name on the top (that matches with one of the parent folders), when you change one file from one module to the other, the file header must be updated reflecting the correct module.

[nicklockwood]

@jesus-mg-ios you can do all that now by generating your header template using a script and setting it via the command line though, right? Is there any difference between doing the variable substitution yourself vs having SwiftFormat do it for you?

[jesus-mg-ios]

Yes, you could even add the header format that Swift format already does using a script, isn't it? So the aim is to remove duplicity.

[nicklockwood]

@jesus-mg-ios right, but the idea with the built-in variables is that it's easier than figuring out how to get those values yourself. If you already have to write the code to extract the modified date from git or whatever then it doesn't seem to add much benefit.

I could add the modified date as a built-in variable if that's something you want? Getting the module name would be trickier as I'm not sure how you'd infer that without parsing the project file or something

[jesus-mg-ios]

Okey, the modified date as built-in is a nice improvement, so for my side go ahead with it. The other one I could try to manage it using another script.