Techno Blender
Digitally Yours.

How to Find the Stinky Parts of Your Code [Part XX]: We have Reached 100!

0 65


20 stories with 5 code smells each are 100 code smells, right?


Previous Code Smells

Let’s continue…


You don’t own objects.

TL;DR: don’t use my as a name prefix.

  • Lack of context
  • Bijection Fault
  1. Remove my prefix.
  2. Change to a role suggesting name.

Several old tutorials use the word ‘my’ as a lazy name.
This is vague and lead to context mistakes.

Wrong

MainWindow myWindow = Application.Current.MainWindow as MainWindow;

Right

MainWindow salesWindow = Application.Current.MainWindow as MainWindow;

/*

Since window is instanciated, we are currently working
with a specialized window playing a special role

*/

We can tell our linters and static checkers to search for this prefix and warn us.

Avoid using my. Objects change according to the usage context.

Photo by Michał Bożek on Unsplash


Thinking about my experience of modifying code, I see that I spend much more time reading the existing code than I do writing new code. If I want to make my code cheap, therefore, I should make it easy to read.

Kent Beck

Software Engineering Great Quotes


image

We should take special care with error descriptions for the users (and ourselves).

TL;DR: Use meaningful descriptions and suggest corrective actions.

  • The Least Surprise Principle
  1. Use declarative error messages
  2. Show clear exit actions

Programmers are seldom UX experts.

We also underestimate the fact we can be on both sides of the counter.

Wrong

alert("Cancel the appointment?", "Yes", "No");

// No consequences
// Options not clear

Right

alert("Cancel the appointment? \n" +
      "You will lose all the history", 
      "Cancel Appointment", 
      "Keep Editing");

// Consequences are clear
// Choice options have context

We need to read all exception messages in code reviews.

We need to think in our end users when raising exception or showing messages.

Photo by visuals on Unsplash


While it is a known fact that programmers never make mistakes, it is still a good idea to humor the users by checking for errors at critical points in your program.

Robert D. Schneider


image

Spelling and readability are very important for humans and not important for machines.

TL;DR: Take care of your names.

  • Readability
  • Harder to search terms in code.
  1. Spellcheck your code.
  2. Use an IDE with spellchecking

Many of us don’t speak English as our first language.

We need to have extra care for our texts and names.

This article has a typo in its title as proof of context and also a clickbait😀

Wrong

comboFeededBySupplyer = supplyer.providers();

Right

comboFedBySupplier = supplier.providers();
  • Readability
  • Naming
  • Code Styling

Pay close attention to your names.

You will probably be the person reading the code in a few months.

Code Smell 48 – Code Without Standards

What exactly is a name — Part I The Quest

What exactly is a name — Part II Rehab

Photo by Brett Jordan on Unsplash

Inside every well-written large program is a well-written small program.

C.A.R. Hoare


image

How many times do we see lazy argument names?

TL;DR: Name your arguments according to the role and not the accidental position

  • Readability
  • Intention Revealing Names
  1. Use meaningful names

When writing methods, we usually don’t stop to find decent names.

We never refactor the obvious, neither.

Wrong

class Calculator:
  def subtract(self, first, second):
    return first - second

class CalculatorTest  
  def test_multiply():
    assert equals(first, second)

Right

class Calculator:
  def subtract(self, minuend, subtrahend):
    return minuend - subtrahend

class CalculatorTest  
  def test_multiply():
    assert equals(expectedValue, realValue)

We can warn for forbidden words like ‘first’ and ‘second’ as argument names.

Always follow rule suggesting parameter.

Name your collaborators according to the role.

Code Smell 65 – Variables Named after Types

What exactly is a name — Part II Rehab

Photo by Priscilla Du Preez on Unsplash


Final source code is the real software design.

Jack Reeves


image

GOTO was considered harmful 50 years ago

TL;DR: Don’t ever use GoTo.

  • Readability
  • Hard to follow code
  1. Replace GOTO with structured code
  2. Use exceptions

I started programming in Basic.

GOTO was heavily abused there.

I had to learn structured programming from scratch in Rehab mode.

Wrong

for x < 0 {
    if x > -1e-09 {
      goto small
    }
    z = z / x
    x = x + 1
  }
  for x < 2 {
    if x < 1e-09 {
      goto small
    }
    z = z / x
    x = x + 1
  }

  if x == 2 {
    return z
  }

  x = x - 2
  p = (((((x*_gamP[0]+_gamP[1])*x+_gamP[2])*x+_gamP[3])*x+_gamP[4])*x+_gamP[5])*x + _gamP[6]
  q = ((((((x*_gamQ[0]+_gamQ[1])*x+_gamQ[2])*x+_gamQ[3])*x+_gamQ[4])*x+_gamQ[5])*x+_gamQ[6])*x + _gamQ[7]
  return z * p / q

small:
  if x == 0 {
    return Inf(1)
  }
  return z / ((1 + Euler*x) * x)
}

Right

for x < 0 {
    if x > -1e-09 {
      return small(x, z)
    }
    z = z / x
    x = x + 1
  }
  for x < 2 {
    if x < 1e-09 {
      return small(x, z)
    }
    z = z / x
    x = x + 1
  }

  if x == 2 {
    return z
  }

  x = x - 2
  p = (((((x*_gamP[0]+_gamP[1])*x+_gamP[2])*x+_gamP[3])*x+_gamP[4])*x+_gamP[5])*x + _gamP[6]
  q = ((((((x*_gamQ[0]+_gamQ[1])*x+_gamQ[2])*x+_gamQ[3])*x+_gamQ[4])*x+_gamQ[5])*x+_gamQ[6])*x + _gamQ[7]
  return z * p / q

small(x, z) {
  if x == 0 {
     return Inf(1)
   }
   return z / ((1 + Euler*x) * x)
 }
}

In languages supporting GOTO, our linters can warn us against its usage.

We acknowledged GOTO problems a few decades ago.

The problem is still present in modern languages like GoLang, PHP, Perl etc.

Most programmers luckily avoid GOTO sentence. Next goal will be to consider harmful null usage.

image

Courtesy XKCD

Code Smell 12 – Null

Photo by Jens Johnsson on Unsplash


It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

Edsger Dijkstra

Software Engineering Great Quotes


And that’s all for now, We have hit 100 milestone.

The next article will explain 5 more code smells!

L O A D I N G
. . . comments & more!


20 stories with 5 code smells each are 100 code smells, right?


Previous Code Smells

Let’s continue…


image

You don’t own objects.

TL;DR: don’t use my as a name prefix.

  • Lack of context
  • Bijection Fault
  1. Remove my prefix.
  2. Change to a role suggesting name.

Several old tutorials use the word ‘my’ as a lazy name.
This is vague and lead to context mistakes.

Wrong

MainWindow myWindow = Application.Current.MainWindow as MainWindow;

Right

MainWindow salesWindow = Application.Current.MainWindow as MainWindow;

/*

Since window is instanciated, we are currently working
with a specialized window playing a special role

*/

We can tell our linters and static checkers to search for this prefix and warn us.

Avoid using my. Objects change according to the usage context.

Photo by Michał Bożek on Unsplash


Thinking about my experience of modifying code, I see that I spend much more time reading the existing code than I do writing new code. If I want to make my code cheap, therefore, I should make it easy to read.

Kent Beck

Software Engineering Great Quotes


image

We should take special care with error descriptions for the users (and ourselves).

TL;DR: Use meaningful descriptions and suggest corrective actions.

  • The Least Surprise Principle
  1. Use declarative error messages
  2. Show clear exit actions

Programmers are seldom UX experts.

We also underestimate the fact we can be on both sides of the counter.

Wrong

alert("Cancel the appointment?", "Yes", "No");

// No consequences
// Options not clear

Right

alert("Cancel the appointment? \n" +
      "You will lose all the history", 
      "Cancel Appointment", 
      "Keep Editing");

// Consequences are clear
// Choice options have context

We need to read all exception messages in code reviews.

We need to think in our end users when raising exception or showing messages.

Photo by visuals on Unsplash


While it is a known fact that programmers never make mistakes, it is still a good idea to humor the users by checking for errors at critical points in your program.

Robert D. Schneider


image

Spelling and readability are very important for humans and not important for machines.

TL;DR: Take care of your names.

  • Readability
  • Harder to search terms in code.
  1. Spellcheck your code.
  2. Use an IDE with spellchecking

Many of us don’t speak English as our first language.

We need to have extra care for our texts and names.

This article has a typo in its title as proof of context and also a clickbait😀

Wrong

comboFeededBySupplyer = supplyer.providers();

Right

comboFedBySupplier = supplier.providers();
  • Readability
  • Naming
  • Code Styling

Pay close attention to your names.

You will probably be the person reading the code in a few months.

Code Smell 48 – Code Without Standards

What exactly is a name — Part I The Quest

What exactly is a name — Part II Rehab

Photo by Brett Jordan on Unsplash

Inside every well-written large program is a well-written small program.

C.A.R. Hoare


image

How many times do we see lazy argument names?

TL;DR: Name your arguments according to the role and not the accidental position

  • Readability
  • Intention Revealing Names
  1. Use meaningful names

When writing methods, we usually don’t stop to find decent names.

We never refactor the obvious, neither.

Wrong

class Calculator:
  def subtract(self, first, second):
    return first - second

class CalculatorTest  
  def test_multiply():
    assert equals(first, second)

Right

class Calculator:
  def subtract(self, minuend, subtrahend):
    return minuend - subtrahend

class CalculatorTest  
  def test_multiply():
    assert equals(expectedValue, realValue)

We can warn for forbidden words like ‘first’ and ‘second’ as argument names.

Always follow rule suggesting parameter.

Name your collaborators according to the role.

Code Smell 65 – Variables Named after Types

What exactly is a name — Part II Rehab

Photo by Priscilla Du Preez on Unsplash


Final source code is the real software design.

Jack Reeves


image

GOTO was considered harmful 50 years ago

TL;DR: Don’t ever use GoTo.

  • Readability
  • Hard to follow code
  1. Replace GOTO with structured code
  2. Use exceptions

I started programming in Basic.

GOTO was heavily abused there.

I had to learn structured programming from scratch in Rehab mode.

Wrong

for x < 0 {
    if x > -1e-09 {
      goto small
    }
    z = z / x
    x = x + 1
  }
  for x < 2 {
    if x < 1e-09 {
      goto small
    }
    z = z / x
    x = x + 1
  }

  if x == 2 {
    return z
  }

  x = x - 2
  p = (((((x*_gamP[0]+_gamP[1])*x+_gamP[2])*x+_gamP[3])*x+_gamP[4])*x+_gamP[5])*x + _gamP[6]
  q = ((((((x*_gamQ[0]+_gamQ[1])*x+_gamQ[2])*x+_gamQ[3])*x+_gamQ[4])*x+_gamQ[5])*x+_gamQ[6])*x + _gamQ[7]
  return z * p / q

small:
  if x == 0 {
    return Inf(1)
  }
  return z / ((1 + Euler*x) * x)
}

Right

for x < 0 {
    if x > -1e-09 {
      return small(x, z)
    }
    z = z / x
    x = x + 1
  }
  for x < 2 {
    if x < 1e-09 {
      return small(x, z)
    }
    z = z / x
    x = x + 1
  }

  if x == 2 {
    return z
  }

  x = x - 2
  p = (((((x*_gamP[0]+_gamP[1])*x+_gamP[2])*x+_gamP[3])*x+_gamP[4])*x+_gamP[5])*x + _gamP[6]
  q = ((((((x*_gamQ[0]+_gamQ[1])*x+_gamQ[2])*x+_gamQ[3])*x+_gamQ[4])*x+_gamQ[5])*x+_gamQ[6])*x + _gamQ[7]
  return z * p / q

small(x, z) {
  if x == 0 {
     return Inf(1)
   }
   return z / ((1 + Euler*x) * x)
 }
}

In languages supporting GOTO, our linters can warn us against its usage.

We acknowledged GOTO problems a few decades ago.

The problem is still present in modern languages like GoLang, PHP, Perl etc.

Most programmers luckily avoid GOTO sentence. Next goal will be to consider harmful null usage.

image

Courtesy XKCD

Code Smell 12 – Null

Photo by Jens Johnsson on Unsplash


It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

Edsger Dijkstra

Software Engineering Great Quotes


And that’s all for now, We have hit 100 milestone.

The next article will explain 5 more code smells!

L O A D I N G
. . . comments & more!

FOLLOW US ON GOOGLE NEWS

Read original article here

Denial of responsibility! Techno Blender is an automatic aggregator of the all world’s media. In each content, the hyperlink to the primary source is specified. All trademarks belong to their rightful owners, all materials to their authors. If you are the owner of the content and do not want us to publish your materials, please contact us by email – [email protected]. The content will be deleted within 24 hours.
Leave a comment