Clean Code | Quick Notes

51bPR2V9fBL._SX258_BO1,204,203,200_

A handbook of agile software craftsmanship by Robert C.Martin.

Two reasons for reading this book, you’re a programmer or you want to be. So by the end of this, we’ll know how to write good code because we are going to look code in each and every direction.

There will be a code, some peoples say we are at the end of the code and we don’t need the programmers because business people will generate the program from the specification.  That’s not true because at some level details can’t be ignored so we have to be specified.

It is bad code that brings the company down.

Why do we write the bad code? go fast, in a rush, don’t have to time to think before writing the line of code. One thing we’ve all said we’d go back and clean it up later. But we didn’t know LeBlanc’s Law: Later Equals Never.

The Total Cost of Owning a Mess, we all see teams that were moving fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two, three other parts of the code. As the mess builds, the productivity of the team continues to decrease. Now management adds new developer to increase it but it creates the new mess because the new developers are not aware of current architecture and then together they create more mess.

The Grand Redesign in the Sky, eventually team rebels and they inform management that they cannot continue with the codebase and they demand redesign, Management doesn’t want to expend the resources but they can’t deny because productivity is 0. A new tiger team is selected and everyone wants to be on that team, now they have to develop same what old app is doing also the new changes that are coming in. It takes time but after some time, the developers of tiger team is gone and current developers demand new because it’s mess.

Attitude, Why does this happen to code? we complain that the change in requirements, schedules that were too tight, we blame stupid managers, intolerant customers etc. but the fault is in ourselves we are unprofessional.

The only way to make the deadline, the only way to go fast is to make your code clean as much as possible.

What is Clean Code? there are lots of definition given by different deep experience programmers, here I have mentioned one that I like most.

Bjarne Stroustrup, Inventor of C++. I like my code to be elegant and efficient. The logic should be straightforward to make it harder bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimisations. clean code does one thing well.

Thanks for reading this, here I am also including my point what I like most and I must recommend this book to each and every person who is responsible for writing/reviewing code. For more just buy the book.

Clean Code | Introduction | Quick Notes

51bPR2V9fBL._SX258_BO1,204,203,200_.jpg

A handbook of agile software craftsmanship by Robert C.Martin.

Writing clean code is what you must do in order to call yourself a professional, there is no excuse to do anything less than your best.

In this series of quick notes, I am going to share the quick notes from this book with you, So welcome aboard, let’s start with the introduction.

So think 2 mins, what is the valid measurement of code quality for you? The answer according to the book is funny but its WTFs/minute. haha 🙂 Now you can easily measure the quality of your code.

Next question will be, How to handle bad code? the answer is Craftsmanship. There are two parts of learning Craftsmanship: Knowledge and Work. It means you must gain the knowledge of principles, patterns and best practices and you must also grind the knowledge into your finders, eyes by working hard.

Yes, that’s why this book is divided into three parts.

  1. First will teach you principles, patterns, and best practices.
  2. Second, Case studies of ever-increasing complexity. Here you have to think and give the reason for making each change.
  3. Third, a list of heuristics and smells gathered while creating the case studies.

Thanks for reading this, I am also including what I like most and I must recommend this book to each and every person who is responsible for writing/reviewing code. For more just buy the book.

STUPID principles | Quick Notes

Recent blog: SOLID vs STUPID

STUPID principles and yes this may hurt your feeling but yes if you are following this you are writing stupid code.

Singleton

Well known design pattern, but mostly understood one as well. Like me, people are also fighting with Singleton syndrome. In that case, whenever we create a class we create it Singleton but why? That is definability not cool. Singleton also considered anti-patterns. We should think and avoid if possible because the program using Singleton are hard to test because of global state, with the global state they hide their dependencies.

Tight Coupling

Avoiding static things is important to avoid tight coupling. If it’s there then making a change in one module requires to changes another module too. Now it’s really difficult to reuse and difficult to test.

Untestability

Testing is not hard, what you think? We don’t write test case may be because we don’t have the time or the code we are writing is bad because of tight coupling?

Premature Optimization

One of my favorite quote from Donald Knuth, premature is the root of all evil. There are only cost and no benefits. Actually optimised code is much complex as compared to just writing a loop.

Indescriptive Naming

That’s what I like most and I try to follow as much as possible. Name of your class, variables or methods should be clear because at the end of the day human is only going to read because programming languages are for human not for computers, computers can understand 0 or 1 very well.

Duplication

That’s bad. Writing same code again and again so don’t repeat yourself, keep it simple and strong. Write Code only once.

Thank you for reading the quick introduction of STUPID principles, next will be SOLID principles.

SOLID principle with Swift | STUPID

SOLID principle is an acronym created by Robert C Martin also unknown as Uncle Bob. It represents five principles for OOPS.

Single responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

Now the first thought that came to my mind is Why do we need this? Here is the answer, using these principles we can solve the problems of a bad architecture.

Fragility where A small change may break complete module it’s really very difficult to find this if you don’t have good test cases.

Immobility where A component is very hard to reuse in another project or we can say multiple places in the same project because of too many dependencies.

Rigidity where Single change requires lots of developer efforts because it affects several parts of the project.

Here I want to add principles will not turn a bad programmer into a good programmer you need a better judgment there. Principles have to apply with judgment and you must be smart enough to understand when to apply what.

I have also written one blog where they have mentioned one more acronym like SOLID and it’s STUPID. This may hurt your feeling but yes if you are following this you are writing stupid code.

Singleton
Tight Coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication

Thank you for reading the quick introduction, In next blogs, I will try to define all principles with Swift Code.

Signs of wrong architecture? | Quick Notes

Recently I have got one iOS Application codebase to review and it always gives a thought, where to start?

Here are the 3 important first steps for me that I always do.

find . -type f -exec wc -l {} + | sort -n

Execute the terminal command in your project location, it will give you count of number of lines, like mentioned below

3000 ./ViewControllers/DashboardVC.swift
5655 ./AppDelegate.swift

where 3000/5655 is the lines of code.

Second, I track are we using Appdelete directly?

grep -rnw . -e "UIApplication.shared"

Last, but not the least. Swift/Objective-C dependency visualizer. It creates object dependency graphs and gives you the clear picture.

Screen Shot 2017-11-22 at 5.33.12 PM

Thanks for reading. I hope it was quick and informative for you.

Safety In Swift | Fun Time

Let’s say we have a Car and we want it to be safe so we have seatbelts and airbags and we don’t want to let the truck drive unless safety points passed.

Code Sample

enum Safety {
    case seat
    case door
    case airbag
}

struct Car {
    var seatBeltEnabled: Bool
    var doorLocked: Bool
    var airBagsWorking: Bool
}

extension Car   {
    func drive() throws {
        guard seatBeltEnabled else {
            throw Safety.seat
        }

        guard doorLocked else {
            throw Safety.door
        }

        guard airBagsWorking else {
            throw Safety.airbag
        }
        //Everything fine.... drive carefully
    }
}

I hope everything is looking fine so that’s the beauty of Swift otherwise in other approaches we need to manage it with if-else before we start driving.
That’s all about the small beautiful thing I learned today.

App Secure | URLSession | Authentication Challenge | NTLM | Security | Credentails

Yesterday, I have posted about How to response Authentication Challange but thoughts came in mind that if you are going with the first options Provide authentication credentials is it really secure and safe? how is client sharing the credentials with the server?

After lots of Google, I have found, how’s NTLM works and it’s pretty interesting to see that client don’t share the password with the server. here are the steps as follow.

Screen Shot 2017-10-12 at 1.06.51 PM.png

  1. The client makes the request to the server.
  2. The server needs to validate the user because there is no identity so server generates 16 bytes random number called as the challenge and sends it to the client.
  3. Client hash this challenge with the user’s password and return it back to the server that is called the response it also includes username as plain text and challenge sent to the client.
  4. The server sends everything to the domain controller and it uses the username to retrieve the hash of the user’s password from security account manager database and hash the challenge.
  5. Domain controller shares the response back to the server if they are identical then authentication is successful otherwise a failure.

So the interesting part is here that Network API doesn’t share the password with the server it means it very secure.

Thank you for reading.

Share your thoughts and feeback.