Scribd
Upload
45 views

Coding

The document discusses principles and best practices for writing clean, readable code including: - Linting tools that analyze code for errors, bugs, and style issues. - Writing code with searchable, readable, and understandable variables, functions, and comments by following naming conventions and other guidelines. - SOLID principles like the single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion principles which aim to create flexible, understandable and maintainable code. - Each principle is explained with its goal and implementation considerations. Resources for further reading are also provided.

Uploaded by

uta
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
45 views

Coding

The document discusses principles and best practices for writing clean, readable code including: - Linting tools that analyze code for errors, bugs, and style issues. - Writing code with searchable, readable, and understandable variables, functions, and comments by following naming conventions and other guidelines. - SOLID principles like the single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion principles which aim to create flexible, understandable and maintainable code. - Each principle is explained with its goal and implementation considerations. Resources for further reading are also provided.

Uploaded by

uta
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 47

Code Like a Pro

By: Dylan C. Israel


YouTube.com/CodingTutorials360
Code Like a Pro: Linting
By: Dylan C. Israel
The Big 2
WHAT WHY

A linter or lint refers ● Readability


to tools that analyze
source code to flag
● Catches
programming errors, syntax errors
bugs, stylistic errors, ● Automation
and suspicious
constructs.
Code Like a Pro:
Variables

By: Dylan C. Israel


3 Main Objectives

Searchable
Readable
Understandable
How We Accomplish Our Objectives

● Follow Language Standards


● Limiting scope
● Creating New Variables vs Reusing
● Eliminating magic numbers
● Choose a name that describes what it does, but not
how it does it
● Parent or Significant other test?
● When to use Long Names vs Short Names
● And more...
Code Like a Pro: Functions
By: Dylan C. Israel
Objectives:
Readable
Searchable
Understandable
● Small functions
● Eliminating boolean flags
● Reads top to bottom
● Correct function naming

How ●
●
Limiting parameters
DRY
● Avoid side effects
● NO GLOBALS
Code Like a Pro:
Comments

By: Dylan C. Israel


2 Main Objectives

What are BAD comments?


What are GOOD comments?
What makes comments BAD?

● Comments used when they are unneeded


● Comments are typically used to explain bad code
● Comments need to be maintained and may mislead
● Leftover code
● Version control code
● Visual Markers
● TODOs
What makes a GOOD comment?

● Short and concise.


● Provides value.
● Clarifies code that has a business purpose but looks
out of sort.
● Sometimes a warning or amplification of importance.
● Legal Comments
SOLID Principles
YouTube.com/CodingTutorials360

By: Dylan C. Israel


● S - Single Responsibility
Principle
● O - Open Closed Principle
● L - Liskov Substitution

Overview ●
Principle
I - Interface Segregation
Principle
● D - Dependency Inversion
Principle
Who/Where?

Robert C. Martin
● Introduced in 2000 paper
on Design Principles and
Design Patterns

● Clean Code

● The Clean Coder

● Co-Author of the Agile


Manifesto
What?

OOP Agile
● Designed for OOP ● Testing & TDD

● Language agnostic ● Principles supports a rapid


development process
Why?

Goals
● Understandable code

● Maintainable code

● Flexible code
Single ‘A class should have one, and
Responsibility only one, reason to change.’

Principle
Open Closed
‘You should be able to extend a
classes behaviour, without

Principle modifying it’


Liskov ‘Derived classes must be

Substitution substitutable for their base


classes.’
Principle
Interface ‘Clients should not be forced to

Segregation depend on methods that they


do not use.’
Principle
Dependency ‘High level modules should not
depend upon low level modules.
Inversion Both should depend upon
abstractions.’
Principle
Single Responsibility Principle
By: Dylan C. Israel
● The SRP states that each
The Idea software module should have
one and only one reason to
change.
What This
● Small classes
Means? ● Single responsibility classes
● Limiting the impact of change.
What It Actually ● ‘Gather together the things that
change for the same reason.
Means Separate those things that
change for different reasons.’
● Cohesion where it matters
● Decoupling where it doesn’t
● https://blog.cleancoder.com/u
Resources ncle-bob/2014/05/08/SingleRe
ponsibilityPrinciple.html
Implementation
Open Closed Principle
By: Dylan C. Israel
● Software should be open for
The Idea extension, but closed for
modification.
What This ● Extend so no need to refactor
Means? legacy code.
What It Actually ● Successful use of inheritance
● Allows change to occur easily
Means ● A well written class should not
have to be updated in multiple
spots
● https://blog.cleancoder.com/u
Resources ncle-bob/2014/05/12/TheOpen
ClosedPrinciple.html
Implementation
Liskov Substitution Principle
By: Dylan C. Israel
● If S is a subtype of T, then
objects of T may be replaced
The Idea with objects of S without
altering any of the desirable
properties of the program.
What It Actually ● Subtypes should retain the
Means ●
behavior of the main type
Children should be like their
parents for what they inherit
Implementation
Interface Segregation Principle
By: Dylan C. Israel
● Do not force the client to
The Idea depend on methods they do
not use.
What It Actually
● Many small classes/interfaces
Means ● Role interfaces
● Support abstraction
Implementation
Dependency Inversion Principle
By: Dylan C. Israel
● High level objects should not
The Idea depend on low level
implementations.
What It Actually ● Depend in abstractions
Means ● Abstractions should not
depend on low level details
● Support abstraction
Implementation

You might also like