Is adding ./bin a bad idea

The $HOME/bin, . and ./bin are usually looked as a security risk.

For the $HOME/bin it's the problem of some "cracker" pushing some script (say a script named nano) to that directory, then it waits until you run something like sudo nano /etc/hosts to gain instant root access (change the nano to vi, emacs, whatever; the command isn't important, it's the payload it can execute).

For . and ./bin, it is still the same problem: adding an extra program working from the wrong directory.

If those ./bin/command are in different directories instead of /usr/local/bin (the preferred solution for new, local scripts), it's because they do different things; what if you run the incorrect one?

If you name your commands the same way (let's call then update, commit, cleanup, etc) you may be working on a directory, then you get one phone call and change to another for a quick check. After hangup, your brain will try to resume what you were doing and most of the times will forget that quick "cd" you made (particularly if everything on the screen seems to point to the correct directory) and finish running a command on the wrong directory (say that cleanup script that erases all your month work).

It might look an innocent mistake, but they happen every day to many people! :)

A good workaround (or better solution) is to use alias:

alias proj1-cleanup=/srv/proj1/bin/cleanup

and add on the script the correct cd to make sure it runs on the correct directory.

This way, playing with the $HOME/.alias to add the various scripts you need, you have different commands to do the different things, and even if someone cracks your browser to create a $HOME/bin/ls file or some local user creates a bin/ls file on any directory, those will never be executed, as your path still points to the correct commands.

But hey, it's a personal choice; you are the one that knows what your local risks are and what the commands do.