Hi people! Let me continue with our bad code academy. In this post, we will reveal another way to slow down your code reading. The following tricks can help you reduce your understanding of your code and increase the chances of bugs in it. Ready? Let's start.
Line breaks, spaces, and indentation can kill.
How do people read books? Top to bottom, left to right (at least most). The same happens when developers read the code. One line of code should contain one thought, therefore, each line should contain only one command. If you want to embarrass other developers, you'd better violate these guidelines. And let me show you how to do it.
Example # 1
Look at this piece of code. One idea on one line. The code is so clean it makes me sick.
return elements
.Where(element => !element.Disabled)
.OrderBy(element => element.UpdatedAt)
.GroupBy(element => element.Type)
.Select(@group => @group.First());
We can combine all the statements into one line, but that would be too easy. In this case, the developer's brain will understand that something is wrong here, and it will split the operators from left to right. Easy peasy!
It is best to keep some statements on the same line and some to split. The best option is when the developer may not even notice some of the operators, which will lead to misunderstandings and ultimately to an error. Another option is to just slowly reduce his understanding of this code until he cries out, "What the hell is this !?"
return elements.Where(e => !e.Disabled)
.OrderBy(e => e.UpdatedAt).GroupBy(e => e.Type)
.Select(g => g.First());
How do you like that? You can add some indentation so other developers will format your code for decades if they need to rename the elements variable.
return elements.Where(e => !e.Disabled)
.OrderBy(e => e.UpdatedAt).GroupBy(e => e.Type)
.Select(g => g.First());
Send me a postcard if this approach gets code-reviewed by your team.
Tip : Leave a couple of statements on one line and a couple on separate lines.
Example # 2
Absolutely the same idea here. This is the only code you see much more often.
var result =
(condition1 && condition2) ||
condition3 ||
(condition4 && condition5);
The procedure is the same. Separate lines to confuse the reader as much as possible. Play a little with newlines to get the best result.
var result = (condition1 && condition2) || condition3 ||
(condition4 && condition5);
And add some indentation to make the code look normal.
var result = (condition1 && condition2) || condition3 ||
(condition4 && condition5);
Remember, you must strike a balance between the illegibility of your code and the believability of your style.
Tip : play with newlines for best results.
Example # 3
What about this?
if (isValid)
{
_unitOfWork.Save();
return true;
}
else
{
return false;
}
The same problem, but on the other side. Here, the best option would be to combine the operators into one line, of course, by placing curly braces.
if (isValid) { _unitOfWork.Save(); return true; } else { return false; }
This approach will only work if you have few statements in the then and otherwise blocks. Otherwise, your code may be rejected at the code review stage.
Tip : Combine small if / for / foreach statements into one line.
Example # 4
80 characters per line is the current recommended standard. This allows you to keep the developer's concentration as they read your code. What's more, you can have two documents open at the same time on the same screen when needed, leaving you room for the Solution Explorer.
bool IsProductValid(
ComplexProduct complexProduct,
bool hasAllRequiredElements,
ValidationSettings validationSettings)
{
// code
}
The easiest way to slow down the reading of your code is by forcing other developers to scroll your code horizontally. Just ignore the 80 character rule.
bool IsProductValid(ComplexProduct complexProduct, bool hasAllRequiredElements, ValidationSettings validationSettings)
{
// code
}
It's super easy: forget what happened before you started scrolling, or skip the line you started on. Great trick.
Tip : On purpose, ignore the 80 character rule.
Example # 5 A
blank line in the right place is a powerful tool for grouping your code and making it read faster.
ValidateAndThrow(product);
product.UpdatedBy = _currentUser;
product.UpdatedAt = DateTime.UtcNow;
product.DisplayStatus = DisplayStatus.New;
_unitOfWork.Products.Add(product);
_unitOfWork.Save();
return product.Key;
A blank line in the wrong place, combined with the other tips in this article, can help you save your work. Which blank line do you prefer?
ValidateAndThrow(product);
product.UpdatedBy = _currentUser;
product.UpdatedAt = DateTime.UtcNow;
product.DisplayStatus = DisplayStatus.New;
_unitOfWork.Products.Add(product);
_unitOfWork.Save();
return product.Key;
Tip : Insert blank lines randomly.
Example # 6
When you commit to a repository, you have a tiny opportunity to see what exactly you are going to commit. DO NOT DO THAT! It's ok if you add an extra blank line like here.
private Product Get(string key)
{
// code
}
private void Save(Product product)
{
// code
}
Or, even better, added a few spaces on a blank line (to understand the difference, highlight the 5th line).
private Product Get(string key)
{
// code
}
private void Save(Product product)
{
// code
}
Why do you need this? The code continues to work (but it's not certain). You continue to understand your code, but the other developer will understand your code less. You can't just add a few extra whitespace to common methods at once (code reviews are our enemy), but using this practice will create a mess after a couple of weeks of active development.
Another added benefit of using extra spaces in a string is when other developers commit related functionality, their IDE can automatically correct the formatting. At the code review, they will see a thousand red and green lines. If you understand what I mean;)
For the same reason, you can set up tabs in your IDE if you use spaces in your project, and vice versa.
Tip : don't look at the code before committing.
Example # 7
Bypass those developers who may see extra spaces in the code. They are dangerous to your career.
product.Name = model.Name;
product.Price = model.Price;
product.Count = model.Count;
Tip : know your enemy.
It's hard work to make your code unsupported. When you accumulate many small problems, they grow without your participation. Young developers will write their code according to your templates. One day during the code review, you will hear "What the hell?" from your team lead, and here you will be able to use the catchphrase: “What? We always do this, ”and show him a thousand places in the code where it is written in the same way.
Have fun.