ADDITIONAL RESOURCE: CSCI 20 NOTES

ADDITIONAL RESOURCE: CSCI 21 NOTES

ADDITIONAL RESOURCE: CSCI 22 NOTES
ADDITIONAL RESOURCE: CSCI 30 NOTES
ADDITIONAL RESOURCE: MATH 10 NOTES
ADDITIONAL RESOURCE: MATH 21 NOTES
ADDITIONAL RESOURCE: MATH PREP TRACK A NOTES
ADDITIONAL RESOURCE: MATH 21 PDF DISCUSSIONS
ADDITIONAL RESOURCE: MATH 30.23 NOTES
ADDITIONAL RESOURCE: MATH 60.2 NOTES

GENERAL COURSE NOTES:

- You will read more code than you will ever write.
- MAX grade goes lower every 2 days
- This means incomplete

Writing Maintainable Code

● Writing Clean Code
○ Why
■ Dirty code will be bound to get re-written every couple of years
■ Previous messes will compound to slow you down
● You, as a developer, are the most expensive resource for software
development
● Makes code harder to read and therefore navigate
○ What
■ Minimal dependencies
■ Performance is as close to optimal
■ Does one thing well
■ Performant code does not “tempt” messy code – people usu. make bad
code worse
■ Does one thing well – focused
■ UNIX Philosophy
● Make it work – “I don’t care as long as it works”
● Make it right – “Let’s fix up the ugly parts to make the code
clearer”
● Make it fast – Use the correct DSA; “What needs to be fast? Let’s
only optimize that”
■ Boy Scout Principle – “leave the campground cleaner than you found it”
● If we leave code cleaner than we found it, code could not rot
● Generally applies to codebases you are bound to work on
● Everyone doesn’t have the opportunity to start a new project
○ How
■ Use intention revealing names – what the variable does, what it does,
how it is used
 ● If a name requires comment it does not reveal intent
■ Avoid disinformation – words whose meanings vary from our intended
meaning
■ Make Meaningful Distinctions bet. Variables
● If names must be different, they should also mean something
different
● Making your variables a number series is non-informative
■ Avoid noise words
■ Use pronounceable names
■ Avoid mental mapping
● Readers shouldn’t have to translate names into other names they
already know
● Common with single-letter names
○ Using single letters for loop counters is OK because that is
universally understood but don’t use it in other contexts
○ Just because a and b were taken is not a reason to use c
■ Class names and objects should have noun/noun phrases
● Avoid ambiguous words like “Data” or “Info”, unless they really are
information about the thing
■ Method names should have verb/verb phrases
● Accessors, mutators, and predicates (boolean checkers) should
be named according to return values – consider “get”, “set”, “is”,
etc.
● Overloaded constructors are better with static factory methods that
describe the arguments
■ Pick one word per concept
● Using synonymous words in different classes for the equivalent
methods is confusing
● Use a consistent set of words for similar concepts across the
codebase
■ Don’t Pun
● Avoid using the same word for two purposes
■ Use CS terms when necessary
● If doing bucket sort, use the name bucket
■ Use terms in the problem domain when the task/function is highly tied to
the problem domain
● Recall methods in CSCI 21/22 assessments – names describe the
problem to solve
■ Add meaningful contexts
● Variable names might be prefixed with more context
● Separating into functions is another way to add context to variable
● Namespacing helps to add more context
■ Keep functions small
● Blocks in if, else, and while statements should be
 ● Indentation should not be too deep – three levels at most, one or
two is a good number
○ Otherwise, it no longer does just one thing
○ Don’t be afraid to make a lot of functions
■ Can be used elsewhere
■ Can determine which function is not correct
■ Do one thing
● Doing one thing – the function is doing only steps one level lower
than the function name
● If you can extract another function from your method, it is doing
more than one thing
● Having sections of code is a symptom of code doing more than
one thing
● Creating different functions that you call in another means you can
swap out functions or maintain each individual one to see which is
wrong, etc.
■ One level of abstraction per function
● Statements in functions should be at the same level of abstraction
○ Mixing levels may be confusing
● One should be able to read a program top-down
○ With each description explaining that level of abstraction
○ The description can reference descriptions of the next
lower level of abstraction
■ Try and avoid switch statements – not completely avoidable, keep in
lower levels of abstraction
■ Use descriptive names
● “You know you are working on clean code when each routine turns
out to be pretty much what you expected”
● The smaller the function, the easier to name – long names are
better than long comments
■ # of Function Arguments – 0 is ideal, 1 is better, 2 is okay, avoid 3e, don’t
even think about 4+
● Should be at the same level of abstraction
● More arguments = harder to test
○ Having one argument is, essentially, asking only one
question about that argument then acting on that argument
● Don’t use flag arguments – booleans as arguments
○ Booleans as arguments is bad practice
○ Means that the function is doing more than one thing
● 2 arguments
○ Harder to understand
○ May be appropriate in certain situations
○ If ignoring certain parameters, bugs can hide there – order
causes you to pause/think/skip certain parts
 ● 3 arguments
○ Significantly more confusing than 2 arguments
○ Consider if the combination can be broken down
● With 2 or 3 arguments, consider if it is possible to make the
function into a class – multiple values usu. go together anyway
● Consider encoding the names of the arguments into the function
name
○ No need to remember the ordering of the arguments
○ Not an end-all-be-all, but a possible solution to remember
that arguments that need to be passed
■ Have no side effects
● Side effects – changes that you function does but is not supposed
to do
○ Does other things than what is promised
○ Can happen when a function tries to do too much
■ Functions should either do something or ask something
● Mutate, get, etc.
● Not all three at the same time
■ Prefer exceptions to returning error codes
● Error codes can easily lead to deeply nested code
● Extract try/catch blocks into their own functions
○ Makes them easier to read
■ Don’t repeat yourself, but don’t be scared of some duplication
● If the duplication only happens once, don’t worry about it
■ Don’t create overly abstract complications
● Only create new methods and functions only when necessary
○ Necessary – function is too big, or not doing one thing only
■ How to write
● Write the functions as they come
○ Easier to start with working code
○ Then slowly edit the code to be cleaner
● Writing the code is similar to telling a story of the system, functions
are segments that then help tell that story
■ Comments
● Do not make up for bad code
● Explain yourself in code, not comments
○ Consider rewriting the block into a function
● Good comments
○ Legal comments – copyright/author data
○ Informative comments – convey basic information
○ Explanation of intent
○ Clarification
■ Translate the meaning of something that might be
confusing
 ■ Better to try and make an argument or return value
be clearer
■ Clarify if the message is for something that
CANNOT be changed
○ Warning of consequences
○ TODO comments
○ Amplification – situations where code looks trivial but is
actually important
○ Comment documentation in public APIs
● Bad comments
○ Mumbling/writing for the sake of it
○ Redundant comments
○ Misleading comments
○ Don’t use a comment when you can use a function or
variable
○ Position markers
○ Bylines in code – already noted in source control
○ Commented out code
○ Code about the system
○ TMI such as trivia
○ Pydoc/Javadoc in non-public code
■ Code formatting
● Vertical formatting
○ Source file name should be concise
○ Detail should increase as we go downward – lowest levels
of abstraction in the bottom
○ Line breaks to separate concepts
○ Concepts clearly related should be close in the source
code
■ If a function is called by another, the two should be
vertically close
■ If multiple functions offer similar operations, they
should be close
○ Variable declaration should be as close to the usage as
possible
● Horizontal formatting
○ Hierarchy of scope is visible in the indentation
○ When working with people, agree on code formatting
○ You shouldn’t have to scroll horizontally
● Zen of Python and PEP8 Style
○ The “Zen of Python” – ideas that Python developers generally follow in writing
Python programs, written by the creator of Python
■ Beautiful is better than ugly – code should look simple
■ Explicit is better than implicit – use explicit names
 ■ Simple is better than complex – if there is a simpler way to do something,
use it
■ Complex is better than complicated – a solution might be complex, but
don’t write it in a convoluted way
■ Flat is better than nested – keep hierarchy of modules to a minimum
■ Sparse is better than dense – keep it simple, one-line code may seem
clever but they aren’t always the best
■ Readability counts – you’re bound to read more than you write, so make
code as readable as possible, use naming conventions and style guides
■ Special cases aren’t special enough to break the rules, although
practicality beats purity – there will be instances where you need to break
the rules, in which case choose practicality; guidelines not hard rules
■ Errors should never pass silently unless explicitly silenced
● How to handle errors?
○ Handle within the function where it makes sense
■ If the code that raised the error is able to fix it, do it
there; otherwise, it might be wise to let the
exception be raised to a higher context
○ Allow exceptions to flow upwards to a higher level in the
call stack
○
■ In the face of ambiguity, refuse the temptation to guess – try as much as
possible to figure out what part of the code is wrong
■ There should only be one - and preferably only one - obvious way of
doing it –
■ Now is better than never, although better is often better than right now
● Having code that gets stuck is much worse than one that
terminates when something goes wrong
■ If the implementation is hard to explain,
■ Namespaces are one honking great idea - –
○ PEP8 Style – style guide for Python, devised to be able to help guide all Python
developers towards code readability
■ Naming
● Function, Variable – lowercase or snake_case
● Class – PascalCase
● Constant – ALLCAPS
● Package – lowercasewithnounderscores
■ Code Layout
● Top-level functions and classes should be separated by 2 blank
lines
● If you have methods in a class, they should have one line in
between them
● Recommendation – 79-120 characters
○ Might need to break code
 ■ Indentation
● Use 4 consecutive spaces to for indentation
● Prefer spaces over tabs
● Mixing spaces and table even cause error in Python 3
■ Comments
■ Whitespace
● Operators should have a space on either side, if there is more
than one, only space the last one
● Avoid
○ Inside grouping symbols
○ Before a comma
○ Before the opening parenthesis in a function call
○ After a trailing comma and before the closing parenthesis
in a function call
○ Aligning operators

Source Code Management

● Version Control and Git
○ Version Control
■ For programmers – way to keep track of file changes
● Tracks change in code, past versions of code
● Version Control Save – similar to a game save
○ Saves everything up until the last time you save it
○ Helps you roll back to previous versions of code
■ For organizations – way to keep track of software versions
● Can see past versions of software, prevalent in open-source
software
● Enables organizations to map out features, as in when a certain
software gets a specific feature
○ Terminology
■ Repository – storage area for files, folder that contains files and
subfolders
■ Commit – a saved change
● Something that can be “committed” into version control, even
though it might not be completely working
■ To commit – save a change made in source code
■ Branch – a path of development, “a specific timeline in a multiverse”
● Why branch? – to keep the integrity of the main branch when
changes have to be made
■ Main branch – usu. the “source of truth” where releases are made
● One true line of development
● Normally is where specific automated releases are made
● NOT to be messed with, only make new branches out of it and
merge changes in it
 ● Creating a different branch automates releases in the main branch
○ New feature – make a new branch, new feature does not
exist in production yet
■ Merging then updates the main branch with said
new feature
○ What is Git?
■ A specific Version Control System (VCS)
● Other less popular VCSs – Mercurial, subversion
● Key features
○ Distributed Repositories – all edits made are done locally
on your machine, version control operations are done
locally
■ Each developer working on the same project has a
copy of the repository, not connected to the copy of
the others
■ Each commit is stored in the LOCAL machine
■ Specific conventions and workflows then enable
code to be synced across all developers’ machines
■ Certain software systems, like Github and GitLab,
allow the distributed changes to be synced with one
another
○ Fast Branching – creating a branch = making a copy of the
repository at a particular point in time
■ “Feature Branches” – branches used to create new
features and test new ideas; keeps the main branch
stable
○ Staging Area – allows developers to pick what changes
should be committed at the moment
● NOT GitHub – the latter is a remote repository
○ Git is a software that manages codebases, GitHub is a
form of remote storage
● GITting Started - Getting Started with Git
○ Installation – install Git, and a GUI if you wish
○ Configuration – assign the user to be the one making the changes
■ Git bash
● Name – git config --global user.name “<Name>”
● Email – git config --global user.email “<email>”
■ GUI – there should be a setting for it
○ Syntax – on the command line, git [switches] <command> [<args>]
■ For more information on a specific command – git help <command>
○ Initializing a Repository
■ From a GUI – a folder can be initialized as a Git Repository
■ From a command line – open a terminal in the directory and type git init –
initializes the folder as a Git repository and creates a hidden .git folder
 ● NOT in any software like Github or Gitlab yet
■ Working directory – place/folder where work is done
■ Repository – specialized area where version files can be saved
■ Git has the ability to track file changes – detect differences between files
in the working directory and the repository
● On the local machine, the .git folder
○ Adding a file – to be able to commit a file, you have to add it to the staging area
first
■ From a GUI – a file can be added
■ From a command line – git add <file>
● Adds a file for tracking, but not yet saved to the repository
○ Committing changes
■ From a GUI – there is a button for it
■ From the command line – git commit -m “<description>”
● The description should go into detail as to what files are changed
and how
● There are guidelines to good commit messages
● Branching and Merging
○ Create a new folder, init as repo
■ mkdir <folder> – makes a new folder with the name specified
■ cd <folder> – changes current directory to folder
■ git init – can also initialize with a GUI
○ Add commits to repo
■ Create a new file
■ Add file
■ Commit file
■ Can add more commits
■ Each commit made has a relationship with succeeding commits – the
parent of each commit can be seen with “git log --parents”
● Shorten commit hash with “...parents --abbrev-commit”
● Every commit after the first points to its parent in reverse
chronological order
○ New branch will be made
■ Commits – connected to parent, a linked list in nature
■ Branches – line of commits, development history
● Tip branch – the tip of the branch, latest
● Head – pointer to the commit currently being looked it, typically the
last commit of a branch (head is at the top)
○ But, you can revert back to a previous commit – move the
pointer to look at a different branch using “git checkout
<first 6 characters of the id>”
○ Detached HEAD – pointer is not in the latest commit
 ○ Discouraged to edit in a detached state – head gets in a
rogue state, might need to start over which erases git
history
● Branches should be made when – introducing new features, fixing
existing code
○ To edit a previous version, make a new branch first, make
changes, then merge with the main branch so the head
now points to that
■ Files in between then get merge, which Git knows
how to do unless a merge conflict arises (need user
input on what lines to keep)
■ Making a new branch
● git branch <name> – makes new branch
● git checkout <branch> – visits the branch
○ Might be necessary because developments on different
branches are independent of one another
○ Commits are added to the branch
■ In the branch, do file edits then the standard commit process
○ Branch will be merged into the main development branch
■ Branch – creates diverging code bases
■ Merge – converges 2 branches, results in a commit with multiple parents
● git merge <name> – the branch <name> gets merged into the
branch you are currently at
○ Making a new branch – “git newbranch”
○ Merging – “git merge”
■ Merging branch into main
○ Other useful commands dealing with branches
■ Draw a text-based graphical representation of the commit history
● git log --graph --decorate --pretty=oneline --all --abbrev-commit
■ Finding the difference between 2 branches
● git diff <branch1> <branch2>
■ Quickly make a branch and checkout
● git checkout -b new_branch
● Collaboration in Git
○ Cloning – makes a copy of a repo
■ git clone <URL|local repository name> <optional destination directory>
● Automatically makes directory
■ Check if the branches of the original exists
● git log --simplify-by-decoration --decorate --all --oneline
■ When cloning, only the active branch is checked out
■ Other branches are just tracked as indicated by
remotes/origin/branch_name
■ Checkout tracking branch and make a branch out of it – git checkout
○ Remotes – references to the location of the original repo
 ■ Can be to a local or remote location
■ git remote -v show
■ Remote URLs – show 2 URLs
● Fetch for receiving files/updates
● Push for sending files/updates
● Remote references can be renamed – git remote rename origin
beginning
○ Pushing changes – git push <remote name> <local branch>
■ Need proper permissions – granted by the remote owner
■ All remote-tracking branches track the upstream version (source/origin)
■ Creating a new local branch does not create a remote branch
■ Create a new branch, and checkout – git checkout -b <name>
■ Push the current branch and setup upstream tracking – git push
--set-upstream origin new_branch
■ Conflicts in pushing can occur, but this can be fixed by pulling first before
pushing your own
● git push/pull origin master
○ Pulling code – updating local code with changes from the remote
■ Combines git fetch and git merge
■ If an error in pushing occurs, pulling can help fix
■ Retrieve references – git fetch
■ Merge changes – git merge
● Can add tip of the remote – FETCH_HEAD
■ Pulling code that changes code that has changes locally creates a Merge
Conflict
● To resolve them, look for the markers inserted into your code
○ Bet. HEAD and ====== – local changes; after it are
remote changes
○ Remove markers and keep the code that SHOULD be kept
● Branching and History
○ When to go through history
■ Looking for function calls/declarations
■ Seeing when major changes happened to the codebase
■ See what commits made major changes to the codebase
■ See when/what was changed in major changes which may help in
debugging
○ git log
■ A git log message – has metadata, a subject, and a full commit message
■ See all commits and their parents – git log --parents --oneline
■ 3 commit IDs is a merge
● Can also find merges with git log --merges
● Can also find commits that affect specific files with git log --oneline
<file> <file2> <...> <filen>
 ■ In cases where commit messages contain the issue name/code,
searching through the messages may be useful
● git log --grep=<search term>
● Can also grep through the contents of the files – git grep
<search-term>
■ In cases where code was working before a commit but not after one, it
may be useful to see the diff bet. the two versions
● git log --patch name..name2
● For generic commits – git log --patch <hash>...<hash2>
■ See where the branches diverged – git log --graph --decorate --oneline
--all
○ Gitk – default GUI for git
■ Viewing branches – gitk <branch> <branch> master
■ Can modify which branches you see
● gitk > View Menu > New View
● Add branches and tags you want to see, uncheck “All refs”
■ Can modify the view to just the different branches
● New View > check “All refs” and “Simple History”
■ Look at history of file – gitk <file>
■ File browser – git gui browser <commit|HEAD>
■ Parts of a gitk window
○ git blame – once a commit has been selected for viewing, check who created the
changes
■ “Run git gui blame on this line”
■ git gui blame <file>
■ git blame <file>
● Git Guide for Merging and Rebasing

Working with Templates

● Web Frameworks
○ Server-side Web Programming
■ “Web Server” – either hardware or software
● Hardware – contains server software and files, connected to the
internet
● Software – controls how users access hosted files, via HTTP
through URLs
■ Programming server-side software entails
● Handling different types of HTTP requests
● Retrieving data from databases and returning that data
■ Internet – originally made to serve the purposes of researchers, so they
can access each other’s data and research
● Why an index.html file – the index of the server, lists all the files on
the server ready for access
● The Internet Today – no longer static web pages
 ○ Dynamic – files can change
● Static Site – always returns the same hard-coded content for the
same request
○ Browser sends an HTTP GET request; server retrieves
document then returns it along with a status (successful or
not)
● Dynamic Site – content is generated when needed based on
information from URL
○ Browser sends HTTP GET
○ Server retrieves data from a backend web app retrieved
from a database
○ Web app returns the rendered HTML/data
○ Server returns the HTML/data AND any static resource
■ Environments for server-side code is usu. controlled
● Enables use of diff. languages
■ Web Frameworks – typically used when creating applications to
● Provide constructs to handle web-related tasks – the application
can read whatever request is used on it
● Store and deliver information efficiently – can be put into a
database
● Customized experiences – different experiences based on if the
user is logged in or out
● User access control – users can log in or out
● Session/state information – session in which a user is logged in
● Notifications and communication
○ HTTP and Web Servers
■ Web clients and servers connect via the HyperText Transfer Protocol
(HTTP)
● HyperText – more than strings, can have links to other pages
■ Clients send HTTP requests comprised of
● A URL – uniform resource locator
○ https:// – protocol
○ domain – name of the website
○ .com – top level domain
● An HTTP method
○ GET – get a specific resource
○ POST – create a new resource
○ HEAD – get metadata
○ PUT – update or create a resource
■ Try to update if it exists, create otherwise
○ PATCH – partially update a resource
■ Update ONLY
○ DELETE – delete a resource
● Addtl. Parameters via URL parameters, POST data, or cookies
 ○ URL params – for GET requests, key-value pairs
○ POST data – data included in a POST request for storing
○ Cookies – data about the client to learn about current
status/state
■ Servers wait for the request data to return the proper data and status
■ GET requests are generally made through clicking a link – parts:
● First and second lines:
○ GET
○ URL of resource
○ URL parameters
○ Protocol version
○ Host
● Other lines:
○ User-Agent – client used
○ Accept-Encoding – what compressed information is
supported
○ Accept-Charset – character set accepted
○ Referrer – address that contains the link
○ Cookie – client cookies
● HTTP Response:
○ First line – protocol and response code
○ Other information
■ Content-Type – format/character set of the
response
■ Content-Length – size of resposne
■ POST requests – contain addtl. information about the transaction
● Differ from GET by having a request body and not having data
passed as a parameter
● Response contains additional information about the transaction
○ Location – points to URL for the created resource
○ 302 FOUND – POST succeeded
○ Web Frameworks – handles back-and-forth between client and server via HTTP
■ Handles looking for data and what output format – HTML, JSON, CSV
■ Make it easier to handle specific tasks
○ Common responsibilities handled by a framework
■ Work with HTTP requests and responses
● No need to learn how to write in lower-level languages for access
to HTTP data
■ Routing requests to the appropriate handler
● Different mechanisms to point to the handler functions
● Separate functions per type of request
■ Accessing data in the request – Django provides an HttpRequest object
■ Abstracting database access and management
 ● Web frameworks provide an abstraction layer to the DB – the
ORM, or object-relational mapping
● ORMs – allow for
○ Replacing the used DB to optimize for their use case
○ Basic data validation
● Django ORM
○ Record – referred to as a model
■ Can specify field types, with field-level validation
■ Can have constraints that usual SQL provides as
parameters
■ Rendering data in different formats
● Web frameworks usu. provide a templating engine to HTML
● Generation of other data formats, like JSON, XML, and CSV is
also possible
○ Choosing a Web Framework
■ Effort to learn – language it uses, documentation
■ Productivity
● All factors for learning plus
○ Origin/purpose for the creation of the framework
○ Is it opinionated for a best way or not?
■ Opinionated – usu. better when it is a common
problem and the framework leads you to the
answer; less flexible
● Batteries-included vs. Get-it-yourself
○ Does it have all the tools or is there a need to find or install
○ Everything-included – easier to start, better integrated
● Does it encourage good practices
■ Performance of the framework and language
● Speed benefits of some languages may be offset by maintenance
or learning curves
■ Caching Support
● Caching – becomes important once optimization is needed
○ Mechanism where frequent tasks are stored so it can be
easily retrieved instead of recalculated
■ Scalability – how easy to scale across multiple machines/servers
■ Security
● What level of support against common attacks
● Enabled or disabled by default?
○ Some common web frameworks
■ Django (Python)
● “Batteries included”
● MVC architecture
● Popular sites built with Django – Disqus, MDN, IG, Pinterest
■ Flask (Python)
 ● “Get-your-own”
● Popular for smaller systems
■ Express (JS)
● Unopinionated, get-your-own
● Popular sites on Express – Uber, Accenture
■ Ruby on Rails (Ruby)
● Batteries-included; MVC architecture
● Popular sites on Rails – GitHub, Shopify, Airbnb, Twitch
■ Laravel (PHP)
● Batteries-included; MVC architecture
■ ASP.NET (C#, VB)
● Batteries-included; MVC architecture
● Popular sites on ASP – Stack Overflow
■ Spring Boot (Java)
● Opinionated view of Java’s Spring platform
● Minimum configuration
● Strength in cloud-based systems/parallel systems
● Introduction to Django
○ Django Coding Style – use PEP8; some conventions include
■ 4 spaces for indents
■ Separate top-level functions and class definitions with 2 lines in bet.
■ Separate method definitions with 1 line in bet.
■ 79 characters per line
● Long names/identifiers that make the line exceed this are fine –
better to have good names that break line length rules
■ Import order
● Standard library imports
● Core imports
● 3rd party imports
● Project-level imports
■ Use underscores in URL patterns
■ Choose specific style guides for frontend code
○ Explicit relative imports – allows for renaming/re-using of appl used for importing
from other modules of the same app
○ Optimal Django Setup
■ Use the same database ending in development and production
● Allows for examining production data locally
● Allows for uniformity in field constraints
■ Use PIP, or alternatives like Conda and virtualenv
● PIP – tool that allows for installation of Python packages
○ Django should be installed using PIP or conda, etc.
○ Other packages should also be added via package
managers
● virtualenv – tool that isolates python environments
 ○ Installing Django gives a default project layout
○ Terminology
■ Django project – web app using Django
■ Django apps – libraries/folders that represent a single aspect of a project;
a project is made of many apps
■ INSTALLED_APPS – Django apps used by a project, written down in the
settings file
○ Third-party Django packages – reusable Django apps
○ Django App Design – it is better to have a lot of small apps than a few giant apps
■ “If an app can't be explained in a single sentence of moderate length, or
you need to say 'and' more than once, it probably means the app is too
big and should be broken up.” (Two Scoops of Django)
■ Naming – app names should be the plural version of the main model of
the app
● Also consider the possible URL for that app
● Use valued PEP-8 compliant package names:
○ All lowercase
○ Without numbers, spaces, dashes, and other special
characters
○ Underscores if necessary, but discouraged
■ What belongs where – most Django apps would have the following
modules:
● Management folder
● Migrations folder
● __init__.py
● admin.py
● forms.py
● models.py
● urls.py
● utils.py
● Views.py
○ Installing Django (GeeksForGeeks)

Working with Templates

● Web Frameworks

Django Models
● Running the default migrations
○ Migrations – way to ensure that the database structure is consistence across
different setups (development, production, etc.) and to manage any database
structure changes
● Models – class that maps to a single database table
○ Models the database structure
 ○ Each model
■
○

Querying
● QuerySet
○ Set of objects resulting from doing queries on the Django ORM
●