Sh*t Code to Clean Code

Abdurrafi Arief
4 min readApr 6, 2021
Source: WTF per Minute — commadot.com

Do you ever look at a colleague’s code and think “WTF is this?” like the image above?

Have you ever wanted to continue someone else’s code and just couldn’t because you didn’t understand the sh*t written?

Have you ever had your code reviewed and your colleagues said the code you written was sh*t?

Well then, have I got some tips for you. After reading this article, I hope the code you write isn’t sh*t anymore.

Clean code is important so that the scenarios above do not happen. It also can brighten up a programmers day because clean code is satisfying to look at.

First tip: Proper variable and function naming

Maybe during the newbie days, there were a lot of variables named “a”, “b”, and “temp”. Maybe there were also functions named “function”. Well, it’s time to leave that habit behind and give them proper names.

Here is an example of bad naming:

String? a;
String b = 'File Name';
File? c;
bool function() {
return a != null && b != "File Name"
&& c != null;
}

Here is an example of good naming:

String? _attachmentType;
String _attachmentName = 'File Name';
File? _attachmentItem;
bool _valuesAreNotEmpty() {
return _attachmentType != null && _attachmentName != "File Name"
&& _attachmentItem != null;
}

In the first example it isn’t obvious what a, b, and c is. And it also isn’t obvious what the function does at first glance. But in the second example, it becomes clear what the function does and what the variables are storing.

Second tip: Organized Layout Formatting

An annoying thing to read would be a long line of code or a big wall of text(code) that is incomprehensible. With an organized layout, the code would look aesthetically pleasing and the amount of WTFs thrown are bound to decrease.

Example of bad layouting:

Future getImage() async { final pickedFile = await imagePicker.getImage(source: ImageSource.camera);
setState(() { if (pickedFile != null) { _attachmentItem = File(pickedFile.path); initialState = false;}
});
}

Example of good layouting:

Future getImage() async {
final pickedFile = await imagePicker.getImage(source: ImageSource.camera);

setState(() {
if (pickedFile != null) {
_attachmentItem = File(pickedFile.path);
initialState = false;
}
});
}

In the first example, everything is bunched up together making it hard to read. But in the second with proper indenting and newlines it is much easier to read and understand.

Third tip: Efficient Comments

The code you write should be easy to understood without comments. In my opinion, comments on code is like MSG on food. It should be used when it is necessary to give an extra taste/explanation. It shouldn’t be used to cover up bad code (or unseasoned food in MSG’s case). And remember, MSG doesn’t make sh*t taste good.

Example of good comments:

int calculateDiagonalSideTriangle() {
diagonal_side = sqrt(none_diagonal_side_1**2 +
none_diagonal_side_2**2);
return diagonal_side;
}
int veryComplexAlgorithm() {
//This function helps another function to count something
...
return;
}

Example of bad comments:

String? a;
String b = 'File Name';
File? c;
bool function() { //This function of for checking if a,b,and c is empty or not
return a != null && b != "File Name"
&& c != null;
}

In the first example, the function “calculateDiagonalSideTriangle” is very clear in what it does so it doesn’t need comments. While the “veryComplexAlgorithm” (for the sake of example) is a complex algoritm so it might need comments to help explain it.

In the second example, because of the bad naming, it has comments which could have been avoided.

Fourth tip: Error Handling

A user’s behavior is unpredictable. You never know what they do with the software you developed. Which is why it is important to add safety mattresses or “Error Handling” as it is properly called in the necessary places, so your software doesn’t go to sh*t.

Example:

Future getImage() async {
final pickedFile = await imagePicker.getImage(source: ImageSource.camera);

setState(() {
if (pickedFile != null) {
_attachmentItem = File(pickedFile.path);

initialState = false;
}
});
}

There is an if condition to check if a variable is null or not to avoid errors.

Fifth tip: Simple Functions

A function should only do one thing only. It shouldn’t be able to do a lot of sh*t at once. If it does more than one sh*t another person reading it could get confused or when you have to refactor something more effort is necessary. Which is why you should keep functions simple.

Example:

int calculateDiagonalSide() {
diagonal_side = sqrt(none_diagonal_side_1**2 +
none_diagonal_side_2**2);
return diagonal_side;
}

The function “calculateDiagonalSideTriangle” only does one thing which is calculate a diagonal of a triangle.

So after these 5 tips, I hope the code you write isn’t shit code but instead sparkling shining pleasing clean code.

References:

  • Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, Prentice Hall, 2008
  • My own code

--

--