When I learn a new language, or write something in a language I don’t use very often, there are a few ways to go about it. I guess, often we’re forced into learning how to do what we need to do with the language. Or, sometimes we may be studying the language, or just trying it out for fun.
Websites like Code Wars are great for learning how to use a new language. How I use the katas are by looking at the kata description, and assessing how do-able I think the problem is. If I think it’s ok, I’ll start wotk on the problem it.
My way of coding involves looking most things up, either on the official docs, or on Stackoverflow. This method is great for starting a problem in a language you don’t know very well. It’s also a good way of checking that whichever method you’re using does what you think it does, even if you have used it many times before. With an unfamiliar language websites like Code Wars are great because you can compare your very long-winded solution to the much shorter solutions by people who know the language a lot better than you do.
I have written a few BASH scripts in the past, but not for quite a while. I wanted to have a quick play to see if I could remember anything. I could look my previous scripts up, but they may not be best practice. This was a perfect example of a way to try a quick problem on Code Wars.
A quick script to check that a US phone number was in the correct format.
REGEX_PHONE='^[\(]{1}[[:digit:]]{3}[\)]{1}[[:space:]]{1}[[:digit:]]{3}[-/][[:digit:]]{4}$'echo "$1" | grep -P -q $REGEX_PHONEif [ "$?" -eq "0" ]; thenecho "True";elseecho "False";fiexit;
There’s not a huge amount of code here but this took me about 7 tabs of Stackoverflow. It’s very basic and quite readable. It passed the test and was submitted. After submitting, looking at other people’s solutions can show you better ways to do the same thing. The one-liners can be very clever but sometimes be unclear or not very readable. Just looking at a handful of different solutions from one-liners to solutions that are slightly longer can be very helpful.
One of the main takeaways I took from this is the way I’m using the regex with grep
is quite clunky.
This is because the Stackoverflow answer I found to use regex in BASH wanted to use the perl version of regex
(Perl Compatible Regular Expressions, PCRE), which would be called this way.
I believe BASH uses the Extended Regular Expressions (EREs) version of regex natively,
which is what PCRE is based on but will be different in some ways.
It sounds as though there is less functionality in ERE compared to PCRE, which has become the de facto version of regex.
For most applications BASH’s native regex is probably ok, but it needs studying to figure out what is different.
I’ll try using the native version on more BASH tests in the future.
The BASH docs explains more about using regex in BASH…
An additional binary operator, ‘=~’, is available, with the same precedence as ‘==’ and ‘!=’. When it is used, the string to the right of the operator is considered a POSIX extended regular expression and matched accordingly (using the POSIX regcomp and regexec interfaces usually described in regex(3)). The return value is 0 if the string matches the pattern, and 1 otherwise.
Here is someone else’s attempt that uses the standard way to use regex. I modified it a little to simplify it slightly. This example is good because it uses a similar structure to my attempt, but this person is using regex the same way as most other people.
regexp="^\([0-9]{3}\) [0-9]{3}-[0-9]{4}$"if [[ $1 =~ $regexp ]]; thenecho "True"elseecho "False"fi
The regex pattern itself is very different to mine. I went ultra conservative and explicit, which obviously isn’t needed. This person’s pattern looks like something I might write for PHP.
I just mentioned comparing a BASH script to how I would write a PHP script. Sometimes, it is easy to slip into writing a new language in the same way that you would write another language.
There are differences and similarities between BASH and PHP. While some things will probably work similarly, other things I believe should be approached quite differently.
Going from PHP to JavaScript is fairly straight-forward. If I end lines with semicolons and use variables that have dollar signs, the two languages look very similar. In old legacy code where HTML, CSS, jQuery and PHP are all jumbled up together it can be easy to forget which language you are writing for.
Even though I have written in JavaScript for many years I am still more comfortable with PHP. I understand PHP more than I do JavaScript. But, that being said I have used JavaScript in most websites I’ve ever worked on, whether it be vanilla JavaScript, jQuery or VueJS.
Historically, if I once used PHP and JavaScript in a very similar way, the advent of frameworks makes this less possible. PHP’s Laravel looks and feels very different to VueJS or GatsbyJS. If I’m writing VueJS in the same way that I write PHP I’m doing something very wrong.
Frameworks are great for getting people and teams working in a standardized way. Once you have a framework set up, modifying and adding to it is probably a lot less scary than starting off with a blank sheet of paper. Frameworks have helpers, and they lead you to arrange the code in a structured way. That being said, they are not a silver bullet, and you still have to try to follow best practices. But, frameworks do make the barrier to entry lower and lower each year, which can only be a good thing.
Ironically, frameworks do not translate very well to tools like Code Wars. Maybe there are some websites out there where you can solve problems within a framework.
Practice by example is a good way to learn something new. The online docs for whichever language are often surprisingly good and can save a lot of searching. With coding, we are lucky that the answer we’re trying to find has normally been asked and answered already on a website such as Stackoverflow. Even after we have solved our problem and written some code, could we have written it better? Are we using the best tools for the job? Even if we have done a great job, it can be interesting to see how others would approach the same problem and learn from their approach.
Quick Links
Legal Stuff