Friday, August 4, 2017

Clean Code

At work we have been reading and discussing as an engineering department. While I don't agree with everything there are definite aspects of it that I have found extremely helpful when looking at old/legacy code. I would like discuss a few of the points that were most helpful.

1. Naming variables
This is sooo crucial. I have found, no joke, variables called 'a' or 'b' in code. Let me tell you that this is the most annoying thing. Because now I have to spend 30 to 45 minutes (if i'm lucky) trying to find out what the variables are supposed to be. This is especially annoying with parameter variables.
I found it most helpful to pull someone over and ask them if they know what the variables are supposed to represent. That way I get the opinion of someone who has know idea what the code is actually supposed to do. I also found it helpful to refactor after I finish writing the function or segment of code to make sure the variables store what they are supposed to store.

2. Functions doing just one thing and naming functions
You would not believe how helpful this is. I was recently working in a language called cold fusion and I kid you not there was a function not a class that basically was an API. That is hopefully an extreme example but none the less having your function do just one thing is super helpful for testing, refactoring and using the function itself. One of the things this does is keep your parameter list down which makes usage significantly easier to navigate. The naming of functions is also something you should keep in mind when righting clean code. make sure your function is named what it is doing

3. Abstract out all the things
You should put things where they go and avoid clumping.What I mean by that is making sure you have your back end code separate from your front end code and connect them with your API's. If you follow number 2 this should be pretty easy to follow. if you do this your code will be the easiest to maintain and to refactor later on.

4. refactor often and make sure your code is covered with tests (of some sort)
The reason i put these together is if you don't have the tests then you will not be able to refactor with confidence. Refactoring often will help you avoid potential issues. This is how you convert legacy code to clean code. So if you don't have tests already write them, then start the refactor process. I would suggest starting this sooner rather than later because of the potential technical debt that you could be accruing.

So these points and this book more refer to software developers when stating the various points and as it is true that these points do refer mostly to developers I have found some of the dirtiest code written by SQA for automation tests. So I implore ANYONE who writes code to make sure that you write clean code.

1 comment :