My FeedDiscussionsHeadless CMS
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more
"Clean Code" book summary, Part 2-a: Functions

"Clean Code" book summary, Part 2-a: Functions

Amir Anwar's photo
Amir Anwar
·Feb 5, 2017

As a continuation to my previous post This is the second part, and I believe is a very important part of the book, talking about functions or methods, this is a long part so I divided it into two subparts, this is the first one....Hope you find it useful...

Functions (Methods):

  • Functions should be small; one line, two-three or four maximum.
  • This means that if satatements, for loops and while loops, should be one line long, obviously this line should be calling another function.
  • For switch statements, every case should have one line, usualy a call to another function.
  • Indentation level in functions should not be bigger than one or two levels.
  • Functions should do one thing only, not to make multiple things, and that should be reflected on their names, e.g., don't make a saveAndCloseDiaolg() function, instead, make two functions: save(), and closeDialog().

    Functions should do only one thing

  • In the same context, they shouldn't have side effects, meaning, they should not lead to another part or initialize another thing etc.. e.g. the save() function should only do the saving part, it should never do anything else.
  • Function mames should be descriptive, don't be afraid to make them very long as long as they are descriptive.

    You know you are working on clean code when each routine turns out to be pretty much what you expected, ward's principle

  • Be consistent in naming the functions, meaning, don't makeincludeName(), addAdress(), instead: includeName(), includeAdress(), Or, addName(), addAdress().
  • Code should be like telling a story, can be read as a top down narrative, every function leading to the next one smoothly .
  • In other words: Every function should have one level of abstraction, the other level should be in another function that follows the first one, like in the following narration: To include the setups and teardowns, we include setups, then we include the test page content, and then we include the teardowns. To include the setups, we include the suite setup if this is a suite, then we include the regular setup. To include the suite setup, we search the parent hierarchy for the SuiteSetUp page and add an include statement with the path of that page. To search the parent. .

       private void includeSetupAndTeardownPages() throws Exception {
      private void includeSetupPages() throws Exception {
                  if (isSuite){
      private void includeSuiteSetupPage() throws Exception {
                  include(SuiteResponder.SUITE_SETUP_NAME, "-setup");  
    private void includeSetupPage() throws Exception {
              include("SetUp", "-setup");  

.... and so on

Continue to part 2-b