Bitesize Improvement 1: Developer
Posted on Saturday May 16, 2015 at 11:00PM in Technology
The hallmark of successful people and organisations is continual improvement. Here are some small suggestions for improving yourself as a developer.
Learning a little bit on a regular basis is a great way to build your confidence and avoid stagnating. So don't try to learn everything at once; just pick one thing that you think looks interesting that you don't already know.
I've put these in order of complexity, with 1 being very easy and intended to be an introduction to the subject.
Yes, we've all heard the joke. But a simple regular expression can save you much trial-and-error. If you've never used one, you're missing out.
This is a very simple application of regexes. For example,
a (blue|red) carmatches both "a blue car" and "a red car"
The syntax for find and replace varies between regex flavours. Java uses $1 for the first match, $2 for the second, etc.
So you could pimp up the car in the previous example with a replacement string
a flashing $1 car
which would give 'a flashing red car' or 'a flashing blue car'
This is quite advanced, and useful when you are trying to avoid matching the wrong thing. The excellent regular-expressions.info site explains it better than I can.
Learn your IDE's refactoring tools.
Renaming classes, methods, and variables is a simple but powerful way of keeping your code base sane. It requires very little effort, once you've learned your IDE's keyboard shortcut. If you don't know it yet, here's a couple of links to help you out.
The 'Extract method' refactoring is your trusty sword in the battle against duplicated code. A statically typed language such as Java or C# helps here, but modern IDEs such as PHPStorm and PyCharm (both from the magnificent JetBrains) do a pretty good job with dynamic languages.
The opposite refactoring, 'Inline method', is less frequently used, but still useful. For example, during a complicated refactorings you might be left with a short method that is only called in one place. Feel free to inline it, if that makes the code more readable. You can always extract it again later.
OO purists will insist that member variables of a class cannot be accessed outside of that class, and that you ought to write tedious get and set methods. Well, your IDE probably does this for you with its 'Encapsulate field' refactoring.
In my opinion, the availability of this refactoring makes accessor methods less important, since you can always introduce them when you need to. (This is only true when you control all the code, and not, for example, in libraries and APIs consumed by others. But in that case, it can be argued that you ought to be providing interfaces, not concrete classes.)