The Ethics of Coding – The Basics

Written by wyncode on 28th June 2014, 5:26 PM

Writing code can be both a fun and frustrating process; often at the same time. Nights spent debugging, only to find the simplest of errors was made, feels invigorating and exhausting. When writing code, we often forget about the ethical code we should be adhering to. The following is a list of ethical considerations when coding.

Ethic #1: Re-use

You may know what your program is intended to do, but will anyone who reads your lines of code? Furthermore, do others need to use part or all of what you’ve written in their code? Here is where the ethic of re-use comes in. Writing your code in such a way that it is both simple and functional is an art. This is a balance between code readability and fewest lines possible. Adding additional comments can also help other coders understand and re-use your code.

Ethic #2: Not stealing

Learning about a particular technique by examining code is fine. Even borrowing a function can be fine if it is referenced. However, claiming an entire program or portion of a program as your own can be dangerous. The program may work for now, but what happens when it stops working? Will you be able to debug what you don’t understand. Furthermore, will you be able to expand on what you don’t understand. Stealing is wrong for multiple reasons, including ability to use the code to its full potential.

Ethic #3: Fancy footing

Programmers want to know more new stuff; more techniques and new languages. However, some programmers want to show off or use these talents when the occasion does not call for it. This leads to one of two downfalls. Either no one knows the solution you are really coding for, or you over code for the solution (which can mean more bugs or potential bugs). It is best to keep you coding as simple and effective as possible.

Ethic #4: Wrong tool for the job
While it is possible to use that web tool for a Windows machine, it may not be the best tool. This means that when you need to expand code, you find yourself “painted into the corner”. The same rings true for using a tool meant for rapid development on a process sensitive area. You can shrink down what that rapid development tool is doing, but why not start off correctly?