Follow

I've rewritten my first project, a small CLI utilising , , etc. I'm sure there are many ways it could be improved, but it's my beginner's effort and works well for my own needs.

Please feel free to critique, share, modify, collaborate and all that good stuff:
gitlab.com/5am/backup

Β· Β· 1 Β· 0 Β· 4

@syntax
Tip 1:
Design your programs so that you can always run them unmodified.

In this case that means externalizing 'sd_id', 'ssd_id', 'vc_pass'.
It could be provided by running your program with (named) parameters or by reading a config file or by reading environment variables.
If you must use hardcoded values, define them (as constants) at the top of the file.

Tip 2:
Add documentation and/or help text

Tip 3:
When you do the same thing multiple times, extract it into its own function.

@syntax
ad 3) This is known as the DRY principle.
Don't Repeat Yourself

Try to get in the habit of writing good commit messages.
'git log --oneline' should directly give you a reasonably good indication of what has happened in the repo.
'git log --stat' should tell you a lot, short of the actual changes (which 'git diff' will tell you), including which files are modified.

Tell why you made a change or what, not where. Also use the extended msg to give details.
I like using 'git commit -v'

@syntax
YW :)
Just found out that the chapter about DRY is available online: media.pragprog.com/titles/tpp2

I've bought quite a few books at pragprog, including "The Pragmatic Programmer", as they're (really) good and DRM free :)

Sign in to participate in the conversation
Mastodon πŸ” privacytools.io

Fast, secure and up-to-date instance. PrivacyTools provides knowledge and tools to protect your privacy against global mass surveillance.

Website: privacytools.io
Matrix Chat: chat.privacytools.io
Support us on OpenCollective, many contributions are tax deductible!