Clean Code Chapter 3: Functions

Uncle Bob begins the chapter with a code segment. In terms of clean code, the sample code is a poor example. The code block is lengthy. But it is not a single issue. Uncle Bob gives us a quick receipt to improve the code. First and above all, divide functions. That’s similar to first aid. It’s not enough to live, but it’s a start.

Let’s try something new in this article and start with a list of things not to do. Too many input parameters, duplicate code, long function code lines, unusual data types, and nested if and switch statements. In the previous two articles, it was always said that “anyone needs to look at a code block that can quickly explain themselves.” And the author provides a minute to be how much?

“Do you understand the function after 3 minutes of study? “

This is a good time. Because it forces us to create a clear, small, and meaningful function. We’ve heard that functions should be no larger than a full screen. It’s a nice sound. But the advice is outdated. Sizes for screens vary widely. So, it’s not the most effective advice.

Let’s begin with Book advice.

SMALL!

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify “ Make the smallest you can do. A function should not have two business rules and should only produce one result. Each function should tell a story and serve a purpose: Do something or respond to the caller code. In the previous article (Clean Code Chapter 2: Meaningful Names) we asked four questions to learn about the story.

Blocks and Indenting

“ This implies that the blocks within if statements, else statements, while statements, and so on should be one line long. Probably that line should be a function call. “ Blocks and indentings are typically used to open a new business. There should be a function if there is a business. As a result, when using blocks and intending to use them, they should be one line: call a function or make an assignment. Not more. “Therefore, the indent level of a function should not be greater than one or two. This, of course, makes the functions easier to read and understand ”

“FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY”

DO ONE THING, JUST DO ONE THING !!! Repeat a few times :) Because it is so important. Do one thing and KISS (keep it simple, stupid) principle, and after that give a specific name. If you complete these steps, you have completed the difficult part.

“If a function does only those steps that are one level below the stated name of the function, then the function is doing one thing.” If a function does one thing that helps other clean code principles like small, define a clear, descriptive name, testable functions, and so on…

“Another way to know that a function is doing more than “one thing” is if you can extract another function from it with a name that is not merely a restatement of its implementation “

Reading Code from Top to Bottom: The Stepdown Rule

The step-down rule relates to the order of functions. We begin with the first line of a function and go down the bottom rows, line by line. If we go from basics to specifics, the brain can understand all steps and read them while scrolling. It will be organized like a book. Previously blocks supply coming from behind code blocks.

Use Descriptive Names

“Small” function is our first subtitle. When we achieve that, a lot of clean code concepts are resolved. When a function is small-> it will focus on a job-> and it will be easy to define and give descriptive names. Making a short or long name is not important. There is only one rule. It should be descriptive, understandable, and clear. Don’t be afraid to spend time if it’s necessary. It is deserving of it. “Don’t be afraid to spend time choosing a name. It’ll take time, but save more than take. Be consistent in your names. Use the same phrases, nouns, and verbs in the function names you choose for your module.”

Function Arguments

There is a mostly tell “argument counts aren’t more than three or five”. That’s how I also learned. However, Uncle Bob says that no argument is the best.

“The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification — and then shouldn’t be used anyway.”

Think about a small function with a descriptive name and no arguments. That sound is very simple. It will be too simple to read this function when need to. Reading code is enjoyable and time-saving.

Arguments count is important to test cases too. Every argument can be controlled by tests. “Arguments are even harder from a testing point of view. Imagine the difficulty of writing all the test cases to ensure that all the various combinations of arguments work properly.”

“Flag Arguments are ugly” It is a bad practice to send arguments to decision. It goes against the “one function, one thing” principle. Because Different jobs are made by the flag function.

If arguments are necessary, think argument objects. it will help to make sense of the variables. “Reducing the number of arguments by creating objects out of them may seem like cheating, but it’s not. When groups of variables are passed together, the way x and y are in the example above, they are likely part of a concept that deserves a name of its Own”

Functions should have no side effects. Functions only do one thing. The function body serves only one purpose. When the Body includes another business, it creates a weakness.

“Functions should either do something or answer something, but not both. Either your function should change the state of an object, or it should return some information about that object. Doing both often leads to confusion” Separate commands will help to reduce complexity.

Don’t Repeat Yourself

“Duplication may be the root of all evil in software. Many principles and practices have been created for the purpose of controlling or eliminating it.” Code duplication causes far too many problems. Code management, testing, refactoring, and wide side effects

How Do You Write Functions Like This?

“When I write functions, they come out long and complicated. They have lots of indenting and nested loops. They have long argument lists. The names are arbitrary, and there is duplicated code. But I also have a suite of unit tests that cover every one of those clumsy lines of code. So then I massage and refine that code, splitting out functions, changing names, eliminating duplication. I shrink the methods and reorder them. Sometimes I break out whole classes, all the while keeping the tests passing. In the end, I wind up with functions that follow the rules I’ve laid down in this chapter. I don’t write them that way to start. I don’t think anyone could.” That is a good road map for writing functions.

Conclusion

“Writing software is like any other kind of writing. When you write a paper or an article, you get your thoughts down first, then you massage it until it reads well. The first draft might be clumsy and disorganized, so you wordsmith it and restructure it and refine it until it reads the way you want it to read.”

Writing code is similar to creating a work of art. It is necessary to work carefully and gradually. The most important steps in the building project are the functions. When you properly prepare these steps, you have completed a large part of the work. This unit is an excellent resource for creating a masterpiece of art.

This is a collection of my notes and comments from the book “Clean Code: A Handbook of Agile Software Craftsmanship.”