Nonetheless, keeping authentication/login data out of program code is generally a good idea. Deciding whether to store such info in a separate (private, rw-------) data file (as opposed to requiring manual entry on every run) is a question of weighing the tradeoff between convenience vs. risk.
If someone other than me can see the contents of a file after I've done chmod 600 on it, and can decide to do something malicious with that, it means someone with malicious intent has root access on my system. In that case, exposure of login info on a twitter account would be the least of my worries.
I disagree. It's an improvement. The executable could be installed in /usr/local/bin or someplace or be a module in a public lib. The only more secure answer is taking a passkey or something against some encryption keys and you have to do that under either SSL or with echo off in the terminal and the whole point of a tool like this is to make it easier, not to make it a functionally identical interface the web UI.
You know, the OP didn't strike me as someone who was contemplating putting script like that on a box with multiple users. Or even having the authentication to do so. He certainly wasn't asking about a general program (otherwise, he would have realized that hardcoding a single username/password for a global program isn't going to work anyway).
My guess is that either 1) he has written a script which runs from this personal box noone else has access to (in which, it doesn't really matter where he stores the password), or 2) he has written a script while working on a shared box, and isn't root. In which both the script, and the config file are stored somewhere in or below his homedirectory.