“Good Code Documents Itself” And Other Hilarious Jokes You Shouldn’t Tell Yourself

Code documentation — is there anything more exciting than spending your time writing extensive comments? If I had to guess, your answer is probably somewhere along the lines of “uhm, yes, everything is more exciting than that”. Plus, requesting to document your code is almost like an insult to your well thought out design, this beautiful creation you implemented so carefully that it just has to be obvious what is happening. Writing about it is just redundant, the code is all you need.

As a result, no matter if it’s some open source side project or professional software development, code documentation usually comes in two flavors: absent and useless. The dislike for documenting ones code seems universal among programmers of any field or language, no matter where in the world they are. And it’s understandable, after all, you’re in it for the coding, implementing all the fun stuff. If you wanted to tell stories, you would have chosen a different path in life.

This reluctance has even formed whole new paradigms and philosophies claiming how comments are actually harmful, and anyone trying to weasel their way out of it can now happily rehash all those claims. But, to exaggerate a bit, we’re essentially villainizing information this way. While it is true that comments can be counterproductive, it’s more the fundamental attitude towards them that causes the harm here.

In the end, code documentation is a lot like error handling, we are told early on how it’s important and necessary, but we fail to understand why and instead grow to resent doing it again for that same old teacher, supervisor, or annoying teammate. But just like error handling, we are the ones who can actually benefit the most from it — if done right. But in order to do it right, we need to face some harsh truths and start admitting that there is no such thing as self-documenting code, and maybe we simply don’t understand what we’re actually doing if we can’t manage to write a few words about it.

So let’s burst some bubbles!

Continue reading ““Good Code Documents Itself” And Other Hilarious Jokes You Shouldn’t Tell Yourself”

From Software to Tindie Hack Chat with Brian Lough

Join us Wednesday at noon Pacific time for the From Software to Tindie Hack Chat!

Brian Lough has followed a roundabout but probably not unusual route to the hardware hacking scene. Educated in Electronic and Computer Engineering, Brian is a software developer by trade who became enamored of Arduino development when the ESP8266 hit the market. He realized the microcontrollers such as these offered incredible capabilities on the cheap, and the bug bit him.

Since then, Brian has fully embraced the hardware hacking way, going so far as to live stream complete builds in a sort of collaborative “hack-along” with his viewers. He’s also turned a few of his builds into legitimate products, selling them on his Tindie store and even going so far as to automate testing before shipping to catch errors and improve quality.

Please join us for this Hack Chat, where we’ll discuss:

  • How software hacking leads to hardware hacking;
  • The creative process and how live streaming helps or hinders it;
  • The implications of going from project to product; and
  • What sorts of new projects might we see soon?

Continue reading “From Software to Tindie Hack Chat with Brian Lough”

Crash your code – Lessons Learned From Debugging Things That Should Never Happen™

Let’s be honest, no one likes to see their program crash. It’s a clear sign that something is wrong with our code, and that’s a truth we don’t like to see. We try our best to avoid such a situation, and we’ve seen how compiler warnings and other static code analysis tools can help us to detect and prevent possible flaws in our code, which could otherwise lead to its demise. But what if I told you that crashing your program is actually a great way to improve its overall quality? Now, this obviously sounds a bit counterintuitive, after all we are talking about preventing our code from misbehaving, so why would we want to purposely break it?

Wandering around in an environment of ones and zeroes makes it easy to forget that reality is usually a lot less black and white. Yes, a program crash is bad — it hurts the ego, makes us look bad, and most of all, it is simply annoying. But is it really the worst that could happen? What if, say, some bad pointer handling doesn’t cause an instant segmentation fault, but instead happily introduces some garbage data to the system, widely opening the gates to virtually any outcome imaginable, from minor glitches to severe security vulnerabilities. Is this really a better option? And it doesn’t have to be pointers, or anything of C’s shortcomings in particular, we can end up with invalid data and unforeseen scenarios in virtually any language.

It doesn’t matter how often we hear that every piece of software is too complex to ever fully understand it, or how everything that can go wrong will go wrong. We are fully aware of all the wisdom and cliches, and completely ignore them or weasel our way out of it every time we put a /* this should never happen */ comment in our code.

So today, we are going to look into our options to deal with such unanticipated situations, how we can utilize a deliberate crash to improve our code in the future, and why the average error message is mostly useless.

Continue reading “Crash your code – Lessons Learned From Debugging Things That Should Never Happen™”

A Cheat Sheet For Publishing Python Packages

[Brendan Herger] was warned that the process of publishing a Python package would be challenging. He relishes a challenge, however, and so he went at it with gusto. The exhausting process led him to share a cheat sheet for publishing Python packages with the goal of making the next time smoother, while also letting other people benefit from his experience and get a running start.

[Brendan] describes publishing a Python package as “tying together many different solutions with brittle interchanges.” His cheat sheet takes the form of an ordered workflow for getting everything in place, with some important decisions and suggestions about things like formatting and continuous integration (CI) made up-front.

The guide is brief, but [Brendan] has made errors and hit dead ends in the hopes that others won’t have to. The whole thing came about from his work in deep learning, and his desire to create a package that allows rapid building and iterating on deep learning models.

Deep learning is a type of machine learning that involves finding representations in large amounts of data. [Brendan] used it in a project to automatically decide whether a Reddit post contains Star Wars plot spoilers, and we recently saw it featured in a method of capturing video footage only if a hummingbird is present.

Warnings On Steroids – Static Code Analysis Tools

A little while back, we were talking about utilizing compiler warnings as first step to make our C code less error-prone and increase its general stability and quality. We know now that the C compiler itself can help us here, but we also saw that there’s a limit to it. While it warns us about the most obvious mistakes and suspicious code constructs, it will leave us hanging when things get a bit more complex.

But once again, that doesn’t mean compiler warnings are useless, we simply need to see them for what they are: a first step. So today we are going to take the next step, and have a look at some other common static code analysis tools that can give us more insight about our code.

You may think that voluntarily choosing C as primary language in this day and age might seem nostalgic or anachronistic, but preach and oxidate all you want: C won’t be going anywhere. So let’s make use of the tools we have available that help us write better code, and to defy the pitfalls C is infamous for. And the general concept of static code analysis is universal. After all, many times a bug or other issue isn’t necessarily caused by the language, but rather some general flaw in the code’s logic.

Continue reading “Warnings On Steroids – Static Code Analysis Tools”

Warnings Are Your Friend – A Code Quality Primer

If there’s one thing C is known and (in)famous for, it’s the ease of shooting yourself in the foot with it. And there’s indeed no denying that the freedom C offers comes with the price of making it our own responsibility to tame and keep the language under control. On the bright side, since the language’s flaws are so well known, we have a wide selection of tools available that help us to eliminate the most common problems and blunders that could come back to bite us further down the road. The catch is, we have to really want it ourselves, and actively listen to what the tools have to say.

We often look at this from a security point of view and focus on exploitable vulnerabilities, which you may not see as valid threat or something you need to worry about in your project. And you are probably right with that, not every flaw in your code will lead to attackers taking over your network or burning down your house, the far more likely consequences are a lot more mundane and boring. But that doesn’t mean you shouldn’t care about them.

Buggy, unreliable software is the number one cause for violence against computers, and whether you like it or not, people will judge you by your code quality. Just because Linus Torvalds wants to get off Santa’s naughty list, doesn’t mean the technical field will suddenly become less critical or loses its hostility, and in a time where it’s never been easier to share your work with the world, reliable, high quality code will prevail and make you stand out from the masses.

Continue reading “Warnings Are Your Friend – A Code Quality Primer”

Code Review Lamp Subtly Reminds You To Help Your Fellow Developer

[Dimitris Platis] works in an environment with a peer review process for accepting code changes. Code reviews generally are a good thing. One downside though, is that a lack of responsiveness from other developers can result in a big hit to team’s development speed. It isn’t that other developers are unwilling to do the reviews, it’s more that individuals are often absorbed in their own work and notification emails are easily missed. There is also a bit of a “tragedy of the commons” vibe to the situation, where it’s easy to feel that someone else will surely attend to the situation, but often no one does. To combat this, [Dimitris] built this Code Review Lamp, a subtle notification that aims to prod reviewers into action.

The lamp is based on a ring of RGB LEDs and a Wemos D1 Mini board. The Wemos utilizes the popular ESP8266, so it’s easy to develop for. The LED ring and Wemos are tied together with a slick custom PCB. Mounting the LED ring on the top of the PCB and the Wemos on the bottom allows for easy powering via a USB cable while directing light upward.  The assembly is placed in a translucent 3D printed enclosure creating a pleasant diffuse light source.

Every developer gets a Code Review Lamp. The lamps automatically log in to the change management system to check whether anything is awaiting review. If a review is ready, the Lamp glows in a color specific to the individual developer. All this serves as a gentle but persistent reminder that someone’s work is being held up until a review is completed.

We love the way that the device has a clear purpose: it does its job without any unnecessary features or parts. It’s similar to this ESP8266 IoT Motion Sensor in that it has a single job to do, and focuses on it well.

Continue reading “Code Review Lamp Subtly Reminds You To Help Your Fellow Developer”