If you haven't heard of Source Making, you should check them out. They have a lot of really great and simple tips and tricks to help developers write good code and refactor bad code, and they have lots of practical examples for each of their techniques.
Here's two of my favorite tips:
This technique adheres to the Tell-Don't-Ask principle: instead of asking an object about its state and then performing actions based on this, it is much easier to simply tell the object what it needs to do and let it decide for itself how to do that.
Removes duplicate code. You get rid of many almost identical conditionals.
If you need to add a new execution variant, all you need to do is add a new subclass without touching the existing code (Open/Closed Principle).
Problem You have a group of nested conditionals and it is hard to determine the normal flow of code execution.
Solution Isolate all special checks and edge cases into separate clauses and place them before the main checks. Ideally, you should have a "flat" list of conditionals, one after the other.
In regards to the first tip, I find myself falling into the trap of if/elsing though a list of cases just to determine what to do next, or what state to alter. Unfortunately, a lot of Python libraries are guilty of this practice. Replacing each of the cases with concrete subclasses would definitely help developers keep track of the various code paths, all while making the code cleaner.
In keeping with the second tip, one of my favorite features of Swift is its Guard statement. It keeps the normal execution logic clean, while still allowing the developer to handle rare, or extraordinary cases easily.
Earlier this week I wrote up a simple script to strip out links in log files and add them to an RSS feed. Up till now I've been having it monitor a few IRC channels and pull out the links in real-time, but I have an idea to use this script as a sort of "instant link blogging" tool which I'll hopefully get going really soon.
The script can parse most generic log formats, but by default it only parses Textual's logs. Currently the script has to be rerun to check for changes, but that's going to be fixed (hopefully right after this post goes up).
Check it out. It's hosted, as usual, on GitHub →
13 years later, it’s amazing how much we’ve grown. According to a study by CloudHarmony, Linode is the 4th largest cloud provider to the top 10,000 Alexa websites, following only Amazon, Rackspace, and IBM. Not bad. We have helped over half a million customers, launched nearly 12 million Linode servers, and now have more than 100 employees, all while remaining independent and privately owned.
I've been using Linode as my host of choice for a few years now, and I have absolutely no complaints. They've been great to me.
As a token of our gratitude, we’re announcing free RAM upgrades for both new and existing customers.
It's a non-trivial upgrade; even though I only use the cheapest instances, I'm still getting 100% more RAM.
Editing is difficult; especially difficult when it's your own work. Professional writers will often advise reading your writing aloud. This helps you find errors with narrative flow, voice, and sentence structure, but I'm usually writing in public (i.e. at a coffee shop), so that's not normally an option.
Siri is a great editing tool, and now I can't imagine writing a post with out it. When a blog post is in the editing phase, I'll plug in some headphones and listen to Siri read the post to me. The first time I'll listen intently, and fix glaring flaws. Each time afterward, I listen less and less attentively, only fixing what pops out at me. Sometimes I'll even go for a walk while I listen. Being outside and moving around seems to help me untangle particularly pesky prose.
Hearing your wording aloud and with someone else's voice, inflection, and tone can really help you fine tune things like punctuation, voice, and structure. Generally, with Siri, my writing is better, clearer, cleaner, and more concise.
2 This post is partially inspired by Jesse Jiryu Davis's excellent talk at PyCon 2016.