I suggest not adding numbers to variable names.

for context, this is to help clarify the local path should be the first argument and the remote path should be the second argument, i.e. given a list of args["sess:remote/path", "/local/path"] or the converse args[ "/local/path", "sess:remote/path"] for the other function shouldCopyRemoteDirToLocal

it's still not clear from the variable naming alone, the first argument needs to be the local path and the second argument needs to be the remote path or vice versa.

so, im not sure what a good solution to this is other than to indicate localPath1 as 'the first argument that we also expect to be the local path' and 'remotePath2' as 'the second argument that we also expect to be the remotePath'.

any ideas how we could name this?

edit: i've updated this to remove the second argument on the whole and that gets rid of the numbers from the variable names, seemed superfluous

but i don't know about not adding numbers to variable names as a blanket rule, especially if we need to indicate some kind of ordinal

The variable names in a function signature should ideally be descriptive and not denote their positions. The position of a parameter in a function is determined by its place in the function definition itself, not by its name.

I suggest
func shouldCopyLocalDirToRemote(localPath, remotePath string) bool {

i think in this case the intent of the positions was to also denote some sense of directionality, but yes this was likely overthought, either way its been removed now, thanks for commenting !

I'd agree to keep numbers out of names. I don't think there's a rule but just looks off.
Shorter names are better. So in this case some thing a and b is idiomatic in go. The standard library uses it all over the place.

I think shorter names can be better but I think they also need to be use judiciously because they can muddy a codebase or make logic borderline unreadable because you can lose context on what kind of operation a variable is intended to perform.

So, I think short names are fine as long as they preserve the context of what the code is doing. But if you lose context i.e. you change remotePath and localPath to just 'path' then it's completely unclear whether you intend to take the remotePath or localPath as an argument.

However in defense of this, I think from is probably descriptive enough, and I think that captures all the above.

So instead of func shouldCopyLocalDirToRemote(remotePath) we use func shouldCopyLocalDirToRemote(from string)

Ideally I would have

func shouldCopyLocalDirToRemote(from Path) where Path aliases a type declaration for strings, because it's not clear from 'from string' that the from string needs to be a validated abspath, but I think that's a bit much for our use cases right now.

There have definitely been cases in the past where the why of business logic has been lost because of single letter variable names, resulting in bad refactors.

Let's call this tarRemoteDirectory