Do not Repeat Yourself (Coding in style in 60 secs)

Get smart by being stupid

Do you know why programming is the best job ever? From the thousands and thousands of possible jobs out there, programming is the most awesome one. Why? Simple. Because it is the only job when you feel smart when you are stupid.

Have you ever written a simple code that was so simple that any kid could have written it and yet that was not working? No amount of swearing punches to the table or to the keyboard made it work.

And after hours and hours of investigating you found a comma or a bracket missing. What did you do at that moment? Honestly?!?

First, you felt like the king of the world! The smartest programmer on the planet to have done the stupidity in the first place but then being so smart that you were able to fix it. Didn't you also tell everybody about it? 'Look how stupid I was but the how smart I am for having found a solution to it.'

Does it sound familiar?

What does this have to do with Coding in style? Well, awesome code lives on a foundation of many stupid mistakes and especially of the pain you went through fixing them!

That’s it for today!

How to give a great talk

1. Share just one idea

2. Give people a reason to care about it

3. Build your idea using pieces the audience understands

4. Make your idea worth sharing

Capitalization (Coding in style in 60 seconds)

Welcome to “Coding in Style in 60 seconds”, a collection of short videos about how we can improve our code in simple steps. This is Dragos, the speaker for this video.

Do you have any idea what is the first reason for which the code is discarded? Of course, other than the fact that it is not working. Eh? Because it is ugly!!!

Who likes to keep ugly things around? We like to live in a beautiful house, drive a beautiful car and marry a beautiful woman or a handsome guy. But I digress.

One of the fundamental pieces of the code is a variable. So we need to make it beautiful.

To start with, decide on the capitalization. For example, in Swift, the most common one is lower camel case. That is: start the name of the variable with a lower letter and capitalize each of the next words in the name if any.

Let’s take a look at few examples.

var clientName = "john"
var cityOfBirth = "Toronto"
var numberOfSecondsInAMinute = 60

In this example, all the variables are nicely formatted, with first word starting with a lower letter and the next ones with a capital.

Here is another example, not that good this time.

var first_name = "ugly name"
var FirstName = "this is a class name"
var firstNAME = "another ugly name"

The first variable has an underscore, the second one has both words capitalized and the last is a mess.

Let’s talk a bit about constants. A constant is a variable that does not vary so we can use the same rules. With just one addition. To differentiate a constant from a variable, we can start its name with a k.

Here is a good example.

let kClientName = "john"
let kCityOfBirth = "Toronto"
let kNumberOfSecondsInAMinute = 60

And here is a messy one.

let CLIENT_NAME = "john"
let CITY_OF_BIRTH = "Toronto"
let NUMBER_OF_SECONDS_IN_A_MINUTE = 60

Coding in Style in 60 seconds - Lesson 1 - Make The Code Pretty

Coding in Style in 60 seconds

We are starting a new initiative to promote beautiful coding: "Coding in style in 60 seconds", a collection of short videos.

Each video will present a small topic that can have a great impact on the code quality.

You can receive the video by email by subscribing to the blog: http://blog.adelante.ca/ or see them on Facebook at https://www.facebook.com/adelanteconsultinginc/

You want the code clearer? Add useless conditionals

Imagine this situation:

You have a shopping cart and after a product is ordered, its status can be Approved, Declined or Not Available.

If the product is not available, you want to do some processing and then display a message depending if it is declined or not available.

The code looks like this:

 if ([product isNotAvalable] || [product isDeclined]) {

  //some common functionality

  if ([product isNotAvalable]) {                    

    //do something

  } else {

    //do something else

  }

}

Nothing wrong with this code. For the second if, it is obvious that "do something else" is happening when the product is declined.

What if a developer looks only to this piece of code:

  if ([product isNotAvalable]) {                    

    //do something

  } else {

    //do something else

  }

There is a big chance that he will understand that "do something else" is happening when the product is not "not available" that is when the product is available, that is Approved.

To prevent this, we can add a useless conditional like the following:

 if ([product isNotAvalable] || [product isDeclined]) {

  //some common functionality

  if ([product isNotAvalable]) {                    

    //do something

  } else if ([product isDeclined]) {

    //do something else

  }

}

Useless? True!

But very useful ;)

(Image credit)