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
